Исходное сообщение
"Релиз OpenBSD 4.8" Отправлено paxuser, 02-Ноя-10 21:48
Конечно логика есть. Уж релизы-то подписывать ЭЦП они могли бы, согласитесь. Я вот всё жду, когда же начнут... Даже давний взлом FTP-сервера проекта их, видимо, ничему не научил. А ведь усилий минимум, и не пришлось бы предлагать ерунду о проверке хэшей с разных зеркал. Проблема есть, косвенно признанна, но решение предлагается негодное. Что, если взломщик контролирует канал связи жертвы? В этом случае он может подменить файлы, с каких бы зеркал они запрошены ни были. Но если жертва для проверки целостности файлов применяет настоящий публичный ключ (условимся, что он был успешно получен ранее - например, для проверки файлов предыдущих релизов), то подсадка трояна значительно усложнится. О сложности эксплуатации уязвимостей в ядре OpenBSD (по ссылке об этом тоже написано) - неправда. Корректность кода усложняет поиск уязвимостей, поскольку встречаются они реже, но не их экслпуатацию, оцените сами: http://www.securiteam.com/exploits/5JP092KKAM.html В последних версиях подобный эксплойт работать не будет, потому что в 2009-ом в OpenBSD ввели запрет на маппинги нулевого адреса (кстати, где-то на год позже, чем в ванильном линуксе). То есть, сработает конкретный механизм защиты от эксплуатации, а не некие последствия от аккуратного написания и аудита кода. Ну и вообще, априори склоняться к версии о троянах в установочных файлах - непрофессионально, как минимум. Разработчики OpenBSD не тратят на аудит и толику того времени, которое будет потрачено на поиск уязвимостей взломщиком, который поставит перед собой чёткую цель и не будет стеснён сроками.

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	> Конечно логика есть. Уж релизы-то подписывать ЭЦП они могли бы, согласитесь. Я > вот всё жду, когда же начнут... Даже давний взлом FTP-сервера проекта > их, видимо, ничему не научил. А ведь усилий минимум, и не > пришлось бы предлагать ерунду о проверке хэшей с разных зеркал. > Проблема есть, косвенно признанна, но решение предлагается негодное. Что, если взломщик > контролирует канал связи жертвы? В этом случае он может подменить файлы, > с каких бы зеркал они запрошены ни были. Но если жертва > для проверки целостности файлов применяет настоящий публичный ключ (условимся, что он > был успешно получен ранее - например, для проверки файлов предыдущих релизов), > то подсадка трояна значительно усложнится. > О сложности эксплуатации уязвимостей в ядре OpenBSD (по ссылке об этом тоже > написано) - неправда. Корректность кода усложняет поиск уязвимостей, поскольку встречаются > они реже, но не их экслпуатацию, оцените сами: http://www.securiteam.com/exploits/5JP092KKAM.html > В последних версиях подобный эксплойт работать не будет, потому что в 2009-ом > в OpenBSD ввели запрет на маппинги нулевого адреса (кстати, где-то на > год позже, чем в ванильном линуксе). То есть, сработает конкретный механизм > защиты от эксплуатации, а не некие последствия от аккуратного написания и > аудита кода. > Ну и вообще, априори склоняться к версии о троянах в установочных файлах > - непрофессионально, как минимум. Разработчики OpenBSD не тратят на аудит и > толику того времени, которое будет потрачено на поиск уязвимостей взломщиком, который > поставит перед собой чёткую цель и не будет стеснён сроками.
	Введите код, изображенный на картинке: