Comments 6
Среднее время закрытия уязвимостей для коммерческих компаний — 295 дней
Жуть какая… Мне кажется, на закрытие уязвимостей должно даваться не больше недели.
Почему?
Потому что уязвимости по своему определению представляют опасность для конечного пользователя продукта. Найденная и отрепорченая уязвимость может быть найдена кем-то ещё, кто захочет её экспулатировать.
После звонка о заложенной бомбе здание эвакуируют сразу, а не ждут 295 дней…
После звонка о заложенной бомбе здание эвакуируют сразу, а не ждут 295 дней…
Ну а если взглянуть так:
Ну нашел кто-то XSS в каком-то портале Oracle, который используют в корп. сегменте и которая редко где торчит в инте. Какой риск от этой XSS? Такой проблеме ставят приоритет, и фиксят в следующем минор релизе, который может быть и через пол года… и всем
Аналогия с бомбой немного не верна.
Понимаете, БОЛЬШЕНСТВО уязвимостей, это либо не эксплуатируемый треш, либо риск такой мизерный что рвать что-то и менять слишком дорого и проще исправить в не спешном порядке. Это причина 1.
Причина 2. Допустим в IE нашли уязвимость. Потенциальное выполнение кода, но ПоКа нет. А даже если есть, то DoS. Вроде в потенциале риск большой. И тут MS дают время — неделя! Конечно, за неделю зафиксить dangling pointer в нескольких билдах IE (32/64/Arm) проверить все это на различных ОС — XP/7/8/WP8. И на это неделя? Как бы хуже не было от таких фиксов 8) Функциональность важнее потенциального ущерба в определенном пределе.
Вывод: понятие «уязвимость» — это ужасно. Оно НИ О ЧЕМ НЕ говорит ни вендору ни пользователям, потому что для каждой такой уязвимости разные риски, вероятности и возможности. Отсюда мораль — разработчику и стейкхолдеру виднее. Есть конечно запущенные случаи, когда вендор НЕ ПОНИМАЕТ о чем речь, но это не о SAP/Oracle/MS и прочих ребят, у которых есть понимание вещей. Так что неделя в общем случае — не верно. «Неделя» — может быть в случае критических вещей, с неслабым импактом и тотальным пывном, когда это в паблике УЖЕ и то… зависит от ситуации 8)
Ну нашел кто-то XSS в каком-то портале Oracle, который используют в корп. сегменте и которая редко где торчит в инте. Какой риск от этой XSS? Такой проблеме ставят приоритет, и фиксят в следующем минор релизе, который может быть и через пол года… и всем
Аналогия с бомбой немного не верна.
Понимаете, БОЛЬШЕНСТВО уязвимостей, это либо не эксплуатируемый треш, либо риск такой мизерный что рвать что-то и менять слишком дорого и проще исправить в не спешном порядке. Это причина 1.
Причина 2. Допустим в IE нашли уязвимость. Потенциальное выполнение кода, но ПоКа нет. А даже если есть, то DoS. Вроде в потенциале риск большой. И тут MS дают время — неделя! Конечно, за неделю зафиксить dangling pointer в нескольких билдах IE (32/64/Arm) проверить все это на различных ОС — XP/7/8/WP8. И на это неделя? Как бы хуже не было от таких фиксов 8) Функциональность важнее потенциального ущерба в определенном пределе.
Вывод: понятие «уязвимость» — это ужасно. Оно НИ О ЧЕМ НЕ говорит ни вендору ни пользователям, потому что для каждой такой уязвимости разные риски, вероятности и возможности. Отсюда мораль — разработчику и стейкхолдеру виднее. Есть конечно запущенные случаи, когда вендор НЕ ПОНИМАЕТ о чем речь, но это не о SAP/Oracle/MS и прочих ребят, у которых есть понимание вещей. Так что неделя в общем случае — не верно. «Неделя» — может быть в случае критических вещей, с неслабым импактом и тотальным пывном, когда это в паблике УЖЕ и то… зависит от ситуации 8)
А что на Адаптация техники JIT-Spray (2010) нет ссылки?
dsecrg.com/files/pub/pdf/HITB%20-%20JIT-Spray%20Attacks%20and%20Advanced%20Shellcode.pdf
dsecrg.com/files/pub/pdf/Writing%20JIT-Spray%20Shellcode%20for%20fun%20and%20profit.pdf
Старье уже. но забавно вспоминать… эххх… молодость… время было ковыряться)
dsecrg.com/files/pub/pdf/HITB%20-%20JIT-Spray%20Attacks%20and%20Advanced%20Shellcode.pdf
dsecrg.com/files/pub/pdf/Writing%20JIT-Spray%20Shellcode%20for%20fun%20and%20profit.pdf
Старье уже. но забавно вспоминать… эххх… молодость… время было ковыряться)
Sign up to leave a comment.
Результаты работы исследовательской лаборатории Digital Security за 5 лет