LINUX.ORG.RU

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

mittorn ★★★★★
()

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

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

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

iron ★★★★★
()
Последнее исправление: iron (всего исправлений: 1)
Ответ на: комментарий от mittorn

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

cobold ★★★★★
()
Ответ на: комментарий от cobold

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

mittorn ★★★★★
()
Ответ на: комментарий от mittorn

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

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

vbcnthfkmnth123 ★★★★★
()
Последнее исправление: vbcnthfkmnth123 (всего исправлений: 1)
Ответ на: комментарий от mittorn

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

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

cumvillain
()
Ответ на: комментарий от vbcnthfkmnth123

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

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

cumvillain
()
Ответ на: комментарий от t184256

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

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

cumvillain
()

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

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

MoldAndLimeHoney
()
Ответ на: комментарий от cobold

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

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

hateyoufeel ★★★★★
()
Ответ на: комментарий от hateyoufeel

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

cobold ★★★★★
()
Последнее исправление: cobold (всего исправлений: 1)
Ответ на: комментарий от cobold

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

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

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

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

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

hateyoufeel ★★★★★
()
Последнее исправление: hateyoufeel (всего исправлений: 2)
Ответ на: комментарий от vbcnthfkmnth123

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

mittorn ★★★★★
()
Ответ на: комментарий от cumvillain

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

mittorn ★★★★★
()
Ответ на: комментарий от cumvillain

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

mittorn ★★★★★
()
Ответ на: комментарий от mittorn

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

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

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

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

vbcnthfkmnth123 ★★★★★
()
Последнее исправление: vbcnthfkmnth123 (всего исправлений: 1)
Ответ на: комментарий от vbcnthfkmnth123

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

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

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

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

mittorn ★★★★★
()
Ответ на: комментарий от hateyoufeel

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

asm ("int 0x80")

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

sparks ★★★★
()
Ответ на: комментарий от sparks

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

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

cumvillain
()
Последнее исправление: cumvillain (всего исправлений: 1)

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

vasya_pupkin ★★★★★
()
Ответ на: комментарий от sparks

asm («int 0x80»)

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

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

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

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

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

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

hateyoufeel ★★★★★
()
Ответ на: комментарий от cumvillain

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

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

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

hateyoufeel ★★★★★
()
Ответ на: комментарий от hibou

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

hibou ★★★★★
()
Ответ на: комментарий от hateyoufeel

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

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

cumvillain
()
Последнее исправление: cumvillain (всего исправлений: 2)
Ответ на: комментарий от hateyoufeel

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

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

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

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

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

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

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

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

sparks ★★★★
()
Ответ на: комментарий от hibou

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

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

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

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

hateyoufeel ★★★★★
()
Последнее исправление: hateyoufeel (всего исправлений: 2)
Ответ на: комментарий от sparks

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

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

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

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

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

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

hateyoufeel ★★★★★
()
Ответ на: комментарий от hibou

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

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

hateyoufeel ★★★★★
()
Ответ на: комментарий от hateyoufeel

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

cumvillain
()
Ответ на: комментарий от cumvillain

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

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

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

hateyoufeel ★★★★★
()
Последнее исправление: hateyoufeel (всего исправлений: 2)
Ответ на: комментарий от mittorn

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

iliyap ★★★★★
()
Ответ на: комментарий от hateyoufeel

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

hibou ★★★★★
()
Ответ на: комментарий от cumvillain

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

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

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

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

hateyoufeel ★★★★★
()
Последнее исправление: hateyoufeel (всего исправлений: 1)
Ответ на: комментарий от hibou

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

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

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

hateyoufeel ★★★★★
()
Последнее исправление: hateyoufeel (всего исправлений: 1)
Ответ на: комментарий от hateyoufeel

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

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

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

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

cumvillain
()
Последнее исправление: cumvillain (всего исправлений: 4)
Ответ на: комментарий от mittorn

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

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

cumvillain
()
Ответ на: комментарий от hateyoufeel

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

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

mittorn ★★★★★
()
Ответ на: комментарий от mittorn

только вот перед дёрганьем этого 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
cumvillain
()
Последнее исправление: cumvillain (всего исправлений: 1)
Ответ на: комментарий от hibou

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

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

cumvillain
()
Ответ на: комментарий от cumvillain

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

mittorn ★★★★★
()
Ответ на: комментарий от cumvillain

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

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

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

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

hateyoufeel ★★★★★
()
Ответ на: комментарий от cumvillain

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

mittorn ★★★★★
()
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)