The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Индекс форумов
Составление сообщения

Исходное сообщение
"Удалённая уязвимость в IPv6-стеке OpenBSD"
Отправлено Дон Ягон, 31-Окт-20 22:05 
> Строгий контроль со стороны процессора и ядра OS -- единственное решение которое дает гарантии невозможности эксплуатации уязвимостей.

В твоих устах это больше похоже на религиозную мантру, чем на аргумент. Баги и дыры есть и в процессорах и в средствах защиты в ОС. Али local root в grsec-патчах (которого не было в ванильном linux, CVE-2007-0257) уже забылся? Или kernel panic в нём же (https://xakep.ru/2016/04/28/grsecurity-ban/)? Или забылся dirty cow, который успешно эксплуатировался даже с включёнными pax-патчами? Про новомодные meltdown и его друзей как-то даже напоминать неудобно.

> Плевать на программистов, языки программирования и компиляторы.

Нет. Профессионализм программистов и правильно выбранные средства гораздо важнее.

> Ошибки - были, есть и будут

Ага. И ловить их, по-возможности, лучше не в рантайме, а на стадии компиляции. Или хотя бы в какой-то тестовой среде. Вмешиваться в работу прикладных программ или модулей/компонентов ядра всяческими "проактивными средствами защиты" нужно как можно аккуратнее, ибо можно замедлить приложение/ядро. Или обрушить его. Или всё будет +/- ок, но портирование ядерной защиты на другую архитектуру будет неадекватно сложно.

Почитай, ради интереса, как Попов из PT переносил PAX_STACKLEAK из остатков grsec-патчей в ванильное ядро (на русском, например, тут - https://habr.com/ru/company/pt/blog/424633/ + в коментариях есть полезные ссылки на lwn). И высказывания линуса и шпенглера по поводу этих патчей (выдержке попова можно только позавидовать, не каждый довёл бы пусть и нужное дело до конца под таким давлением. он большой молодец, как по мне). И сроки выполнения работ оцени.

Не всё так просто и однозначно, короче.

> Они уже есть. Надо их просто использовать. Почему в дистрибутивах не используют средства защиты от разных уязвимостей, а вместо этого внедряют средства препятствующие защите: JIT, ...?

У тебя какая-то болезненая фиксация на jit. В то время как это вполне законный способ ускорить транслируемые языки (стандарт позволяет). Да и не всякий jit требует W|X, некоторые, типа того, что у мозиллы, требует только возможности переключений RW -> RX, что _значительно_ лучше.
А та же java, например, хотя и требует W|X, зато достаточно быстра и предотвращает многие типовые проблемы в безопасности приложений.
И, самое главное, есть востребованные бизнесом приложения на той же java.
Это ты можешь собрать себе дистрибутив без jit вообще, если у тебя много свободного времени, а бизнес не будет переписывать решение c java на что-то там ещё, если решение на java их устраивает. Ради чего просто? Ради иллюзии безопасности?
При таких раскладах проще уж будет, имхо, вложиться в аудит и поиск дыр в условном jvm дабы пофиксить их - в конце концов, реализация jit даже и требующая W|X может и не иметь в себе эксплуатируемых уязвимостей.

 

Ваше сообщение
Имя*:
EMail:
Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email).
Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:
  Введите код, изображенный на картинке: КОД
 
При общении не допускается: неуважительное отношение к собеседнику, хамство, унизительное обращение, ненормативная лексика, переход на личности, агрессивное поведение, обесценивание собеседника, провоцирование флейма голословными и заведомо ложными заявлениями. Не отвечайте на сообщения, явно нарушающие правила - удаляются не только сами нарушения, но и все ответы на них. Лог модерирования.



Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру