Исходное сообщение
"В Android и старых ядрах Linux устранена уязвимость, эксплуа..." Отправлено добрый, 05-Апр-17 18:57
> следует понимать, что эти "cотни" на самом деле еще обычно очень непросто использовать К сожалению, это заблуждение, которое развеивается простым разбором кода публикуемых эксплойтов и анализом количества и сложности техник обхода защит, которые там используются. Хороший пример, из последних (обратите внимание на простоту отключения SMEP): https://a13xp0p0v.github.io/2017/03/24/CVE-2017-2636.html С самозащитой ядра в линуксе дела обстоят очень плохо (в сравнении с современной виндой и iOS, например). Большинство тех механизмов защиты, которые реализованы, либо всё ещё нуждаются в необходимом дополнении другими, либо имеют серьёзные изъяны, либо не имеют практического смысла. При этом множество фич, таких как непривилегированные user и network namespaces, eBPF, только увеличивают поверхность атаки и открывают пути к эксплуатации кода, который изначально не писался с оглядкой на защиту от эксплуатации (со стороны root или capable-процессов, которые на момент написания являлись единственными его пользователями). И то, чем преимущественно сейчас занимается Kernel Self-Protection Project - это неумелое и, что важнее, бессистемное портирование (читай: копипаста с ошибками) "низко висящих фруктов" из патча Grsecurity (который, к тому же, в ближайшие недели пропадёт из публичного доступа). Этим не достигается практически ничего, кроме создания ложного чувства безопасности у пользователей и ложного имиджа линукс как ОС с современным подходом к безопасности. Из последних перлов: http://www.openwall.com/lists/kernel-hardening/2017/03/23/3 - "защита" от нападающего с примитивами arbitrary read+write, доступность которых делает такую и все подобные "защиты" бесполезными. http://www.openwall.com/lists/kernel-hardening/2017/04/04/10 - патч, который добавляет ещё одну ситуацию гонки за запись в память к уже существующей, от которой по задумке должен защищать. Почему так происходит? Не выработана и не принята модель угроз, в её рамках не ведётся системная работа. Сообщество продемонстрировало нежелание или неспособность критически оценивать ситуацию и формировать спрос на её исправление. А в свою очередь бизнесу, построенному на базе линукса и СПО, выгодно поддерживать статус кво, поскольку маркетинг, вводящий в заблуждение на фоне практической неспособности потребителя оценить искомые качества (безопасность), даёт прибыльность и обходится гораздо дешевле реальной технической работы.

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	>> следует понимать, что эти "cотни" на самом деле еще обычно очень непросто использовать > К сожалению, это заблуждение, которое развеивается простым разбором кода публикуемых эксплойтов > и анализом количества и сложности техник обхода защит, которые там используются. > Хороший пример, из последних (обратите внимание на простоту отключения SMEP): > https://a13xp0p0v.github.io/2017/03/24/CVE-2017-2636.html > С самозащитой ядра в линуксе дела обстоят очень плохо (в сравнении с > современной виндой и iOS, например). Большинство тех механизмов защиты, которые реализованы, > либо всё ещё нуждаются в необходимом дополнении другими, либо имеют серьёзные > изъяны, либо не имеют практического смысла. При этом множество фич, таких > как непривилегированные user и network namespaces, eBPF, только увеличивают поверхность > атаки и открывают пути к эксплуатации кода, который изначально не писался > с оглядкой на защиту от эксплуатации (со стороны root или capable-процессов, > которые на момент написания являлись единственными его пользователями). > И то, чем преимущественно сейчас занимается Kernel Self-Protection Project - это неумелое > и, что важнее, бессистемное портирование (читай: копипаста с ошибками) "низко висящих > фруктов" из патча Grsecurity (который, к тому же, в ближайшие недели > пропадёт из публичного доступа). Этим не достигается практически ничего, кроме создания > ложного чувства безопасности у пользователей и ложного имиджа линукс как ОС > с современным подходом к безопасности. > Из последних перлов: > http://www.openwall.com/lists/kernel-hardening/2017/03/23/3 - "защита" от нападающего > с примитивами arbitrary read+write, доступность которых делает такую и все подобные > "защиты" бесполезными. > http://www.openwall.com/lists/kernel-hardening/2017/04/04/10 - патч, который добавляет > ещё одну ситуацию гонки за запись в память к уже существующей, > от которой по задумке должен защищать. > Почему так происходит? Не выработана и не принята модель угроз, в её > рамках не ведётся системная работа. Сообщество продемонстрировало нежелание или неспособность > критически оценивать ситуацию и формировать спрос на её исправление. А в > свою очередь бизнесу, построенному на базе линукса и СПО, выгодно поддерживать > статус кво, поскольку маркетинг, вводящий в заблуждение на фоне практической неспособности > потребителя оценить искомые качества (безопасность), даёт прибыльность и обходится гораздо > дешевле реальной технической работы.
	Введите код, изображенный на картинке: