vayerx в обоих темах неоднократно высказывал мысль о том, что доля уязвимостей переполнения буфера (aka выполнение произвольного кода, aka доступ к системе, aka повреждение памяти и т.п., обусловенных фон-неймановской архитектурой, предполагающих совместное хранение и обработку данных и кода) столь ничтожна, что преимущество дотнета, заключающееся в том, что в приложениях под ней подобные уязвимости наплодить достаточно сложно, вовсе и не преимущество а так... пшик просто, по сравнению с армадой других уявзимостей, существование которых возможно и в дотнет-приложениях. Из чего делался вывод, что при равных затратах ресурсов, общий уровень безопасности нативных и управляемых приложений, в общем-то, тоже равен. С чем я, разумеется, согласиться не смог.
Я привел в пример статистику с secunia и securityfocus в подтверждение того, что по факту, уязвимости переполнения буфера представляют собой вполне серьезную угрозу, которой не подвержены приложения на управляемых платформах.
</Краткое содержание предыдущих серий>
KV>>Можно один вопрос? Если все так радужно, почему большая часть уязвимостей, обнаруживаемая в ОСях и, скажем — броузерах, относится именно к этому классу уязвимостей (статистика, подтверждающая это есть на secunia.com и securityfocus.com)?
V>О какой именно статистике на secunia.com и securityfocus.com идет речь? Приведите, пожалуйста, конкретные ссылки.
V>Попытаюсь ответить априорно, правда, вопросом на вопрос. Какой процент софта, в котором обнаруженны уязвимости, написан/использует код "олдскульникамов" и/или ansi c? От какого объема софта считается процент (от суммарного во всем мире? от неуправляемого? etc?)? Как именно рассчитвается этот процент (кол-во приложений? кол-во пользователей? суммарное время использования? кол-во строчек кода? etc?)?
В моем сообщении, речь шла о проценте уязвимостей, связанных с переполнением буфера в любом, конкретно взятом приложении по отношению к остальным уязвимостям в этом же продукте. Я думаю, что пользователю этого приложения до одного места, с использованием каких технологий и языков оно написано, ему важно (если вообще важно), чтобы через это приложение его не смогли атаковать. Я не прав?
Ок, возьмем для примера firefox 3.x (это "шоб два раза не ходить" и нарваться тут не только на плюсников, но и на опенсорсников ) — вполне себе современное и весьма популярное приложение, вопросы безопасности которого (в силу хотя бы того, что это веб-браузер) уж явно стоят не на последнем месте как у его разработчиков, так и его пользователей.
Согласно статистике с secunia, за все время существования этой версии, в ней было обнаружено 28 уязвимостей, выразившихся в 7 бюллетенях безопасности. При необходимо учесть, что многие из упомянутых там уязвимостей обусловлены "by multiple errors". Это так, на всякий случай, если кому-то уявзимостей покажется мало И если внимательно изучить каждый бюллетень, то станет понятно, что как минимум в 4 из них:
сообщается об уявзимостях переполнения буфера. А если озадачиться их подсчетом, то окажется, что тот 31% уязвимостей, обозванных secunia'ей в первой ссылке как "system access" и есть уязвимости переполнения буфера.
И получается интересная картина: оказывается, доля уязвимостей переполнения буфера не так уж и мала (больше доли любых других уязвимостей), но вот некоторые плюсники считают что на них все равно можно забить. И что тут есть причина, а что следствие, это еще разобраться надо
P.S: Хочу обратить внимание, что в бюллетене http://secunia.com/advisories/31132/ сообщается об уязвимости переполнения буфера, применимой только к MacOSX. Это чтобы нарваться еще и на юниксоидов и Мамута
Ну что ж интересно и в общем правильно, но раз уж КСВ, так КСВ.
Так что несмотря на то, что сейчас 9 вечера и я еще на работе, все же немного потреплюсь
Доказывать, что доля уязвимостей, связанных с переполнением буфера, якобы, ничтожна я не буду — ибо сам не разделяю такую точку зрения, НО:
1. По поводу фон неймновской архитектуры — в жизни не бывает белого и черного и давно уже нет чистой фон нейманосвкой архитектуры — начиная с кэша, в котором разделяются данные и команды и заканчивая всякими NX флагами страниц памяти.
2. Опять же есть DEP — уже давно и я видел, как он предотвращает выполнение многих эксплойтов.
Таким образом, некоторые атрибуты песочницы появились и в native приложениях.
Следующий момент: уязвимость переполнения буфера бывает очень часто сложно эксплуатировать, потому что заветный адрес зависит от номера сборки, локали и еще бог знает чего — применимость эксплойта резко снижается (хотя есть "интеллектуальные" варианты). А тут еще и ASR...
Ну и еще один момент: возможности приложения ограничены (помним знаменитое "В Linux'е вирусов нет"... по телевизору ) все-таки само приложение уже давно работает в песочнице ОС. Ты можешь возразить, что существует ряд служб, работающих в привилегированном режиме и даже имеющих интерфейсы в ядре — но тут палка о двух концах — не просто так они в ядро полезли (тут надо появится на сцене Sinclair'у и прочитать лекцию о необходимости драйвера http.sys для нормальной работы IIS'а).
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>vayerx в обоих темах неоднократно высказывал мысль о том, что доля уязвимостей переполнения буфера (aka выполнение произвольного кода, aka доступ к системе, aka повреждение памяти и т.п., обусловенных фон-неймановской архитектурой, предполагающих совместное хранение и обработку данных и кода) столь ничтожна, что преимущество дотнета, заключающееся в том, что в приложениях под ней подобные уязвимости наплодить достаточно сложно, вовсе и не преимущество а так... пшик просто, по сравнению с армадой других уявзимостей, существование которых возможно и в дотнет-приложениях. Из чего делался вывод, что при равных затратах ресурсов, общий уровень безопасности нативных и управляемых приложений, в общем-то, тоже равен. С чем я, разумеется, согласиться не смог.
вы либо сильно перевираете сказанное мной, либо крайне невнимательно читали мои комментарии, либо почему-то сделали акцент на "выгодных" себе вещах.
я утверждаю, что эта самая головная боль заметна лишь для ограниченного круга задач. безусловно, полезно, когда защита есть на уровне платформы разработки, но ее отсутствие в общем случае не фатально.
для каждой задачи должно быть четкое понимание того, что делать желательно, необходимо, не нужно. защита от описанных вами уязвимостей, во-первых, нужна/необходима далеко не везде, а, во-вторых, сами описанные уязвимости являются далеко не самыми опасными из числа возможных. снятие головной боли в их отношении, безусловно, приятно, но не является панацеей от всех возможных ошибок
иными словами, процесс разрботки большого количества ПО встречается с гораздо более сложными проблемами, нежели защита от уязвимостей — далеко не всему ПО необходима защита.
ибо защита "от всего на свете" требует дополнительных человекомесяцев, а это — деньги.
то, что код "Код, позволяющий произвольно и недетерминированно изменять собственную логику выполнения через передачу ему неожидаемые входных данных, не является работающим кодом", в общем случае, неверно:
такое поведение кода можно отнести к нецелевому использованию ПО. это отчасти напоминает байку о том, что если кухонным комбайном выстрелить из катапульты, он перестает работать.
KV>>>Можно один вопрос? Если все так радужно, почему большая часть уязвимостей, обнаруживаемая в ОСях и, скажем — броузерах, относится именно к этому классу уязвимостей (статистика, подтверждающая это есть на secunia.com и securityfocus.com)?
V>>О какой именно статистике на secunia.com и securityfocus.com идет речь? Приведите, пожалуйста, конкретные ссылки.
V>>Попытаюсь ответить априорно, правда, вопросом на вопрос. Какой процент софта, в котором обнаруженны уязвимости, написан/использует код "олдскульникамов" и/или ansi c? От какого объема софта считается процент (от суммарного во всем мире? от неуправляемого? etc?)? Как именно рассчитвается этот процент (кол-во приложений? кол-во пользователей? суммарное время использования? кол-во строчек кода? etc?)?
KV>В моем сообщении, речь шла о проценте уязвимостей, связанных с переполнением буфера в любом, конкретно взятом приложении по отношению к остальным уязвимостям в этом же продукте. Я думаю, что пользователю этого приложения до одного места, с использованием каких технологий и языков оно написано, ему важно (если вообще важно), чтобы через это приложение его не смогли атаковать. Я не прав?
Вы неправы потому, что либо притянули за уши мое высказывание к оспариваемой вами теме, либо не учитываете тот факт, что огромной части пользователей "до одного места", будут ли его приложение атаковать (части из них пофиг ибо обоснованно считают, что никому в здравом уме не прийдет в голову атаковать контроллер их пылесоса, а вторая часть не парится до того момента, пока пятух не клюнет).
KV>И получается интересная картина: оказывается, доля уязвимостей переполнения буфера не так уж и мала (больше доли любых других уязвимостей), но вот некоторые плюсники считают что на них все равно можно забить. И что тут есть причина, а что следствие, это еще разобраться надо ;)
Надеюсь, вы не вписываете меня в ряды тех, кто считает что уязвимости можно забить? Напомню еше раз этого я никогда не говорил. Или вам кажется малозаметным нюанс между "никогда и не при каких условиях не исправлять уязвимости ни в каком ПО" и "уязвимости в некотором ПО вполне допустимы, а защищать необходимо нужно то, что защищать необходимо, но не более того =)"? И именно из-за этого нюанса, видимо, и возник спор о серебрянной пуле, лечащей сразу все прострелянные ноги.
И еще раз напомню, что я ни коем образом не умаляю достоинства управляемых платформ, а, скорее даже наоборот, как неоднократно писал, считаю их гораздо более примеными для большого спектра задач.
V>либо не учитываете тот факт, что огромной части пользователей "до одного места", будут ли его приложение атаковать (части из них пофиг ибо обоснованно считают, что никому в здравом уме не прийдет в голову атаковать контроллер их пылесоса, а вторая часть не парится до того момента, пока пятух не клюнет).
А вот тут не прав ты — заражение компьютера пользователя вредоносным ПО в 99% случаев не наносит прямого вреда самому пользователю, но то, что через него например идут тонны спама или проводятся DDoS атаки причиняет очень серьезный ущерб, который имеет вполне себе измеримое материальное выражение и размеры этого "материального выражения" явно не сопоставимы с пресловутыми дополнительными затратами на обеспечение безопасности приложения.
Про так называемые "ключевые системы инфраструктуры" (ака АСУ ТП) я просто молчу.
Здравствуйте, DOOM, Вы писали:
V>>либо не учитываете тот факт, что огромной части пользователей "до одного места", будут ли его приложение атаковать (части из них пофиг ибо обоснованно считают, что никому в здравом уме не прийдет в голову атаковать контроллер их пылесоса, а вторая часть не парится до того момента, пока пятух не клюнет). DOO>А вот тут не прав ты — заражение компьютера пользователя вредоносным ПО в 99% случаев не наносит прямого вреда самому пользователю, но то, что через него например идут тонны спама или проводятся DDoS атаки причиняет очень серьезный ущерб, который имеет вполне себе измеримое материальное выражение и размеры этого "материального выражения" явно не сопоставимы с пресловутыми дополнительными затратами на обеспечение безопасности приложения. DOO>Про так называемые "ключевые системы инфраструктуры" (ака АСУ ТП) я просто молчу.
а это тут при чем? разве я где-то агитировал абслоютно всегда забивать не безопасность? зачем в данном контексте сравнивать стоимость обеспечения безопасности и потенциального урона?
если же обсуждать коммерческую сторону, то можно прикинуть риски для каждого конкретного случая. распределение вероятности ататки на каждое приложение варьируется от бесконечно низкой до асиптотичски 100%. потенциальн урон от успешной атаки также лежит в широком диапазоне. вот и получается, что в каких-то случаях ставить управляемую платформу в контроллере пылесоса вряд ли окупится, а вот в популярно браузере — безусловно.
Здравствуйте, vayerx, Вы писали:
V>Здравствуйте, DOOM, Вы писали:
V>>>либо не учитываете тот факт, что огромной части пользователей "до одного места", будут ли его приложение атаковать (части из них пофиг ибо обоснованно считают, что никому в здравом уме не прийдет в голову атаковать контроллер их пылесоса, а вторая часть не парится до того момента, пока пятух не клюнет). DOO>>А вот тут не прав ты — заражение компьютера пользователя вредоносным ПО в 99% случаев не наносит прямого вреда самому пользователю, но то, что через него например идут тонны спама или проводятся DDoS атаки причиняет очень серьезный ущерб, который имеет вполне себе измеримое материальное выражение и размеры этого "материального выражения" явно не сопоставимы с пресловутыми дополнительными затратами на обеспечение безопасности приложения. DOO>>Про так называемые "ключевые системы инфраструктуры" (ака АСУ ТП) я просто молчу.
V>а это тут при чем? разве я где-то агитировал абслоютно всегда забивать не безопасность? зачем в данном контексте сравнивать стоимость обеспечения безопасности и потенциального урона?
Я где-то сказал про агитацию против безопасности? Я лишь указал, что ты не прав, принимая во внимание мнение конечного пользователя. А еще бизнесу вообще пофиг на защиту персональных данных — но тут его государство потихоньку нагибает
V>если же обсуждать коммерческую сторону, то можно прикинуть риски для каждого конкретного случая. распределение вероятности ататки на каждое приложение варьируется от бесконечно низкой до асиптотичски 100%. потенциальн урон от успешной атаки также лежит в широком диапазоне. вот и получается, что в каких-то случаях ставить управляемую платформу в контроллере пылесоса вряд ли окупится, а вот в популярно браузере — безусловно.
Ставить управляемую платформу в контроллере пылесоса как раз выгодно Но из других соображений...
Здравствуйте, DOOM, Вы писали:
V>>а это тут при чем? разве я где-то агитировал абслоютно всегда забивать не безопасность? зачем в данном контексте сравнивать стоимость обеспечения безопасности и потенциального урона? DOO>Я где-то сказал про агитацию против безопасности? Я лишь указал, что ты не прав, принимая во внимание мнение конечного пользователя. А еще бизнесу вообще пофиг на защиту персональных данных — но тут его государство потихоньку нагибает :xz:
А вы много пользователей взломанных пылесосов знаете? ;)
DOO>Ставить управляемую платформу в контроллере пылесоса как раз выгодно :) Но из других соображений...
даже если там, к примеру, всего суммарно 1 кб памяти? ;)
Здравствуйте, vayerx, Вы писали:
V>А вы много пользователей взломанных пылесосов знаете?
да я и не густо пылесосов с выходом в иннет знаю
DOO>>Ставить управляемую платформу в контроллере пылесоса как раз выгодно Но из других соображений...
V>даже если там, к примеру, всего суммарно 1 кб памяти?
А что и такие бывают?
Когда-то вообще целесообразнее было реализовать все аппаратно, потом дешевле стало поставить программиуемый контроллер, ну а сейчас дешевле поставить процессор, память, JVM и писать на Java на все модели пылесосов разом.
Здравствуйте, DOOM, Вы писали:
V>>А вы много пользователей взломанных пылесосов знаете? ;) DOO>да я и не густо пылесосов с выходом в иннет знаю :xz:
а про иннет разве кто-то что-то говорил? ;) в своем начальном опусе товарищ kochetkov.vladimir усмотрел фатальную ущербность в архитекутре фон-Неймана и упорно доказывал что все в мире ПО, включая стандартный калькулятор в windows, в обязательном порядке должно быть защищенно и, в первую очередь, от атак в виде инъекций кода вне зависимости от того, подключен ли компьютер к сети или нет.
Здравствуйте, vayerx, Вы писали:
V>а про иннет разве кто-то что-то говорил? в своем начальном опусе товарищ kochetkov.vladimir усмотрел фатальную ущербность в архитекутре фон-Неймана и упорно доказывал что все в мире ПО, включая стандартный калькулятор в windows, в обязательном порядке должно быть защищенно и, в первую очередь, от атак в виде инъекций кода вне зависимости от того, подключен ли компьютер к сети или нет.
Хорошо, почему тогда речь только о взломе? Можно же еще стабильность рассмотреть — в общем случае, действительно, у приложения в песочнице проще добиться стабильной работы.
Возвращаясь к моему первому посту в этой теме:
можно же отказаться от MMU у процессора — общаться с ним в реальном режиме — это даже резко упрощает написание программ (системных правда), но тут есть НО: стабильность работы программы начинает зависеть от кривизны (или прямоты) рук создателей абсолютно левых программ — начиная от драйвера мышки и заканчивая скрин сейвером
[многабукоф]
KV>Ну вот, пожалуй и все. Можете рвать
Ну, рвать — не рвать, но контр-аргументов я парочку добавлю.
1. "Стоимость" необнаруженной уязвимости в управляемом фреймворке значительно превышает такую "стоимость" узявимости в нативном коде — за счёт масштабов распространения и унификации. Так что в "мат. ожидание" вреда (= вероятность уязвимости * вред от неё), полагаю, для двух наиболее популярных фреймворков повыше, чем для отдельного нативного приложения.
2. Тенденции в отрасли таковы, что с каждым годом доля одиночных приложений будет только уменьшаться в пользу серверных (термин cloud computing мне не очень нравится, но пусть будет). И чем дальше, тем в большей степени это всё будет поддерживаться на аппаратном уровне. Соответственно, фоннеймовская архитектура в обозримом будущем если и не уйдёт в небытие, то очень сильно сдаст свои позиции — так что не будет самого предмета спора. С этой точки зрения фреймворки в плане безопасности выглядят как временные костыли, возможно даже и препятствующие эффективной защите.
Курица — это инструмент, с помощью которого одно яйцо производит другие.
Здравствуйте, vayerx, Вы писали: V>даже если там, к примеру, всего суммарно 1 кб памяти?
Это малореально по практическим соображениям — 1кб памяти обойдется тебе сейчас дороже, чем 1MB.
Поэтому про эти вырожденные случаи лучше забыть и попрочнее.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
KV>P.S: Хочу обратить внимание, что в бюллетене http://secunia.com/advisories/31132/ сообщается об уязвимости переполнения буфера, применимой только к MacOSX. Это чтобы нарваться еще и на юниксоидов и Мамута
Ж)
На МакОСИ все это усугубляется сильной непрозрачностью процеса выпуска патчей. То есть если с Мозиллой все понятно — они-то могут среагировать и апдейтнуть, то с официальными Эппловскими продуктами не все так радужно. Часто security updates выходят с одной строчкой типа «fixed numerous issues» — и все
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, vayerx, Вы писали: V>>даже если там, к примеру, всего суммарно 1 кб памяти? ;) S>Это малореально по практическим соображениям — 1кб памяти обойдется тебе сейчас дороже, чем 1MB. S>Поэтому про эти вырожденные случаи лучше забыть и попрочнее.
вообще, про 1 кб, как, впрочем, и про пылесос, я в шутку написал, но, как говориться, холиварить — так холиварить =)
открываем сайт Чип и Дип и смотрим:
разумеется, навеска отличается, но зачем она нашему пылесосу? =) тем не менее, тенденция цен заметна?
можно, безусловно, ставить внешнюю память. но нафига? ;)
Здравствуйте, DOOM, Вы писали:
DOO>Здравствуйте, kochetkov.vladimir, Вы писали:
DOO>Ну что ж интересно и в общем правильно, но раз уж КСВ, так КСВ.
Нет чтобы просто плюсик поставить...
DOO>Так что несмотря на то, что сейчас 9 вечера и я еще на работе, все же немного потреплюсь
Ну щас хоть и не 9 вечера, но зато суббота, а я все еще на работе, так что квиты :-Р
DOO>1. По поводу фон неймновской архитектуры — в жизни не бывает белого и черного и давно уже нет чистой фон нейманосвкой архитектуры — начиная с кэша, в котором разделяются данные и команды и заканчивая всякими NX флагами страниц памяти.
Ну, то что в кэше данные и код разделены от атак на содержимое оперативной памяти ведь слабо влияет? По поводу NX-флагов, недавно прочел, что в Google Chrome они вовсю используются, причем это преподносилось почти как killer-фича по отношению к остальным браузерам. Это действительно так? В смысле, что в FF, IE и Opera они не используются? Я чего-то об этом инфы не нашел
DOO>2. Опять же есть DEP — уже давно и я видел, как он предотвращает выполнение многих эксплойтов.
Я видел буквально у себя на ноутбуке. Но тут есть две проблемы: DEP (в XP, по крайней мере) надо еще включить, чтобы он на все приложения, а не только на ОС работал. А во-вторых, нужно быть готовым, что некоторые приложения после его включения отвалятся сами собой и их придется добавлять в исключения. У меня такая фигня была с архиполезной (для меня) утилиткой kleptomania
DOO>Таким образом, некоторые атрибуты песочницы появились и в native приложениях.
Тут сложно спорить, можно только добавить, что есть еще thinstall, sandboxie и им подобные. Под виндой, по крайней мере.
DOO>Следующий момент: уязвимость переполнения буфера бывает очень часто сложно эксплуатировать, потому что заветный адрес зависит от номера сборки, локали и еще бог знает чего — применимость эксплойта резко снижается (хотя есть "интеллектуальные" варианты). А тут еще и ASR...
Тоже есть такое дело, но есть и забавные воркарраунды. Например, когда фишеры атакуют юзеров с целью подсадить им спам-бота или руткит по "вредоносной ссылке", они на ту сторону ссылки ставят скрипт, анализирующий http-заголовок на предмет ОС и броузера, и возвращают страницу с нужным эксплоитом.
DOO>Ну и еще один момент: возможности приложения ограничены (помним знаменитое "В Linux'е вирусов нет"... по телевизору ) все-таки само приложение уже давно работает в песочнице ОС.
+ AppArmor +SELinux + UAC +всевозможные мониторы системных вызвов (забыл как класс ПО называется) и т.п. Но это именно то, что я назвал в той сказке "костылями"
DOO>Ты можешь возразить, что существует ряд служб, работающих в привилегированном режиме и даже имеющих интерфейсы в ядре — но тут палка о двух концах — не просто так они в ядро полезли (тут надо появится на сцене Sinclair'у и прочитать лекцию о необходимости драйвера http.sys для нормальной работы IIS'а).
Че-то нету Sinclair'a Но тот топик смутно помню, надо будет поискать.
я утверждаю, что эта самая головная боль заметна лишь для ограниченного круга задач. безусловно, полезно, когда защита есть на уровне платформы разработки, но ее отсутствие в общем случае не фатально.
Не фатально. Но если защиты на уровне платформы нет, а защита все же нужна (а она нужна), то ее придется реализовывать на уровне приложения. А это, как минимум, дороже. Либо писать код так, чтобы свести к минимуму вероятность возникновения необходимости в этой защите. Я — говорю о втором, а вы (судя по всему) — о первом.
V>иными словами, процесс разрботки большого количества ПО встречается с гораздо более сложными проблемами, нежели защита от уязвимостей — далеко не всему ПО необходима защита.
Что в вашем понимании есть эта самая "защита"? Чтоб быть уверенным, что мы об одном и том же говорим.
V>то, что код "Код, позволяющий произвольно и недетерминированно изменять собственную логику выполнения через передачу ему неожидаемые входных данных, не является работающим кодом", в общем случае, неверно:
такое поведение кода можно отнести к нецелевому использованию ПО. это отчасти напоминает байку о том, что если кухонным комбайном выстрелить из катапульты, он перестает работать.
Пример про комбайн — некорректен, т.к. вы говорите о том, что может/не может должен/не должен делать с ним его же пользователь. В случае же с ПО, векторы воздействия на него, далеко не всегда ограничиваются только возможностями и желанием его пользователей.
KV>>И получается интересная картина: оказывается, доля уязвимостей переполнения буфера не так уж и мала (больше доли любых других уязвимостей), но вот некоторые плюсники считают что на них все равно можно забить. И что тут есть причина, а что следствие, это еще разобраться надо
V>Надеюсь, вы не вписываете меня в ряды тех, кто считает что уязвимости можно забить? Напомню еше раз этого я никогда не говорил. Или вам кажется малозаметным нюанс между "никогда и не при каких условиях не исправлять уязвимости ни в каком ПО" и "уязвимости в некотором ПО вполне допустимы, а защищать необходимо нужно то, что защищать необходимо, но не более того =)"?
Вот потом и появляются (после выделенного) многофакторные атаки типа того cover bombing через уязвимости в safari и IE
Если следовать вашим словам, то разработчики калькулятора (продолжая тему про гипотетическую уязвимость в нем) должны рассуждать так: "ну и что, что вставив из буфера malformed-строку можно выполнить произвольный код? это ж все локально, по сети данные из клипбоарда-то нельзя принять? да и если выполнится этот код, он жеж выполнится с правами пользователя? а зачем пользователю, имеющему права на выполнение кода (он же как-то запускает калькулятор) выполнять его таким экзотическим способом? Ну ок, присвоим этой уязвимости статус некритичной и закроем в следующей версии".
В то же время, разработчики одного популярного броузера (а это уже реальный пример) думают так: "ну и что, что через JS-скрипт в нашем продукте можно подсунуть произвольные данные в клипбоард? они ведь все равно просто вставятся, и не выполнятся автоматически? ну, ок — некритическая уязвимость, закроем при следующем плановом апдейте)
И в то же самое время (тоже реальный пример), разработчики ядра ОС, по тем же самым соображениям, обзывают обнаруженную уязвимость повышения привилегий в системе "средним риском", потому как она не удаленная. А следовательно и исправить ее тоже можно в плановом порядке.
И т.д. и т.п. И масса таких вот "допущений" со стороны производителей ПО делается ежемесячно. Между тем, любой эксперт по безопасности, уже на основании перечисленных трех допущений, сможет построить довольно ветвистое дерево удаленной многофакторной атаки на полную компрометацию системы. А разработчикам ПО — пофиг, их же уязвимости "некритические", значит во всем виноваты "счастливчики", в чьем продукте обнаруживается "средняя" уязвимость. И все дружно дают пендалей группе разработки ядра Windows
Здравствуйте, vayerx, Вы писали:
V>Здравствуйте, DOOM, Вы писали:
V>>>А вы много пользователей взломанных пылесосов знаете? DOO>>да я и не густо пылесосов с выходом в иннет знаю
V>а про иннет разве кто-то что-то говорил? в своем начальном опусе товарищ kochetkov.vladimir усмотрел фатальную ущербность в архитекутре фон-Неймана и упорно доказывал что все в мире ПО, включая стандартный калькулятор в windows, в обязательном порядке должно быть защищенно и, в первую очередь, от атак в виде инъекций кода вне зависимости от того, подключен ли компьютер к сети или нет.
И это я ваши слова перевираю? По-моему, мой пример с калькулятором явным образом предполагал, что компьютер пользователя подключен к сети
) — вполне себе современное и весьма популярное приложение, вопросы безопасности которого (в силу хотя бы того, что это веб-браузер) уж явно стоят не на последнем месте как у его разработчиков, так и его пользователей.
