Из OpenBSD начинают выпиливать syscall()

Зато так там точно не будет флетпаков - тебе не дадут просто притащить левую libc с собой. Хотя конечно то что всё крутится так вокруг libc и нет интерфейсов позволяющих разным libc уживаттся в процессе - плохо

Чтобы усложнить жизнь крякерам

О даа... OpenBSD насколько популярна, что все крякеры мечтают ее взломать.

P.S: Главная фича безопасности опенка в том, что его нигде вживую не найдешь)

Если смотреть на libc как на неотъемлемую часть системы, такую же как ядро или системный менеджер, то желание иметь вторую libc выглядит странным, ведь получится другая система

Но почему это должна быть именно libc, а не какое-то другое API? А что если я хочу писать на другом языке?
Я бы всё-таки разлелил libc (реализация C и POSIX) и какое-то system api, работающее с сисколами, TLS, потоками и аллокатором. Да, в unix в принципе так сложилось, что всё крутится вокруг libc. Но стоит хоть немного накосячить (привет glibc), как понимаешь всю проблемность такого решения. Я конечно надеюсь что в bsd ситуация с libc не такая печальная.
но результат проблем c glibc - появление таких замечательных вещей как флетпаки, тащащуие весь юзерспейс с собой.
Для сравнения - в windows libc реализован поверх нижестоящих стабильных API и приложения спокойно могут таскать с собой хоть 10 рпзных версий - сам рантайм небольшой, зато у каждой библиотеки он свой и они не мешают друг другу.

но результат проблем c glibc - появление таких замечательных вещей как флетпаки, тащащуие весь юзерспейс с собой.

В винде то же самое, часто программы таскают все зависимости с собой, потому что пользователь не осилит найти эти зависимости и скачать отдельно.

нет интерфейсов позволяющих разным libc уживаттся в процессе

Какие к чертям разные libc? :D

но результат проблем c glibc - появление таких замечательных вещей как флетпаки, тащащуие весь юзерспейс с собой.

Нет, flatpak это результат отсутствия единого пакетного менеджера.

В винде то же самое, часто программы таскают все зависимости с собой, потому что пользователь не осилит найти эти зависимости и скачать отдельно.

И в макоси. Потому что это, внезапно, удобно.

Кто-нибудь объясните, что мешает крякерам принести кусочек асма с собой.

Кто-нибудь объясните, что мешает крякерам принести кусочек асма с собой.

mmap. Чуть раньше Тео запретил вызывать сисколы из регионов не помеченных специальным флагом.

Вот: https://man.openbsd.org/pinsyscall.2

И вот: https://isopenbsdsecu.re/mitigations/pinsyscall/

Зачем? Чтобы усложнить жизнь крякерам, конечно.

Ох уж эти проблемы популярных ОС.

Если смотреть на libc как на неотъемлемую часть системы, такую же как ядро или системный менеджер, то желание иметь вторую libc выглядит странным, ведь получится другая система

Не надо так смотреть на libc. Libc – это просто библиотека. Софт на другом языке вполне может её не использовать.

Это не просто библиотека, это системная библиотека. Что у нас в систему входит? Ядро, системные библиотеки, системные утилиты, компиляторы для данной системы. Прикладной софт может конечно и самостоятельно реализовывать какие-то части, но то причуды и заботы авторов того прикладного софта, если они считают себя более компетентными чем авторы системы. Правда зачем тогда они вообще пользуются системой остается загадкой

Это не просто библиотека, это системная библиотека.

Нет, это просто библиотека.

Что у нас в систему входит? Ядро, системные библиотеки, системные утилиты, компиляторы для данной системы.

В чью систему? Откуда ты это взял? Лялекс – это бардак и в зависимости от дистра в «систему» может входить что угодно, начиная от разных libc (включая 5 разных штук их) и заканчивая интерпретатором JavaScript просто потому что.

Другой вопрос, что эти методы безопасности через выделение libc в качестве «особенной» библиотеки – это полное говно. В случае с сисколлами, их надо нахрен из libc выдавить. Гораздо проще и надёжнее их сунуть в VDSO. Можно даже номера сисколлов для каждого процесса рандомизировать таким образом: у firefox вызов execve будет иметь номер 115, у терминала – 32, и так далее. Это же решает вопрос со статически собранными программами, которые на твою системную libc клали огромный болт.

Таскать зависимости с собой - нормально. ненормально тащить ВЕСЬ ЮЗЕРСПЕЙС. Флетпак тащит libc и реализации opengl/vulkan т.к они тоже зависят от libc. Ты где-нибудь видел чтобы на винде в зависимостях icd дллки от драйвера притаскивали? Да винда упала бы как только драйвер обновился бы.

Которые имеют несовместимые между собой abi

Нет, пакетный менеджер тут не причём, пробоема уходит в glibc с его односторонней совместимостью

Флетпак тащит libc

Это расчитано на то что программу будут запускать в системе где musl основная libc, насколько я понял

реализации opengl/vulkan

Они отличаются в зависимости от драйвера. На каком-нибудь Nouveau не реализованы некоторые вещи которые есть в закрытом драйвере, поэтому тут логика мне понятна. Обеспечивается гарантированная работа вне зависимости от драйвера, насколько я понимаю.

Это расчитано на то что программу будут запускать в системе где musl основная libc, насколько я понял

Нет, musl тут не причём. Это происходит и на glibc. Потому что софт не запустится на libc более старрй версии, а на более новой не оттестирован. А собирать под древний libc тоже проблема - там были серьёзные баги. Тем временем дебиан всё равно libc не обновляет.

Они отличаются в зависимости от драйвера. На каком-нибудь Nouveau не реализованы некоторые вещи которые есть в закрытом драйвере, поэтому тут логика мне понятна. Обеспечивается гарантированная работа вне зависимости от драйвера, насколько я понимаю.

Нет, ты неправильно понимаешь. nouveau не будет работать если в системе блоб, как и наоборот
Так же как и radeonsi если используется radeon для стврой amd видюхи.
Ещё существует ненулевая вероятность, что шаринг текстур будет сломан между разными версиями драйвера и приложение не сможет рисоваться в дисплейный сервер. Например у amdgpu-pro тайловые форматы отличаются от свободных дров. Но фанатам flatpak на это обычно пофиг, они скорее поменяют драйвер в системе лишь бы хвалёный флетпак работал

Да ну, бред, сисколы это обычные прерывания которые благодаря кольцам защиты обрабатываются ядром, по факту это единственный механизм вызовов из User space в Kernel space, что тут надо рандомизировать и зачем? Цепочка и так максимально проста app -> prinf() -> libc -> syscall::write(1, «Hello world», 22) -> kernel -> … , куда это переносить из стандартной либы? Вообще хз в чём именно тут безопасность, при выпиливании syscall(2) это и так чуть ли не голый макрос над

asm ("int 0x80")

бери да вызывай на здоровье, другой момент, что сам по себе libc знатно разжирел и уже не только базовая библиотка для C, а и всё пользовательское окружения, nss и пр. вот это было бы удобно растащить

asm («int 0x80») бери да вызывай на здоровье, другой момент

В openbsd ты за это sigabrt получишь. ld.so помечает из каких адресов ты можешь делать сисколы, ядро это проверяет, и если одно с другим не совпало тебе прилетает.

Да не поможет это сишникам

asm («int 0x80»)

Бвахахахахахах!

Так было лет 30 назад. Во-первых, в x86 давно есть инструкции syscall и sysenter (одна появилась на Intel, другая – на AMD).

по факту это единственный механизм вызовов из User space в Kernel space

Нет, не единственный.

тут надо рандомизировать и зачем?

ВСЁ. А зачем это нужно – чтобы зловред с эксплоитом не мог дёрнуть execve(«/bin/sh»), потому что он не будет знать, где в целевом процессе находится вызов execve или какой номер у этого системного вызова.

asm («int 0x80») бери да вызывай на здоровье, другой момент

В openbsd ты за это sigabrt получишь. ld.so помечает из каких адресов ты можешь делать сисколы, ядро это проверяет, и если одно с другим не совпало тебе прилетает.

Там только execve() сейчас помечается.

А почему зловреду нельзя пользоваться функциями libc?

В astra есть механизм замкнутой среды. Бинарники подписаны. Запускается только то, что подписано.

execve помечается с помощью pinsyscall. Есть еще msyscall :))))

Разница в гранулярности. msyscall позволяет звать сисколы из всего адресного пространства libc.so.

Можно, за это Тео и критикуют.

Так было лет 30 назад. Во-первых, в x86 давно есть инструкции syscall и sysenter (одна появилась на Intel, другая – на AMD).

О да, координальное изменение

по факту это единственный механизм вызовов из User space в Kernel space

Нет, не единственный.

А какие ещё есть? Без совсем уж костылей с виртуальными файловыми системами, где так или иначе работа происходит через системные вызовы.

тут надо рандомизировать и зачем?

ВСЁ. А зачем это нужно – чтобы зловред с эксплоитом не мог дёрнуть execve(«/bin/sh»), потому что он не будет знать, где в целевом процессе находится вызов execve или какой номер у этого системного вызова.

Я прям помню как про Windows 95 тоже самое говорили, что теперь она будет не заражаемая, т.к. адреса функций не будут статические))

А почему зловреду нельзя пользоваться функциями libc?

Потому что их ещё надо найти. Речь идёт именно о шелл-коде.

В OpenBSD сейчас libc линкуется каждый раз в рандомном порядке. В том смысле, что .o из которых состоит libc линкуются собственно в библиотеку при загрузке и никто заранее не знает, по какому адресу лежит какая функция. Вот такой хардкорный ASLR.

https://marc.info/?l=openbsd-tech&m=146159002802803&w=2

О да, координальное изменение

Вообще, да. Это и правда очень значимое изменение.

А какие ещё есть?

Например, через шареную память. gettimeofday() раньше был отдельным сисколлом, сейчас это функция, которая просто читает переменную из VDSO.

Я прям помню как про Windows 95 тоже самое говорили, что теперь она будет не заражаемая, т.к. адреса функций не будут статические))

Кто говорил? Голоса в твоей голове?

В astra есть механизм замкнутой среды. Бинарники подписаны. Запускается только то, что подписано.

Это пока у тебя буфер не протечёт в твоих подписанных бинарниках.

Я слушал разборы митигейшонов из openbsd. В основном консенсус среди писателей эксплоитов какой-то такой: pledge, unveil и privsep это пушка и очень, очень хорошо. Попытки закрыть ROP это бессмысленная работа.

Я слушал разборы митигейшонов из openbsd. В основном консенсус среди писателей эксплоитов какой-то такой: pledge, unveil и privsep это пушка и очень, очень хорошо. Попытки закрыть ROP это бессмысленная работа.

Там примерно две техники для этого: ASLR и пересборка libc/рандомизация бинарников. Что именно из этого бессмысленно? ASLR?

К слову, я полуркал сейчас, полную рандомизацию бинарников (т.е. перелинковка всего бинарника перед запуском в рандомном порядке) делают, например, в AWS Lambda.

Там примерно две техники для этого

Больше: https://isopenbsdsecu.re/

Проблема не в glibc, а в отсутствии Linux sdk. Например, последняя версия windows sdk позволяет собрать бинарник для windows 2012, а последняя версия Ubuntu не позволяет собрать бинарник для Linux 2012.

Очень круто! Прикольно, что в openbsd пробуют новое, глядишь и в других системах появится что-то подобное.

Так может это и хорошо? Вирусы работать не будут старые. А софт и так пересобирается.

Там примерно две техники для этого

Больше:https://isopenbsdsecu.re/

Я знаю про этот сайт. Против ROP там примерно две техники: ASLR и libc/library order randomisation.

P.S. вру, три. Ещё ROP gadgets removal.

Так может это и хорошо? Вирусы работать не будут старые. А софт и так пересобирается.

Вирусам насрать 100500 раз на это. Единственное, к чему это приводит, это к чудовищному пердолингу, когда нужно собрать код под RHEL или Debian.

То есть, уже не приводит, потому что все пересели на Docker. Как раз из-за этого пересели, да.

Против ROP там примерно две техники: ASLR и libc/library order randomisation.

• Control-flow integrity
• MAP_STACK
• pinsyscall
• SROP mitigation
• Stack cookies and RETGUARD
• TRAPSLED

Да дохрена чего.

Основная суть претензий в том что все эти вещи позиционируются как помогающие против ROP, но неработающие на самом деле.

linux sdk это и есть API сисколов

linux sdk это и есть API сисколов

Aha. А теперь обратно в реальный мир. Допустим, ты хочешь добавить в sandbox функцию open(). Какой сискол? Ну очевидно, SYS_open. Но нет, в glibc начиная с N версии open() транслируется SYS_openat. То же самое с кучей других функций. Сискол вообще могут удалить из API ядра и ты даже не заметишь.

Например, через шареную память. gettimeofday() раньше был отдельным сисколлом, сейчас это функция, которая просто читает переменную из VDSO.

только вот перед дёрганьем этого vdso проверяется, не изменился ли часовой пояс сисколлом.

только вот перед дёрганьем этого vdso проверяется, не изменился ли часовой пояс сисколлом.

Чего делается?

$ cat
#include <time.h>

int
main(void)
{
	struct timespec t = {0};

	clock_gettime(CLOCK_REALTIME, &t);
	return 0;
}
$ strace -c ./test
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
  0.00    0.000000           0         1           read
  0.00    0.000000           0         2           close
  0.00    0.000000           0         8           mmap
  0.00    0.000000           0         3           mprotect
  0.00    0.000000           0         1           munmap
  0.00    0.000000           0         1           brk
  0.00    0.000000           0         2           pread64
  0.00    0.000000           0         1         1 access
  0.00    0.000000           0         1           execve
  0.00    0.000000           0         2         1 arch_prctl
  0.00    0.000000           0         1           set_tid_address
  0.00    0.000000           0         2           openat
  0.00    0.000000           0         2           newfstatat
  0.00    0.000000           0         1           set_robust_list
  0.00    0.000000           0         1           prlimit64
  0.00    0.000000           0         1           rseq
------ ----------- ----------- --------- --------- ----------------
100.00    0.000000           0        30         2 total

Очень круто! Прикольно, что в openbsd пробуют новое, глядишь и в других системах появится что-то подобное.

Проблема в том что настоящие хакеры, которые эксплоиты за бабки пишут, говорят что половина всего что Тео делает это попытка завалить атакующего булшитом, в котором ему будет слишком лень разбираться, потому что OpenBSD никому не нужна.

про удалить не совсем верно, Торвальдс не хочет ломать совместимость со старым юзерспейсом. Но новые действительно добавляют.
Я же о том, что сисколы - единственное более-менее стабильное API.
В glibc пусть и «держат» обратную совместимость, реально совместимость там хромает, хоть собирая софт под старые версии ты получаешь memmove вместо memcopy и на новых версиях. Ломает то отрубая генерацию sysv хэшей, то встраивая всякие стекпротекторы и меняя выравнивание для sse.
Единственный способ сделать нормальный юзерспейсный «linux sdk» - сделать специальный сисрут, который для таких функций будет встраивать обёртки. Но пока единственный более-менее поддерживающийся такой sdk - это, как ни странно, steam runtime, но он - просто сисрут под более старую glibc, не более того.

Очень круто! Прикольно, что в openbsd пробуют новое, глядишь и в других системах появится что-то подобное.

Проблема в том что настоящие хакеры, которые эксплоиты за бабки пишут, говорят что половина всего что Тео делает это попытка завалить атакующего булшитом, в котором ему будет слишком лень разбираться, потому что OpenBSD никому не нужна.

Да-да, «настоящие какиры».

В этом в общем-то суть любых техник, препятствующих эксплуатации: сделать взлом либо экономически нецелесообразным (можно найти цель по-проще), либо задержать настолько, чтобы админы успели заметить. Никто не говорит, что всё это даёт какие-то 100% гарантии от взлома, даже Тео.

само по себе время нет, а ты попробуй его в локальное переводить. Будет перечитывать /etc/localtime на каждом вызове localtime