ASLR, PIE, RELRO, BIND_NOW, W^X и подобное

Что: 5916b1b5c4827dccf0a7ced477a8e7d6de45908f

Когда: 2021-03-04 14:30:57+03:00

Темы: bsd c

ASLR, PIE, RELRO, BIND_NOW, W^X и подобное

https://hardenedbsd.org/content/easy-feature-comparison
https://wiki.gentoo.org/wiki/Hardened/Toolchain
https://wiki.ubuntu.com/Security/Features
https://wiki.freebsd.org/Hardening
Ничего из этого нет на FreeBSD. Точнее частично ASLR есть в develop
ветках FreeBSD. В HardenedBSD довольно давно. В OpenBSD вообще раньше
всех ОС появилось почти 20 лет назад.

Только с началом программирования на Си начал хоть как-то понимать про
что это всё и чем оно важно. Точнее под вопросом важен ли ASLR: полно
людей считает что это security by obscurity, значит нафиг нужно, не
серьёзно. Про ASLR не много чего могу сказать, но то что SbO это не
серьёзно -- солидарен. Меня не продолжают удивлять рекомендации менять
порты SSH-а или имена учётных записей чтобы злоумышленник имел чуть чуть
более высокий порог входа. Я не считаю этот геморрой стоящим этого. В
чём проблема с SSH? Если используется аутентификация по ключам, то пусть
хоть об-brute-force-ятся. А если где-то применяются пароли -- то я
считаю вообще не стоит задумываться о безопасности с таким подходом: тут
ничего не поможет.

На деле попробовал использовать SSP:
https://wiki.osdev.org/Stack_Smashing_Protector
включаемый -fstack-protector опцией. В FreeBSD оказывается можно
глобально для портов включить эту опцию. Overhead, говорят, очень
незначительный. А я видел что даже не злонамеренный код может
набедокурить -- и раздражать то будет неясность его поведения и что
вообще происходит.

ASLR+PIE вроде в FreeBSD всё же собираются внедрить. Удивляет что
Windows уже давно в курсе про многие подобные технологии и использует их.

Всякие RELRO и BIND_NOW вроде не касаются статически собранного софта.
Ещё один довод что нафиг динамическую линковку, ибо и PIE и BIND_NOW
имеют очень нехилый overhead, как пишут.
В 5fca611e0f3c79a2985ba04708ecedf960ed7c03 писал что меня удивляло что
на простой FreeBSD всё визуально как будто значительно быстрее стало
работать. Возможно связано как-раз вот со всем этим.

https://hardenedbsd.org/article/shawn-webb/2021-02-28/hardenedbsd-february-2021-status-report
https://cgit.freebsd.org/src/commit/?id=2e1c94aa1fd582fb8ae0522f0827be719ff5fb67
https://www.freebsd.org/news/status/report-2019-07-2019-09/#Kernel-Mapping-Protections
пишут что и работа по W^X ведётся и мержится.

оставить комментарий

комментарий 0:

From: kmeaw
Date: 2021-03-04 17:38:01Z

А является ли подмешивание случайный значений в некриптографические
функции security by obscurity? Например, рандомизация порядка обхода map
в golang, случайные per-process добавки к hash в Python, Ruby и Perl?

ASLR заметно усложняет эксплуатацию уязвимости, требуя либо
дополнительный address leak, либо пересбора, что делает атаку гораздо
более заметной. К сканированию TCP-портов все привыкли, поэтому вряд ли
кто-то начнёт готовиться отбивать атаку и вдумчиво читать логи в
реальном времени при многократных попытках найти порт SSH. А в случае
резкого роста числа SIGSEGV уже стоит начать внимательно следить за
своей системой и подменять её на honeypot.

Ещё ASLR заставляет программу по-разному использовать память при
перезапусках, что увеличивает вероятность случайно обнаружить в своём
коде какой-нибудь баг.

комментарий 1:

From: Sergey Matveev
Date: 2021-03-04 19:38:09Z


>А является ли подмешивание случайный значений в некриптографические
>функции security by obscurity? Например, рандомизация порядка обхода map
>в golang, случайные per-process добавки к hash в Python, Ruby и Perl?

У меня тут нет мнения. Ни тут, ни касательно ASLR. Нет ещё чувства понимания.

>ASLR заметно усложняет эксплуатацию уязвимости, требуя либо
>дополнительный address leak, либо пересбора, что делает атаку гораздо
>более заметной.

Видимо поэтому, касательно ALSR, постоянно говорят про то сколько
энтропии какая реализация добавляет и как всё плохо с узким адресным
пространством i386.

>Ещё ASLR заставляет программу по-разному использовать память при
>перезапусках, что увеличивает вероятность случайно обнаружить в своём
>коде какой-нибудь баг.

И потом отлавливать его, пытаясь воспроизвести :-).
Но согласен что лучше знать факт наличия бага.

Сгенерирован: SGBlog 0.34.0