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. Это чтобы нарваться еще и на юниксоидов и Мамута
Здравствуйте, vayerx, Вы писали: V>даже если там, к примеру, всего суммарно 1 кб памяти?
Это малореально по практическим соображениям — 1кб памяти обойдется тебе сейчас дороже, чем 1MB.
Поэтому про эти вырожденные случаи лучше забыть и попрочнее.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
я утверждаю, что эта самая головная боль заметна лишь для ограниченного круга задач. безусловно, полезно, когда защита есть на уровне платформы разработки, но ее отсутствие в общем случае не фатально.
Не фатально. Но если защиты на уровне платформы нет, а защита все же нужна (а она нужна), то ее придется реализовывать на уровне приложения. А это, как минимум, дороже. Либо писать код так, чтобы свести к минимуму вероятность возникновения необходимости в этой защите. Я — говорю о втором, а вы (судя по всему) — о первом.
V>иными словами, процесс разрботки большого количества ПО встречается с гораздо более сложными проблемами, нежели защита от уязвимостей — далеко не всему ПО необходима защита.
Что в вашем понимании есть эта самая "защита"? Чтоб быть уверенным, что мы об одном и том же говорим.
V>то, что код "Код, позволяющий произвольно и недетерминированно изменять собственную логику выполнения через передачу ему неожидаемые входных данных, не является работающим кодом", в общем случае, неверно:
такое поведение кода можно отнести к нецелевому использованию ПО. это отчасти напоминает байку о том, что если кухонным комбайном выстрелить из катапульты, он перестает работать.
Пример про комбайн — некорректен, т.к. вы говорите о том, что может/не может должен/не должен делать с ним его же пользователь. В случае же с ПО, векторы воздействия на него, далеко не всегда ограничиваются только возможностями и желанием его пользователей.
KV>>И получается интересная картина: оказывается, доля уязвимостей переполнения буфера не так уж и мала (больше доли любых других уязвимостей), но вот некоторые плюсники считают что на них все равно можно забить. И что тут есть причина, а что следствие, это еще разобраться надо
V>Надеюсь, вы не вписываете меня в ряды тех, кто считает что уязвимости можно забить? Напомню еше раз этого я никогда не говорил. Или вам кажется малозаметным нюанс между "никогда и не при каких условиях не исправлять уязвимости ни в каком ПО" и "уязвимости в некотором ПО вполне допустимы, а защищать необходимо нужно то, что защищать необходимо, но не более того =)"?
Вот потом и появляются (после выделенного) многофакторные атаки типа того cover bombing через уязвимости в safari и IE
Если следовать вашим словам, то разработчики калькулятора (продолжая тему про гипотетическую уязвимость в нем) должны рассуждать так: "ну и что, что вставив из буфера malformed-строку можно выполнить произвольный код? это ж все локально, по сети данные из клипбоарда-то нельзя принять? да и если выполнится этот код, он жеж выполнится с правами пользователя? а зачем пользователю, имеющему права на выполнение кода (он же как-то запускает калькулятор) выполнять его таким экзотическим способом? Ну ок, присвоим этой уязвимости статус некритичной и закроем в следующей версии".
В то же время, разработчики одного популярного броузера (а это уже реальный пример) думают так: "ну и что, что через JS-скрипт в нашем продукте можно подсунуть произвольные данные в клипбоард? они ведь все равно просто вставятся, и не выполнятся автоматически? ну, ок — некритическая уязвимость, закроем при следующем плановом апдейте)
И в то же самое время (тоже реальный пример), разработчики ядра ОС, по тем же самым соображениям, обзывают обнаруженную уязвимость повышения привилегий в системе "средним риском", потому как она не удаленная. А следовательно и исправить ее тоже можно в плановом порядке.
И т.д. и т.п. И масса таких вот "допущений" со стороны производителей ПО делается ежемесячно. Между тем, любой эксперт по безопасности, уже на основании перечисленных трех допущений, сможет построить довольно ветвистое дерево удаленной многофакторной атаки на полную компрометацию системы. А разработчикам ПО — пофиг, их же уязвимости "некритические", значит во всем виноваты "счастливчики", в чьем продукте обнаруживается "средняя" уязвимость. И все дружно дают пендалей группе разработки ядра Windows
Здравствуйте, roman10, Вы писали:
R>А если бы "лису" писали на дотнете, их бы не было.
И бОльшей части пользователей лисы — тоже.
Вы хоть один браузер на .net видели?
R>Представим такую ситуацию. Мы настраиваем рабочее место в Интернет-кафе. Чтобы пользователи не натворили дел, запрещаем запуск regedit. Но доступ к calc.exe оставляем, мало ли кому что посчитать захочется. Но: преположим, в ТЗ к калькулятору не было требования обеспечить устойчивость к атакам. Ведь его можно отнести к "прикладным математическим пакетам, не содержащего сетевых компонентов". И если в нем оставили баг с переполнением, то у посетителя появляется возможность писать в реестр все, что угодно.
Если пользователь может скачать и запустить что либо у него тоже есть доступ к реестру.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, kochetkov.vladimir, Вы писали:
V>>а про иннет разве кто-то что-то говорил? ;) в своем начальном опусе товарищ kochetkov.vladimir усмотрел фатальную ущербность в архитекутре фон-Неймана и упорно доказывал что все в мире ПО, включая стандартный калькулятор в windows, в обязательном порядке должно быть защищенно и, в первую очередь, от атак в виде инъекций кода вне зависимости от того, подключен ли компьютер к сети или нет. KV>И это я ваши слова перевираю? По-моему, мой пример с калькулятором явным образом предполагал, что компьютер пользователя подключен к сети :xz:
в каком именно месте это предполагалось? цитату в студию.
с фон-Нейманом сеть как связанна?
V>>
я утверждаю, что эта самая головная боль заметна лишь для ограниченного круга задач. безусловно, полезно, когда защита есть на уровне платформы разработки, но ее отсутствие в общем случае не фатально.
KV>Не фатально. Но если защиты на уровне платформы нет, а защита все же нужна (а она нужна), то ее придется реализовывать на уровне приложения.
вы, прошу прощения, читать умеете? а внимательно?
V>>иными словами, процесс разрботки большого количества ПО встречается с гораздо более сложными проблемами, нежели защита от уязвимостей — далеко не всему ПО необходима защита. KV>Что в вашем понимании есть эта самая "защита"? Чтоб быть уверенным, что мы об одном и том же говорим.
под "защитой от уязвимостей" я предполагаю обеспечение полноого или частичного предотвращения потенциальных вредоносных действий в отношении программы, приводящих к утечке инофрормации, получению управления над системой или ее частью и т.д.
V>>то, что код "Код, позволяющий произвольно и недетерминированно изменять собственную логику выполнения через передачу ему неожидаемые входных данных, не является работающим кодом", в общем случае, неверно:
такое поведение кода можно отнести к нецелевому использованию ПО. это отчасти напоминает байку о том, что если кухонным комбайном выстрелить из катапульты, он перестает работать.
KV>Пример про комбайн — некорректен, т.к. вы говорите о том, что может/не может должен/не должен делать с ним его же пользователь. В случае же с ПО, векторы воздействия на него, далеко не всегда ограничиваются только возможностями и желанием его пользователей.
пример с комбайном вполне корректен. "векторы воздействия не всегда ограничиваются только возможностями и желанием его пользователей", ровно как и ограничиваются только возможностями и желанием его пользователей.
если придираться к словам, то стрелять комбайном может не сам пользователь, а злоумышленник — вам от этого легче?
если же все ж таки переходить к более осмысленному обсуждению, то давайте обсудим является ли "защита" фичей приложения (в каких-то случаях — необходимой, в каких-то — опциональной) или же она является неотъемлемой его частью абсолютно всегда.
V>>вам кажется малозаметным нюанс между "никогда и не при каких условиях не исправлять уязвимости ни в каком ПО" и "уязвимости в некотором ПО вполне допустимы, а защищать необходимо нужно то, что защищать необходимо, но не более того =)"? KV>Вот потом и появляются (после выделенного) многофакторные атаки типа того cover bombing через уязвимости в safari и IE :maniac:
вы передергиваете. вы сами отнесли "safari и ie" к ПО "уязвимости в котором вполне допустимы".
KV>Если следовать вашим словам, то разработчики калькулятора (продолжая тему про гипотетическую уязвимость в нем) должны рассуждать так: "ну и что, что вставив из буфера malformed-строку можно выполнить произвольный код? это ж все локально, по сети данные из клипбоарда-то нельзя принять? да и если выполнится этот код, он жеж выполнится с правами пользователя? а зачем пользователю, имеющему права на выполнение кода (он же как-то запускает калькулятор) выполнять его таким экзотическим способом? Ну ок, присвоим этой уязвимости статус некритичной и закроем в следующей версии".
Примерно так. См. пример с комбайном. Имхо, калькулятор относится именно к тому софту, в котором закрывать дыры если и нужно, то явно постфактум (разумеется, тут следует помнить о допущении: возвращаясь, к исходной теме, именно калькулятор, скорее всего, проще писать на управлямой платформе). для этого есть, как минимум, две предпосылки: специально тратить силы на создание пуленепробиваемого калькулятора (я говорю не только об инъекциях кода) требует больших трудозатрат/денег; защита системы в целом возлагается на файрвол, антивирус, адмистратора и т.д., но никак не поголовно на каждый калькулятор.
KV>Все понял, мы действительно о разных вещах говорим. Вы говорите о защите сферических и обособленных приложений от информационных угроз в вакууме. Т.е. рассматривая само приложение как цель защиты. Я же говорю о защите ОС и других приложений от угроз, которые несет за собой использование уязвимого приложения в этой "экосистеме". KV>Я прав?
Здравствуйте, DOOM, Вы писали:
DOO>>>Каким бы ни было ТЗ оно не может описать весь входной язык, все состояния автомата и функцию перехода. Это просто нереально. V>>it depends (c) DOO>Пример такого ТЗ, раз depends :)
боюсь, придется поверить на слово. если интересует область ПО: рентгеноспектральный анализ; контроллеры излучателей.
DOO>>>А почему ты все сводишь только к входным данным, причем только к тем, которые может ввести пользователь системы? V>>где я говорю только о пользователях системы? DOO>Хорошо переформулируем — ты все ограничиваешь только синхронными данными, не учитывая, например, асинхронные сигналы.
где?
DOO>Про обработку отказов оборудования я вообще молчу.
я отношу это тоже к входным воздействиям на систему.
V>>Это не входные данные системы? DOO>По твоим рассуждениям создается такое впечатление.
по каким именно рассуждениям?
V>>асутп аэс и асутп арбузорастительного комбината — разные вещи с точки зрения требований к надежности. именно минимальных требований, но, разумеется, никак не верхнего ограничения культуры разработки. DOO>В общем-то да. Но опять же, если речь о коробочном продукте (в смысле для массового использования), то тут ты уже не знаешь будет это АЭС или арбузорастительный комбинат.
в общем-то, согласен. но будет ли в аэс кто-либо использовать коробочный продукт школьника Васи Пупкина? если речь идет о выполнении требований надежности, то для системы подбираются компоненты, удовлетворяющие этим требованиям, ибо итоговая надежность условно не выше минимально надежного компонента ("условно" — потому, что "надежность" без конкретики применения — это сферический конь в вакууме). соответственно, ничто не мешает совместно существовать коробочным продуктам с надежностью 95%, 99%, 99.999%, решающим одну и ту же задачу, но с различной стоимостью. вряд ли много кому нужен стандартный калькулятор, с надежностью "пять девяток" за $5000 за одну лиценцию.
Здравствуйте, 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 Но тот топик смутно помню, надо будет поискать.
Мне кажется, vayerx неправильно выбрал позицию для поливания дотнета. Дыры, связанные с переполнением буфера случаются сплошь и рядом и никакие отмазки тут неуместны. Другое дело, что в С++ есть все средства для написания кода в стиле, предотвращающем их появление, и при этом накладывающие оверхед небольший, чем дотнет. Основная проблема состоит в том, что большинство продолжают писать на С++ как на С с классами, даже в крупных и уважаемых проектах.
V>либо не учитываете тот факт, что огромной части пользователей "до одного места", будут ли его приложение атаковать (части из них пофиг ибо обоснованно считают, что никому в здравом уме не прийдет в голову атаковать контроллер их пылесоса, а вторая часть не парится до того момента, пока пятух не клюнет).
А вот тут не прав ты — заражение компьютера пользователя вредоносным ПО в 99% случаев не наносит прямого вреда самому пользователю, но то, что через него например идут тонны спама или проводятся DDoS атаки причиняет очень серьезный ущерб, который имеет вполне себе измеримое материальное выражение и размеры этого "материального выражения" явно не сопоставимы с пресловутыми дополнительными затратами на обеспечение безопасности приложения.
Про так называемые "ключевые системы инфраструктуры" (ака АСУ ТП) я просто молчу.
Здравствуйте, Mamut, Вы писали:
KV>>P.S: Хочу обратить внимание, что в бюллетене http://secunia.com/advisories/31132/ сообщается об уязвимости переполнения буфера, применимой только к MacOSX. Это чтобы нарваться еще и на юниксоидов и Мамута
M>Ж)
M>На МакОСИ все это усугубляется сильной непрозрачностью процеса выпуска патчей. То есть если с Мозиллой все понятно — они-то могут среагировать и апдейтнуть, то с официальными Эппловскими продуктами не все так радужно. Часто security updates выходят с одной строчкой типа «fixed numerous issues» — и все
А они считают выделенное дополнительной мерой по безопасности (т.е. не раскрывать информацию об уязвимости, даже после ее обнаружения и исправления) Но учитывая то, что довольно большой процент эксплоитов пишется через реверсинг выпускаемых патчей, это какая-то неэффективная мера.
V>вы либо сильно перевираете сказанное мной, либо крайне невнимательно читали мои комментарии, либо почему-то сделали акцент на "выгодных" себе вещах.
Все понял, мы действительно о разных вещах говорим. Вы говорите о защите сферических и обособленных приложений от информационных угроз в вакууме. Т.е. рассматривая само приложение как цель защиты. Я же говорю о защите ОС и других приложений от угроз, которые несет за собой использование уязвимого приложения в этой "экосистеме".
V>мнение о том, что прилагать дополнительные меры по защите софта от атак нужно абсолютно в любом софте.
Почему же? Дыра это баг, отказаться от устранения дыр равносильно признанию, что мы намеренно отдаем заказчику глючный продукт.
R>>Дыры, связанные с переполнением буфера случаются сплошь и рядом и никакие отмазки тут неуместны.
V>Где?
Да везде
Здравствуйте, vayerx, Вы писали:
V>во-первых, строго говоря, это исключительно домысел в чистом виде. во-вторых, это относилось исключительно к калькулятору, а не к изначальному опусу, и, соответственно, не к теме в целом.
Вот теперь я точно перестал понимать, к чему вообще был этот вопрос
KV>>Вы утверждаете что для определенных классов ПО (причем для подавляющего их количества) вопрос защиты кода не стоит в принципе, в силу ее нецелесообразности.
V>утверждаю, что для определенных классов ПО (для большего подмножества) защита кода от атак не является необходимой и, как следствие, вопрос о защите в этом случае может и не вставать.
Мне понравилось, как ненавязчиво появилось вот это "может"
KV>>Чтобы разговор был более предментым, можете перечислить несколько примеров где требуется защита и несколько пример, где не требуется?
V>на мой взгляд, защита может быть не необходима: в большинстве прикладных математических пакетов (за исключением сетевых компонентов, если они присутствуют); вычислительной геометрии, картографии; физическом моделировании; задачах искуственного интеллекте; распознавании и обработке образов; вычислительной химии; большинстве прошивок контроллеров бытовой и промышленной техники не связанной с сетевым обменом; стандартном калькулятор windows.
V>на мой взгляд, защита требуется: в браузерах, клиентах сетей мгновенного обмена сообщениями, веб серверах, многих подситемы ОС.
Я прошу прощения, но вам не кажется что перечисленное несколько противоречит вашему же "для определенных классов ПО (причем для подавляющего их количества) вопрос защиты кода не стоит"?
Нет, я конечно понимаю жестокую роль вычислительной химии в тяжелой жизни домохозяек (а про рентгеноспектральный анализ, я вообще молчу, куда ж современный рядовой пользователь без него?), но все же мне кажется, что перечисленное вами не очень является "подавляющим количеством".
V>было бы любопытно посмотреть на ваш домашний бронированный кухонный комбайн, привинченный к полу =) а на работу предпочитаете на танке или бронетранспортере ездить? дорого, наверное, обходится?
Забавно, вы сейчас демострируете мне всю абсурдность предложенной вами же аналогии, на которую я указал еще пару постов назад.
V>>>если же все ж таки переходить к более осмысленному обсуждению, то давайте обсудим является ли "защита" фичей приложения (в каких-то случаях — необходимой, в каких-то — опциональной) или же она является неотъемлемой его частью абсолютно всегда. KV>>Нет, сначала я предлагаю обсудить, зависит ли защищенность кода от квалификации разработчиков и действительно ли им так необходимо реализовывать какие-либо дополнительные "фичи", или же их роль в процессе разработки защищенного ПО сводится к написанию качественного и грамотного кода?
V>не вижу смысла с этого начинать ибо это вторично по отношению к необходимости защиты в целом. если мы прийдем к выводу, что защита нужна лишь на ограниченном подмножестве ПО, то квалификацию разработчиков будет иметь смысл рассматривать именно над этим подмножеством.
Какое славное и осмысленное получилось обсуждение... А вот скажите, следование coding guidelines является мерами по дополнительной защите приложения?
KV>>>>Вот потом и появляются (после выделенного) многофакторные атаки типа того cover bombing через уязвимости в safari и IE V>>>вы передергиваете. вы сами отнесли "safari и ie" к ПО "уязвимости в котором вполне допустимы". KV>>нисколько, просто вы не в курсе этой истории о перебрасывании мячиков (а также всяческих химикалий) между MS'ами и Apple'ами по поводу этих двух уязвимостей.
V>не в курсе. тем не менее, какими бы сложными не были психосексуальные отношения между MS'ами и Apple'ами, это не является поводом передергивать. если вы приводите эту историю как контраргумент, то логично предположить, что вы согласны с отнесением safari и ie к ПО, уязвимости в котором вполне допустимы.
Я привел его как пример того, насколько разлагающе могут действовать на разработчиков мысле, которые вы тут проталкиваете.
V>низкоквалифицированные разработчики всегда были, есть, и, видимо, будут есть. ориентироваться на них тоже не стоит. так же, как и не стоит забывать, что допускать ошибки могут все. много ли существует "серьезных" коммерческих продуктов, написанных неквалифицированными разработчиками, код которых никто ни разу не просматривал?
Это все верно, однако верно и то, что софт на дотнете потенциально содержит меньше дыр, чем на С++. Причем это уменьшение дается нам фактически бесплатно. Допустим перед нами две программы, реализующих одинаковый функционал, только одна на C++, другая на C#. Вы не можете наперед точно сказать, в какой меньше дыр, но можете заявить, что в варианте C# как минимум дыр с переполнением нет.
V>вряд ли вы сочтете более защищенным продукт написанный на управляемой платформе, но, к примеру, хранящий все пароли в тесктовом файле и позволяющий выполнить произвольный sql запрос пользователя.
Мне кажется, переполнение буфера и хранение паролей в текстовом файле — дыры разного уровня. Допустить дыру с паролями (или аналогичную) просто так не получится, нужно сознательно принять решение и написать код. Дыры же с переполнением случаются почти машинально, едва ли не на уровне опечатки, и допустить их может кто угодно и когда угодно. Единственный надежный способ от них избавиться — лишить программиста возможности совершить их.
V>строго доказать отсутствие уязвимостей крайне дорого практически для любого софта — примем это как данное.
Дорого — для произвольного, уже имеющегося софта. Но если при его разработке использована "правильная" технология, доказательство у нас в кармане .
V>в данном вопросе у меня другое вероисповедание. вместо заковывания в броню каждого калькулятора, вопрос защиты реестра должен решаться ограничением прав доступа пользователя к уязвимым веткам. это, имхо, исключительно вопрос администрирования/разработки системного ПО, а не разработки прикладного.
А причем тут ваше вероисповедание? . Интернет-кафе лишь пример. Мало ли какая возникнет ситуация и потребуется обеспечить разграничение прав на более высоком уровне, чем позволяет механизм безопасности Windows. Всего не предусмотришь. И решение будет принимать сотрудник кафе, а он не обязан держать в голове, какие программы с какими требованиями разрабатывались. А если потребовать от него это знание, или пытать разграничивать, где и когда можно использовать калькулятор, наступит сплошной хаос.
Другими словами, если мы хотим кардинально решить проблему дырявого софта, то гораздо эффективнее сделать безопасной каждую программу в отдельности, чем выдумать всякие разграничительные меры.
V>таки как раз наоборот. надежности от любого софта требовать не нужно, как минимум, из-за того, что это обойдется сильно дороже.
Ну что ж интересно и в общем правильно, но раз уж КСВ, так КСВ.
Так что несмотря на то, что сейчас 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>И получается интересная картина: оказывается, доля уязвимостей переполнения буфера не так уж и мала (больше доли любых других уязвимостей), но вот некоторые плюсники считают что на них все равно можно забить. И что тут есть причина, а что следствие, это еще разобраться надо ;)
Надеюсь, вы не вписываете меня в ряды тех, кто считает что уязвимости можно забить? Напомню еше раз этого я никогда не говорил. Или вам кажется малозаметным нюанс между "никогда и не при каких условиях не исправлять уязвимости ни в каком ПО" и "уязвимости в некотором ПО вполне допустимы, а защищать необходимо нужно то, что защищать необходимо, но не более того =)"? И именно из-за этого нюанса, видимо, и возник спор о серебрянной пуле, лечащей сразу все прострелянные ноги.
И еще раз напомню, что я ни коем образом не умаляю достоинства управляемых платформ, а, скорее даже наоборот, как неоднократно писал, считаю их гораздо более примеными для большого спектра задач.
Здравствуйте, 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 мне не очень нравится, но пусть будет). И чем дальше, тем в большей степени это всё будет поддерживаться на аппаратном уровне. Соответственно, фоннеймовская архитектура в обозримом будущем если и не уйдёт в небытие, то очень сильно сдаст свои позиции — так что не будет самого предмета спора. С этой точки зрения фреймворки в плане безопасности выглядят как временные костыли, возможно даже и препятствующие эффективной защите.
Курица — это инструмент, с помощью которого одно яйцо производит другие.
KV>P.S: Хочу обратить внимание, что в бюллетене http://secunia.com/advisories/31132/ сообщается об уязвимости переполнения буфера, применимой только к MacOSX. Это чтобы нарваться еще и на юниксоидов и Мамута
Ж)
На МакОСИ все это усугубляется сильной непрозрачностью процеса выпуска патчей. То есть если с Мозиллой все понятно — они-то могут среагировать и апдейтнуть, то с официальными Эппловскими продуктами не все так радужно. Часто security updates выходят с одной строчкой типа «fixed numerous issues» — и все
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, vayerx, Вы писали: V>>даже если там, к примеру, всего суммарно 1 кб памяти? ;) S>Это малореально по практическим соображениям — 1кб памяти обойдется тебе сейчас дороже, чем 1MB. S>Поэтому про эти вырожденные случаи лучше забыть и попрочнее.
вообще, про 1 кб, как, впрочем, и про пылесос, я в шутку написал, но, как говориться, холиварить — так холиварить =)
открываем сайт Чип и Дип и смотрим:
разумеется, навеска отличается, но зачем она нашему пылесосу? =) тем не менее, тенденция цен заметна?
можно, безусловно, ставить внешнюю память. но нафига? ;)
Здравствуйте, vayerx, Вы писали:
V>Здравствуйте, DOOM, Вы писали:
V>>>А вы много пользователей взломанных пылесосов знаете? DOO>>да я и не густо пылесосов с выходом в иннет знаю
V>а про иннет разве кто-то что-то говорил? в своем начальном опусе товарищ kochetkov.vladimir усмотрел фатальную ущербность в архитекутре фон-Неймана и упорно доказывал что все в мире ПО, включая стандартный калькулятор в windows, в обязательном порядке должно быть защищенно и, в первую очередь, от атак в виде инъекций кода вне зависимости от того, подключен ли компьютер к сети или нет.
И это я ваши слова перевираю? По-моему, мой пример с калькулятором явным образом предполагал, что компьютер пользователя подключен к сети
Здравствуйте, frogkiller, Вы писали:
F>Здравствуйте, kochetkov.vladimir, Вы писали:
F>[многабукоф]
KV>>Ну вот, пожалуй и все. Можете рвать
F>Ну, рвать — не рвать, но контр-аргументов я парочку добавлю.
F>1. "Стоимость" необнаруженной уязвимости в управляемом фреймворке значительно превышает такую "стоимость" узявимости в нативном коде — за счёт масштабов распространения и унификации. Так что в "мат. ожидание" вреда (= вероятность уязвимости * вред от неё), полагаю, для двух наиболее популярных фреймворков повыше, чем для отдельного нативного приложения.
А если сравнивать управляемый фреймворк не с еденичным нативным приложением, а с нативной библиотекой типа boost'а или операционной системой?
F>2. Тенденции в отрасли таковы, что с каждым годом доля одиночных приложений будет только уменьшаться в пользу серверных (термин cloud computing мне не очень нравится, но пусть будет). И чем дальше, тем в большей степени это всё будет поддерживаться на аппаратном уровне. Соответственно, фоннеймовская архитектура в обозримом будущем если и не уйдёт в небытие, то очень сильно сдаст свои позиции — так что не будет самого предмета спора.
А на чем тогда сервера в облаке будут крутиться?
F>С этой точки зрения фреймворки в плане безопасности выглядят как временные костыли, возможно даже и препятствующие эффективной защите.
Ну суть-то этой защиты в том, чтобы перенести головную боль с клиентской стороны на серверную, не более того. Но боль-то останется?
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Нет чтобы просто плюсик поставить...
Что-то не подумал, честно говоря... КСВ ведь
Ладно, поставлю...
DOO>>Так что несмотря на то, что сейчас 9 вечера и я еще на работе, все же немного потреплюсь KV>Ну щас хоть и не 9 вечера, но зато суббота, а я все еще на работе, так что квиты :-Р
Ну я с работы уже ушел, но сейчас залезу на корпоративный портал и опять понесется... Конец года мать его — 6-ти дневная рабочая неделя, 12-ти часовой рабочий день...
KV>Ну, то что в кэше данные и код разделены от атак на содержимое оперативной памяти ведь слабо влияет? По поводу NX-флагов, недавно прочел, что в Google Chrome они вовсю используются, причем это преподносилось почти как killer-фича по отношению к остальным браузерам. Это действительно так? В смысле, что в FF, IE и Opera они не используются? Я чего-то об этом инфы не нашел
Не скажу... Вообще в IA32 с NX-ом не все так просто, насколько я помню...
KV>Я видел буквально у себя на ноутбуке. Но тут есть две проблемы: DEP (в XP, по крайней мере) надо еще включить, чтобы он на все приложения, а не только на ОС работал. А во-вторых, нужно быть готовым, что некоторые приложения после его включения отвалятся сами собой и их придется добавлять в исключения. У меня такая фигня была с архиполезной (для меня) утилиткой kleptomania
Ну это да... Тут не поспоришь...
DOO>>Следующий момент: уязвимость переполнения буфера бывает очень часто сложно эксплуатировать, потому что заветный адрес зависит от номера сборки, локали и еще бог знает чего — применимость эксплойта резко снижается (хотя есть "интеллектуальные" варианты). А тут еще и ASR...
KV>Тоже есть такое дело, но есть и забавные воркарраунды. Например, когда фишеры атакуют юзеров с целью подсадить им спам-бота или руткит по "вредоносной ссылке", они на ту сторону ссылки ставят скрипт, анализирующий http-заголовок на предмет ОС и броузера, и возвращают страницу с нужным эксплоитом.
неплохо... Про такое не слыхал даже
DOO>>Ну и еще один момент: возможности приложения ограничены (помним знаменитое "В Linux'е вирусов нет"... по телевизору ) все-таки само приложение уже давно работает в песочнице ОС.
KV>+ AppArmor +SELinux + UAC +всевозможные мониторы системных вызвов (забыл как класс ПО называется) и т.п. Но это именно то, что я назвал в той сказке "костылями"
Я не об этом говорил — а о базовых вещах: монитор безопасности, защита памяти...
DOO>>Ты можешь возразить, что существует ряд служб, работающих в привилегированном режиме и даже имеющих интерфейсы в ядре — но тут палка о двух концах — не просто так они в ядро полезли (тут надо появится на сцене Sinclair'у и прочитать лекцию о необходимости драйвера http.sys для нормальной работы IIS'а).
KV>Че-то нету Sinclair'a
Отметился уже где-то, только не по этому вопросу...
KV>Но тот топик смутно помню, надо будет поискать.
Ну смысл http.sys в том, чтобы эффективно отдавать файлы из кэша — т.е. вопрос скорости и легковесности, не захотят тут оверхед песочницы люди видеть...
Хотя, есть Jetty — даже видел как-то портал на нем — но портал это не массовое обслуживание...
Здравствуйте, kochetkov.vladimir, Вы писали:
F>>1. "Стоимость" необнаруженной уязвимости в управляемом фреймворке значительно превышает такую "стоимость" узявимости в нативном коде — за счёт масштабов распространения и унификации. Так что в "мат. ожидание" вреда (= вероятность уязвимости * вред от неё), полагаю, для двух наиболее популярных фреймворков повыше, чем для отдельного нативного приложения. KV>А если сравнивать управляемый фреймворк не с еденичным нативным приложением, а с нативной библиотекой типа boost'а или операционной системой?
Всё равно связность компонент в фреймворке значительно выше. А с операционной системой сравнивать некорректно.
KV>А на чем тогда сервера в облаке будут крутиться?
Однозначного ответа я не знаю, думаю сейчас его не знает никто. Но вряд ли имеет смысл рассматривать отдельный сервер — только кластер. Соответственно, структура должна быть не фоннеймановской. (Предупреждая напрашивающийся вопрос про кластер из одного сервера — всё равно накладываемые требования и ограничения делают машину не чисто фоннеймановской)
F>>С этой точки зрения фреймворки в плане безопасности выглядят как временные костыли, возможно даже и препятствующие эффективной защите. KV>Ну суть-то этой защиты в том, чтобы перенести головную боль с клиентской стороны на серверную, не более того. Но боль-то останется?
Неа. Суть в том, что на серверной стороне будет боль другого порядка, обусловленная особенностями облачного кластера, а не нынешними проблемами клиентских машин. В этом смысле облако в какой-то мере можно назвать фреймворком, только отличающимся от привычных нам.
Курица — это инструмент, с помощью которого одно яйцо производит другие.
F>Однозначного ответа я не знаю, думаю сейчас его не знает никто. Но вряд ли имеет смысл рассматривать отдельный сервер — только кластер. Соответственно, структура должна быть не фоннеймановской. (Предупреждая напрашивающийся вопрос про кластер из одного сервера — всё равно накладываемые требования и ограничения делают машину не чисто фоннеймановской)
А какие противоречия-то? Ни NUMA, ни транспьютеры за пределы принципов фон Неймана не выходят
Я правда не совсем понимаю термин cloud computing — это для меня какой-то очередной web 2.0 — то, что уже много лет есть, но просто никто красиво не обзывал...
F>Неа. Суть в том, что на серверной стороне будет боль другого порядка, обусловленная особенностями облачного кластера, а не нынешними проблемами клиентских машин. В этом смысле облако в какой-то мере можно назвать фреймворком, только отличающимся от привычных нам.
Хм... Ну вот есть тот же MPI — в общем и целом использование MPI слабо отличается от простого многопоточного приложения — проблемы и пути решения абсолютно одинаковые
Здравствуйте, vayerx, Вы писали:
V>Здравствуйте, kochetkov.vladimir, Вы писали:
V>>>а про иннет разве кто-то что-то говорил? в своем начальном опусе товарищ kochetkov.vladimir усмотрел фатальную ущербность в архитекутре фон-Неймана и упорно доказывал что все в мире ПО, включая стандартный калькулятор в windows, в обязательном порядке должно быть защищенно и, в первую очередь, от атак в виде инъекций кода вне зависимости от того, подключен ли компьютер к сети или нет. KV>>И это я ваши слова перевираю? По-моему, мой пример с калькулятором явным образом предполагал, что компьютер пользователя подключен к сети
V>в каком именно месте это предполагалось? цитату в студию.
Вот в этом:
После этого, мы идем в "Коллеги улыбнитесь" и еще на десяток подобных ресурсов и постим там подготовленную нами строку под видом пасхального яйца с подробными инструкциями по его активации. Разумеется, для якобы активации яйца нужно скопировать нашу строку в буфер и затем вставить в калькулятор.
Нет, можно конечно рассылать ссылки голубиной почтой, или устроить обзвон кывтюгкцев и надиктовку им эксплоита голосом...
V>с фон-Нейманом сеть как связанна?
а это к теме не имеет отношения
V>>>
я утверждаю, что эта самая головная боль заметна лишь для ограниченного круга задач. безусловно, полезно, когда защита есть на уровне платформы разработки, но ее отсутствие в общем случае не фатально.
KV>>Не фатально. Но если защиты на уровне платформы нет, а защита все же нужна (а она нужна), то ее придется реализовывать на уровне приложения. V>вы, прошу прощения, читать умеете? а внимательно?
Умею. Вы утверждаете что для определенных классов ПО (причем для подавляющего их количества) вопрос защиты кода не стоит в принципе, в силу ее нецелесообразности. Чтобы разговор был более предментым, можете перечислить несколько примеров где требуется защита и несколько пример, где не требуется?
V>>>иными словами, процесс разрботки большого количества ПО встречается с гораздо более сложными проблемами, нежели защита от уязвимостей — далеко не всему ПО необходима защита. KV>>Что в вашем понимании есть эта самая "защита"? Чтоб быть уверенным, что мы об одном и том же говорим.
V>под "защитой от уязвимостей" я предполагаю обеспечение полноого или частичного предотвращения потенциальных вредоносных действий в отношении программы, приводящих к утечке инофрормации, получению управления над системой или ее частью и т.д.
ок, в таком случае, разговор становится совсем интересным... но я подожду примеров ПО.
V>>>то, что код "Код, позволяющий произвольно и недетерминированно изменять собственную логику выполнения через передачу ему неожидаемые входных данных, не является работающим кодом", в общем случае, неверно:
такое поведение кода можно отнести к нецелевому использованию ПО. это отчасти напоминает байку о том, что если кухонным комбайном выстрелить из катапульты, он перестает работать.
KV>>Пример про комбайн — некорректен, т.к. вы говорите о том, что может/не может должен/не должен делать с ним его же пользователь. В случае же с ПО, векторы воздействия на него, далеко не всегда ограничиваются только возможностями и желанием его пользователей.
V>пример с комбайном вполне корректен. "векторы воздействия не всегда ограничиваются только возможностями и желанием его пользователей", ровно как и ограничиваются только возможностями и желанием его пользователей. V>если придираться к словам, то стрелять комбайном может не сам пользователь, а злоумышленник — вам от этого легче?
Если выделенное обусловлено особенностями реализации данного конкретного комбайна, то я выберу комбайн, который не позволяет это сделать.
V>если же все ж таки переходить к более осмысленному обсуждению, то давайте обсудим является ли "защита" фичей приложения (в каких-то случаях — необходимой, в каких-то — опциональной) или же она является неотъемлемой его частью абсолютно всегда.
Нет, сначала я предлагаю обсудить, зависит ли защищенность кода от квалификации разработчиков и действительно ли им так необходимо реализовывать какие-либо дополнительные "фичи", или же их роль в процессе разработки защищенного ПО сводится к написанию качественного и грамотного кода? Иными словами, являются ли уязвимости в ПО следствием неграмотности/невнимательности его разработчиков и/или допущенных ими ошибок в коде, или же это намеренная "халатность" обусловленная тем, что (согласно вашей теории): а) "нам за это не платят", б) "наш продукт никто взламывать не будет", в) "у нас нет ресурсов еще и на обеспечение безопасности нашего кода", г) "вопрос безопасности нашего продукта является несущественным в силу того что ...(впишите нужную причину)"?
V>>>вам кажется малозаметным нюанс между "никогда и не при каких условиях не исправлять уязвимости ни в каком ПО" и "уязвимости в некотором ПО вполне допустимы, а защищать необходимо нужно то, что защищать необходимо, но не более того =)"? KV>>Вот потом и появляются (после выделенного) многофакторные атаки типа того cover bombing через уязвимости в safari и IE
V>вы передергиваете. вы сами отнесли "safari и ie" к ПО "уязвимости в котором вполне допустимы".
нисколько, просто вы не в курсе этой истории о перебрасывании мячиков (а также всяческих химикалий) между MS'ами и Apple'ами по поводу этих двух уязвимостей.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Нет, можно конечно рассылать ссылки голубиной почтой, или устроить обзвон кывтюгкцев и надиктовку им эксплоита голосом...
Ага — НЛП. А потом человек сам удаляет у себя файлы, рассылает спам и пр.
Здравствуйте, roman10, Вы писали:
R>Мне кажется, vayerx неправильно выбрал позицию для поливания дотнета.
Мне кажется, вы тоже не отличаетесь внимательностью, либо не утруждаете себя чтением перед выдвижением гипотез.
Я не "поливаю дотнет", я поливаю опус г-на kochetkov.vladimir
и мнение о том, что прилагать дополнительные меры по защите софта от атак нужно далеко не в любом софте. и меня очень сильно удивляет, когда в контрпримерах мне приводят, например, дыры в браузерах — браузеры безусловно относятся к разряду того софта, который защищать необходимо.
R>Дыры, связанные с переполнением буфера случаются сплошь и рядом и никакие отмазки тут неуместны.
опечатался:
V>Мне кажется, вы тоже не отличаетесь внимательностью, либо не утруждаете себя чтением перед выдвижением гипотез. V>Я не "поливаю дотнет", я поливаю опус г-на kochetkov.vladimir
Здравствуйте, roman10, Вы писали:
V>>мнение о том, что прилагать дополнительные меры по защите софта от атак нужно абсолютно в любом софте. R>Почему же? Дыра это баг, отказаться от устранения дыр равносильно признанию, что мы намеренно отдаем заказчику глючный продукт.
Категорически несогласен. Дыры (потенциальная уязвимость, приводящая к потенциальной утечке данных и/или получению доступа к системе или ее части) является, в лучшем случае, подмножеством багов (действия программы, нарушающие требования ТЗ или другого нормативного документа). Продукт, имеющий потенциально незащищенные места может отлично выполнять требуемую функциональность в рамках ТЗ, и, тем самым, не являться "глючным продуктом". Разумеется, в каких-то областях логично предположить необходимость защиты даже вне рамок ТЗ, но в общем случае это не так.
V>>Где? R>Да везде :)
в калькуляторе windows?
Здравствуйте, kochetkov.vladimir, Вы писали:
V>>в каком именно месте это предполагалось? цитату в студию. KV>Вот в этом:
После этого, мы идем в "Коллеги улыбнитесь" и еще на десяток подобных ресурсов и постим там подготовленную нами строку под видом пасхального яйца с подробными инструкциями по его активации. Разумеется, для якобы активации яйца нужно скопировать нашу строку в буфер и затем вставить в калькулятор.
KV>Нет, можно конечно рассылать ссылки голубиной почтой, или устроить обзвон кывтюгкцев и надиктовку им эксплоита голосом...
во-первых, строго говоря, это исключительно домысел в чистом виде. во-вторых, это относилось исключительно к калькулятору, а не к изначальному опусу, и, соответственно, не к теме в целом.
V>>с фон-Нейманом сеть как связанна? KV>а это к теме не имеет отношения
это почему? вам ваш опус напомнить?
KV>Вы утверждаете что для определенных классов ПО (причем для подавляющего их количества) вопрос защиты кода не стоит в принципе, в силу ее нецелесообразности.
утверждаю, что для определенных классов ПО (для большего подмножества) защита кода от атак не является необходимой и, как следствие, вопрос о защите в этом случае может и не вставать.
KV>Чтобы разговор был более предментым, можете перечислить несколько примеров где требуется защита и несколько пример, где не требуется?
на мой взгляд, защита может быть не необходима: в большинстве прикладных математических пакетов (за исключением сетевых компонентов, если они присутствуют); вычислительной геометрии, картографии; физическом моделировании; задачах искуственного интеллекте; распознавании и обработке образов; вычислительной химии; большинстве прошивок контроллеров бытовой и промышленной техники не связанной с сетевым обменом; стандартном калькулятор windows.
на мой взгляд, защита требуется: в браузерах, клиентах сетей мгновенного обмена сообщениями, веб серверах, многих подситемы ОС.
V>>>>иными словами, процесс разрботки большого количества ПО встречается с гораздо более сложными проблемами, нежели защита от уязвимостей — далеко не всему ПО необходима защита. KV>>>Что в вашем понимании есть эта самая "защита"? Чтоб быть уверенным, что мы об одном и том же говорим.
V>>пример с комбайном вполне корректен. "векторы воздействия не всегда ограничиваются только возможностями и желанием его пользователей", ровно как и ограничиваются только возможностями и желанием его пользователей. V>>если придираться к словам, то стрелять комбайном может не сам пользователь, а злоумышленник — вам от этого легче? KV>Если выделенное обусловлено особенностями реализации данного конкретного комбайна, то я выберу комбайн, который не позволяет это сделать.
было бы любопытно посмотреть на ваш домашний бронированный кухонный комбайн, привинченный к полу =) а на работу предпочитаете на танке или бронетранспортере ездить? дорого, наверное, обходится?
V>>если же все ж таки переходить к более осмысленному обсуждению, то давайте обсудим является ли "защита" фичей приложения (в каких-то случаях — необходимой, в каких-то — опциональной) или же она является неотъемлемой его частью абсолютно всегда. KV>Нет, сначала я предлагаю обсудить, зависит ли защищенность кода от квалификации разработчиков и действительно ли им так необходимо реализовывать какие-либо дополнительные "фичи", или же их роль в процессе разработки защищенного ПО сводится к написанию качественного и грамотного кода?
не вижу смысла с этого начинать ибо это вторично по отношению к необходимости защиты в целом. если мы прийдем к выводу, что защита нужна лишь на ограниченном подмножестве ПО, то квалификацию разработчиков будет иметь смысл рассматривать именно над этим подмножеством.
KV>>>Вот потом и появляются (после выделенного) многофакторные атаки типа того cover bombing через уязвимости в safari и IE V>>вы передергиваете. вы сами отнесли "safari и ie" к ПО "уязвимости в котором вполне допустимы". KV>нисколько, просто вы не в курсе этой истории о перебрасывании мячиков (а также всяческих химикалий) между MS'ами и Apple'ами по поводу этих двух уязвимостей.
не в курсе. тем не менее, какими бы сложными не были психосексуальные отношения между MS'ами и Apple'ами, это не является поводом передергивать. если вы приводите эту историю как контраргумент, то логично предположить, что вы согласны с отнесением safari и ie к ПО, уязвимости в котором вполне допустимы.
Здравствуйте, vayerx, Вы писали:
V>Категорически несогласен. Дыры (потенциальная уязвимость, приводящая к потенциальной утечке данных и/или получению доступа к системе или ее части) является, в лучшем случае, подмножеством багов (действия программы, нарушающие требования ТЗ или другого нормативного документа). Продукт, имеющий потенциально незащищенные места может отлично выполнять требуемую функциональность в рамках ТЗ, и, тем самым, не являться "глючным продуктом". Разумеется, в каких-то областях логично предположить необходимость защиты даже вне рамок ТЗ, но в общем случае это не так.
У тебя очень лихое определение бага. Нечестное я бы сказал. Покажи мне хоть одно ТЗ, определяющее функционал АС с точностью до последнего входного сигнала и реакции на него.
Честное определение бага было бы что-то вроде — недетерминированность конечного автомата, соответсвующего АС (это более менее понятно, хотя и не совсем верно). Т.е. если программа при получении определенных входных данных или сигнала или еще чего-то попадает в неопределенное разработчиком состояние, то это баг. Даже, если в результате ничего страшного не происходит.
Здравствуйте, DOOM, Вы писали:
DOO>Покажи мне хоть одно ТЗ, определяющее функционал АС с точностью до последнего входного сигнала и реакции на него.
АС в данном контексте — аналоговая схема, автоматизированная система, атомная станция, etc?
тз бывают формальными, тз бывают педанитичными. в околоисследовательских задачах тз могут вообще не содержать конкретики. это все понятно. тем не менее, если перед вами лежит тз на разработку нового браузера и в нем (тз) нет раздела про безопасность, включающего защиту от атак, это странно. думаю, любой квалифицированный разработчик не увидев такого пункта, поинтересовался бы причиной его отсутсвия — то ли заказчик забыл, то ли рассчитывет на услугу "все включенно", то ли ему на это вдруг наплевать и он платить за это не будет.
DOO>Честное определение бага было бы что-то вроде — недетерминированность конечного автомата, соответсвующего АС (это более менее понятно, хотя и не совсем верно). Т.е. если программа при получении определенных входных данных или сигнала или еще чего-то попадает в неопределенное разработчиком состояние, то это баг. Даже, если в результате ничего страшного не происходит.
недетерминированность конечного автомата — это, безусловно, ошибка. но если в тз явно указанно, что лигитимным входом считается, например, число в некотором диапазоне в строковой форме, а программе на вход подали кусок исполнямого кода, то это можно рассматривать как выход за определение конечного автомата. безусловно, я соглашусь, что квалифицированно написанная программа должна, вероятно (если вдруг обратное не обуславливается спецификой задачи), должна проверять входные данные и если уж не каким-либо образом сообщать об ошибке, то уж по крайней мере не нарушать целостности своих данных и кода и не пытаться выполнить входные данные как код. тем не менее, как бы варварски это не звучало, в общем случае некорректная работа программы при некорректных входных данных для некоторого подмножества ПО, имхо, может быть отнесена к нецелевому использованию этого ПО. разумеется, наличие верификации данных — это не бинарная характеристика ПО: если, к примеру, математический пакет падает при попытке вычислить в действительной системе корень от отрицательного числа, то это по меньшей мере "некрасиво", но если этот пакет падает, если ему подсунуть вместо аргумента для корня вместо числа в строковой форме поток бинарных данных, то это "значительно менее некрасиво" %)
DOO>У тебя очень лихое определение бага. Нечестное я бы сказал. Покажи мне хоть одно ТЗ, определяющее функционал АС с точностью до последнего входного сигнала и реакции на него.
Просто есть неявно понимаемое поведение. Следующее из стандартов качества, общих практик и прочего. И расхождение с общепринятыми стандартами вполне может считаться за баг.
DOO>Т.е. если программа при получении определенных входных данных или сигнала или еще чего-то попадает в неопределенное разработчиком состояние, то это баг.
Это очень узкое определение. Если программа при двухкратном выборе пункта меню Файл за 1 секунду стабильно падает в корку, это вполне определенное поведение. Но это баг.
V>Продукт, имеющий потенциально незащищенные места может отлично выполнять требуемую функциональность в рамках ТЗ, и, тем самым, не являться "глючным продуктом". Разумеется, в каких-то областях логично предположить необходимость защиты даже вне рамок ТЗ, но в общем случае это не так.
Такая точка зрения имеет право на жизнь. Но по сути она является оборотной стороной другой проблемы. Той, что нынешние С++ разработчики не способны справится с валом возникающих проблем в безопасности, и вместо того, чтобы что-то кардинально поменять, ищут отмазки. Дескать, ну не можем мы без дыр, так давайте хотя бы избегать их в критичных местах, а в остальных пофиг.
Кстати, выше приводился пример с Firefox. Современный продукт, с мощной поддержкой крупнейших компаний в отрасли. В котором треть дыр можно отнести к переполнениям. Неужели эти дыры не нарушают ихнее ТЗ? А если бы "лису" писали на дотнете, их бы не было.
V>>>Где? R>>Да везде V>в калькуляторе windows?
Может быть . Гарантировать их отстутвие мы не можем.
И, к вопросу отлично выполняемой функциональности. Понятно, что можно разделить весь софт на "простой" и "с повышенными требованиями". Но проблемы безопасности столь обширны и непредсказуемы, что узнать заранее, что и где вылезет, невозможно. И даже самый безобидный пользовательский софт может неожиданно стать средством взлома.
Представим такую ситуацию. Мы настраиваем рабочее место в Интернет-кафе. Чтобы пользователи не натворили дел, запрещаем запуск regedit. Но доступ к calc.exe оставляем, мало ли кому что посчитать захочется. Но: преположим, в ТЗ к калькулятору не было требования обеспечить устойчивость к атакам. Ведь его можно отнести к "прикладным математическим пакетам, не содержащего сетевых компонентов". И если в нем оставили баг с переполнением, то у посетителя появляется возможность писать в реестр все, что угодно.
Получается, мы вынуждены требовать надежности от любого софта. И если в ТЗ нет таких требований, то это скорее по незнанию, а не тщательно обдуманное решение.
V>тем не менее, если перед вами лежит тз на разработку нового браузера и в нем (тз) нет раздела про безопасность, включающего защиту от атак, это странно.
Этот раздел подразумевается неявно. Допустим, мы написали, обеспечить отображение страниц в соответствии с HTML 4.01. А в нем написано, допустим что максимальная длина тэга не может превышать 32 символа. Но это совсем не значит, что если мы встретим тэг в 100 символов, наш браузер имеет право рушится.
Здравствуйте, roman10, Вы писали:
R>нынешние С++ разработчики не способны справится с валом возникающих проблем в безопасности, и вместо того, чтобы что-то кардинально поменять, ищут отмазки. Дескать, ну не можем мы без дыр, так давайте хотя бы избегать их в критичных местах, а в остальных пофиг.
низкоквалифицированные разработчики всегда были, есть, и, видимо, будут есть. ориентироваться на них тоже не стоит. так же, как и не стоит забывать, что допускать ошибки могут все. много ли существует "серьезных" коммерческих продуктов, написанных неквалифицированными разработчиками, код которых никто ни разу не просматривал? вряд ли вы сочтете более защищенным продукт написанный на управляемой платформе, но, к примеру, хранящий все пароли в тесктовом файле и позволяющий выполнить произвольный sql запрос пользователя. в этом месте, видимо, хочется обратиться к статистике типов обнаруженных уязвимостей, но, имхо, стоит подумать о том, какой процент составляет это софт по отношению к общему "сферическому" объему софта, разрабатываемом в мире. более того, даже внутри софта с найденными уязвимостями, большая его часть может относиться к "дыронейтральному" софту.
еще раз напомню, что я говорю исключительно в контексте обсуждения предложенной серебрянной пули для абсолютно любого ПО.
R>Кстати, выше приводился пример с Firefox. Современный продукт, с мощной поддержкой крупнейших компаний в отрасли. В котором треть дыр можно отнести к переполнениям. Неужели эти дыры не нарушают ихнее ТЗ? А если бы "лису" писали на дотнете, их бы не было.
согласен. с этим я никогда спорил.
V>>в калькуляторе windows? R>Может быть :). Гарантировать их отстутвие мы не можем.
строго доказать отсутствие уязвимостей крайне дорого практически для любого софта — примем это как данное.
вы же утверждали, что "дыры, связанные с переполнением буфера случаются сплошь и рядом" и, более того, везде. извиняюсь за такую придирчивость, но вы таки знаете о дырах в калькуляторе windows?
R>Представим такую ситуацию. Мы настраиваем рабочее место в Интернет-кафе. Чтобы пользователи не натворили дел, запрещаем запуск regedit. Но доступ к calc.exe оставляем, мало ли кому что посчитать захочется. Но: преположим, в ТЗ к калькулятору не было требования обеспечить устойчивость к атакам. Ведь его можно отнести к "прикладным математическим пакетам, не содержащего сетевых компонентов". И если в нем оставили баг с переполнением, то у посетителя появляется возможность писать в реестр все, что угодно.
в данном вопросе у меня другое вероисповедание. вместо заковывания в броню каждого калькулятора, вопрос защиты реестра должен решаться ограничением прав доступа пользователя к уязвимым веткам. это, имхо, исключительно вопрос администрирования/разработки системного ПО, а не разработки прикладного.
R>Получается, мы вынуждены требовать надежности от любого софта. И если в ТЗ нет таких требований, то это скорее по незнанию, а не тщательно обдуманное решение.
таки как раз наоборот. надежности от любого софта требовать не нужно, как минимум, из-за того, что это обойдется сильно дороже.
V>>тем не менее, если перед вами лежит тз на разработку нового браузера и в нем (тз) нет раздела про безопасность, включающего защиту от атак, это странно. R>Этот раздел подразумевается неявно. Допустим, мы написали, обеспечить отображение страниц в соответствии с HTML 4.01. А в нем написано, допустим что максимальная длина тэга не может превышать 32 символа. Но это совсем не значит, что если мы встретим тэг в 100 символов, наш браузер имеет право рушится.
любой квалифицированный разработчик не увидев такого пункта, поинтересовался бы причиной его отсутсвия — то ли заказчик забыл, то ли рассчитывет на услугу "все включенно", то ли ему на это вдруг наплевать и он платить за это не будет.
не спорю, видимо в 95.1% в браузере такая защита потребуется. но есть и менее однозначные виды ПО и возникает несколько путей разработки, если вдруг заказчик не хочет тратить деньги на реализацию и даже тестирование безопасности: обеспечить безопасность в свое личное время и потратить свои деньги (возможно, подняв свою репутацию, а, возможно, и нет, если заказчик этого даже не заметит); неявно включить стоимость безопасности в смету и, возможно, потерять клиента; сделать то, что хочет клиент (если в последствии защита ему потребуется, это будет дополнительным заказом, возможно, потребующим переписания значительной части софта).
Здравствуйте, vayerx, Вы писали:
V>Здравствуйте, DOOM, Вы писали:
DOO>>Покажи мне хоть одно ТЗ, определяющее функционал АС с точностью до последнего входного сигнала и реакции на него. V>АС в данном контексте — аналоговая схема, автоматизированная система, атомная станция, etc?
V>тз бывают формальными, тз бывают педанитичными. в околоисследовательских задачах тз могут вообще не содержать конкретики. это все понятно. тем не менее, если перед вами лежит тз на разработку нового браузера и в нем (тз) нет раздела про безопасность, включающего защиту от атак, это странно. думаю, любой квалифицированный разработчик не увидев такого пункта, поинтересовался бы причиной его отсутсвия — то ли заказчик забыл, то ли рассчитывет на услугу "все включенно", то ли ему на это вдруг наплевать и он платить за это не будет.
Каким бы ни было ТЗ оно не может описать весь входной язык, все состояния автомата и функцию перехода. Это просто нереально.
DOO>>Честное определение бага было бы что-то вроде — недетерминированность конечного автомата, соответсвующего АС (это более менее понятно, хотя и не совсем верно). Т.е. если программа при получении определенных входных данных или сигнала или еще чего-то попадает в неопределенное разработчиком состояние, то это баг. Даже, если в результате ничего страшного не происходит.
V>недетерминированность конечного автомата — это, безусловно, ошибка.
Замечательно.
V>но если в тз явно указанно, что лигитимным входом считается, например, число в некотором диапазоне в строковой форме, а программе на вход подали кусок исполнямого кода, то это можно рассматривать как выход за определение конечного автомата.
Нет-нет-нет. Еще раз — так нечестно. Входной язык в данном случае это именно любой набор сигналов, которые возможно передать в систему. ТЗ тут не при чем абсолютно.
V>безусловно, я соглашусь, что квалифицированно написанная программа должна, вероятно (если вдруг обратное не обуславливается спецификой задачи), должна проверять входные данные и если уж не каким-либо образом сообщать об ошибке, то уж по крайней мере не нарушать целостности своих данных и кода и не пытаться выполнить входные данные как код. тем не менее, как бы варварски это не звучало, в общем случае некорректная работа программы при некорректных входных данных для некоторого подмножества ПО, имхо, может быть отнесена к нецелевому использованию этого ПО.
А почему ты все сводишь только к входным данным, причем только к тем, которые может ввести пользователь системы? У примеру, я видел уязвимость в web приложении, которая заключалась в том, что в таблицу БД складывалось значение HTTP заголовка User-Agent безо всякой предварительной фильтрации.
А если речь вообще идет о каком-нибудь race condition (это тоже прокол в построении автомата)?
V>разумеется, наличие верификации данных — это не бинарная характеристика ПО
ишь как излагает шельма (с)
V> если, к примеру, математический пакет падает при попытке вычислить в действительной системе корень от отрицательного числа, то это по меньшей мере "некрасиво", но если этот пакет падает, если ему подсунуть вместо аргумента для корня вместо числа в строковой форме поток бинарных данных, то это "значительно менее некрасиво" %)
Абсолютно одинаково. Если, допустим, речь идет о системе АСУ ТП, которой в результате сбоя в сети пришли искаженные данные от датчика и она помера от
этого? Тут даже злого умысла не надо... Тот же clipboard приводит к тому, что приложение потенциально должно быть готово получить из него все, что угодно.
Здравствуйте, DOOM, Вы писали:
DOO>Покажи мне хоть одно ТЗ, определяющее функционал АС с точностью до последнего входного сигнала и реакции на него.
АС в данном контексте — аналоговая схема, автоматизированная система, атомная станция, etc?
V>>тз бывают формальными, тз бывают педанитичными. в околоисследовательских задачах тз могут вообще не содержать конкретики. DOO>Каким бы ни было ТЗ оно не может описать весь входной язык, все состояния автомата и функцию перехода. Это просто нереально.
it depends (c)
V>>но если в тз явно указанно, что лигитимным входом считается, например, число в некотором диапазоне в строковой форме, а программе на вход подали кусок исполнямого кода, то это можно рассматривать как выход за определение конечного автомата. DOO>Нет-нет-нет. Еще раз — так нечестно. Входной язык в данном случае это именно любой набор сигналов, которые возможно передать в систему. ТЗ тут не при чем абсолютно.
собственно, вопрос в реакции системы на нелегитимные входные данные. с одной стороны, это нецелевое использование ПО (кухонным комбайном из катапульты) — все возможные виды воздействия предусмотреть весьма трудоемко, да не всегда нужно. с другой стороны, валидация входных данных, корректная обработка нелегитимных (и прочие меры aka defensive programming) относятся к минимально необходимому джентельменскому набору большинства ПО. имхо, минимальные требования в каждом случае зависят задачи, и абсолютно всегда требовать от софта корректности в 100% ситуаций слишком расточительно.
DOO>А почему ты все сводишь только к входным данным, причем только к тем, которые может ввести пользователь системы?
где я говорю только о пользователях системы?
DOO>У примеру, я видел уязвимость в web приложении, которая заключалась в том, что в таблицу БД складывалось значение HTTP заголовка User-Agent безо всякой предварительной фильтрации.
Это не входные данные системы?
DOO>А если речь вообще идет о каком-нибудь race condition (это тоже прокол в построении автомата)?
race condition, имхо, трудно отнести к потенциальным уязвимостям перед атаками, разве что только в некоторых случаях для DoS.
V>> если, к примеру, математический пакет падает при попытке вычислить в действительной системе корень от отрицательного числа, то это по меньшей мере "некрасиво", но если этот пакет падает, если ему подсунуть вместо аргумента для корня вместо числа в строковой форме поток бинарных данных, то это "значительно менее некрасиво" %) DOO>Абсолютно одинаково. Если, допустим, речь идет о системе АСУ ТП, которой в результате сбоя в сети пришли искаженные данные от датчика и она помера от этого? Тут даже злого умысла не надо... Тот же clipboard приводит к тому, что приложение потенциально должно быть готово получить из него все, что угодно.
в общем-то, не спорю.
тем не менее, асутп аэс и асутп арбузорастительного комбината — разные вещи с точки зрения требований к надежности. именно минимальных требований, но, разумеется, никак не верхнего ограничения культуры разработки.
Здравствуйте, vayerx, Вы писали:
DOO>>Каким бы ни было ТЗ оно не может описать весь входной язык, все состояния автомата и функцию перехода. Это просто нереально.
V>it depends (c)
Пример такого ТЗ, раз depends
DOO>>А почему ты все сводишь только к входным данным, причем только к тем, которые может ввести пользователь системы? V>где я говорю только о пользователях системы?
Хорошо переформулируем — ты все ограничиваешь только синхронными данными, не учитывая, например, асинхронные сигналы.
Про обработку отказов оборудования я вообще молчу.
DOO>>У примеру, я видел уязвимость в web приложении, которая заключалась в том, что в таблицу БД складывалось значение HTTP заголовка User-Agent безо всякой предварительной фильтрации. V>Это не входные данные системы?
По твоим рассуждениям создается такое впечатление.
DOO>>А если речь вообще идет о каком-нибудь race condition (это тоже прокол в построении автомата)?
V>race condition, имхо, трудно отнести к потенциальным уязвимостям перед атаками, разве что только в некоторых случаях для DoS.
Ну я о багах в целом, а уж как эксплуатировать ту или иную ошибку, чтобы получилась законченная атака способы найдутся...
DOO>>Абсолютно одинаково. Если, допустим, речь идет о системе АСУ ТП, которой в результате сбоя в сети пришли искаженные данные от датчика и она помера от этого? Тут даже злого умысла не надо... Тот же clipboard приводит к тому, что приложение потенциально должно быть готово получить из него все, что угодно.
V>в общем-то, не спорю. V>тем не менее, асутп аэс и асутп арбузорастительного комбината — разные вещи с точки зрения требований к надежности. именно минимальных требований, но, разумеется, никак не верхнего ограничения культуры разработки.
В общем-то да. Но опять же, если речь о коробочном продукте (в смысле для массового использования), то тут ты уже не знаешь будет это АЭС или арбузорастительный комбинат.
Здравствуйте, vayerx, Вы писали:
V>>>в калькуляторе windows? R>>Может быть . Гарантировать их отстутвие мы не можем.
V>строго доказать отсутствие уязвимостей крайне дорого практически для любого софта — примем это как данное.
А можно узнать подробнее о методиках пусть и дорогого, но вполне строго доказательства отсутствия уявзимостей в конкретном приложении? Я весь во внимании
V>вы же утверждали, что "дыры, связанные с переполнением буфера случаются сплошь и рядом" и, более того, везде. извиняюсь за такую придирчивость, но вы таки знаете о дырах в калькуляторе windows?
А вы таки можете с уверенностью утверждать что их там нет лишь на основании того, что ранее они не были обнаружены?
R>>Представим такую ситуацию. Мы настраиваем рабочее место в Интернет-кафе. Чтобы пользователи не натворили дел, запрещаем запуск regedit. Но доступ к calc.exe оставляем, мало ли кому что посчитать захочется. Но: преположим, в ТЗ к калькулятору не было требования обеспечить устойчивость к атакам. Ведь его можно отнести к "прикладным математическим пакетам, не содержащего сетевых компонентов". И если в нем оставили баг с переполнением, то у посетителя появляется возможность писать в реестр все, что угодно.
V>в данном вопросе у меня другое вероисповедание. вместо заковывания в броню каждого калькулятора, вопрос защиты реестра должен решаться ограничением прав доступа пользователя к уязвимым веткам. это, имхо, исключительно вопрос администрирования/разработки системного ПО, а не разработки прикладного.
А еще этот вопрос может решаться помещением калькулятора в песочницу, дабы исключить какое-либо пагубное влияние на систему. Или переписыванием его на управляемой платформе...
R>>Получается, мы вынуждены требовать надежности от любого софта. И если в ТЗ нет таких требований, то это скорее по незнанию, а не тщательно обдуманное решение. V>таки как раз наоборот. надежности от любого софта требовать не нужно, как минимум, из-за того, что это обойдется сильно дороже.
А необходимая надежность софта тоже определяется его принадлежностью к какому-либо классу, или нет?
Здравствуйте, CreatorCray, Вы писали:
R>>А если бы "лису" писали на дотнете, их бы не было. CC>И бОльшей части пользователей лисы — тоже. CC>Вы хоть один браузер на .net видели?
Ну имелся в виду не конкретно дотнет, а вообще платформы и методики, где у программиста нет доступа к голым указателям и буферам.
CC>Если пользователь может скачать и запустить что либо у него тоже есть доступ к реестру.
Здравствуйте, дорогие коллеги, искатели уязвимостей! Мне кажется что как-то однобоко тема обсуждается. А что если дыры в системе делаются умышленно? Например, почему у Ирака вышли из строя компьютеры когда американские самолеты полетели бомбить эту страну?
Во всяком случае соблазн оставить в форточках дыры для личных нужд Пентагона достаточно велик. И врядли там упустили такую возможность. Это не только мое мнение. Есть много информации на эту тему в интернете.
Что касается написания программ, я программирую на С++ и довольно большие, но не комерческие программы. Скажу так, можно научиться писать программы (и свои библиотеки) максимально строго, так что найти уязвимость будет очень сложно, но она обязательно будет. Без этого наверное невозможно. Но это дорого, по времени. Так что цена — увеличение размера и уменьшение скорости при использовании дот-нета наверное оправданно.
Куплил недавно ноутбук с Вистой на борту. Впечатление от операционки — тяжелое. Еще не осознал наверное преимуществ встроенной защиты. Если учесть что дыры там по определению есть, то нафиг все это нужно.
Здравствуйте, ua1zcl, Вы писали:
U>Здравствуйте, дорогие коллеги, искатели уязвимостей! Мне кажется что как-то однобоко тема обсуждается. А что если дыры в системе делаются умышленно? Например, почему у Ирака вышли из строя компьютеры когда американские самолеты полетели бомбить эту страну? U>Во всяком случае соблазн оставить в форточках дыры для личных нужд Пентагона достаточно велик. И врядли там упустили такую возможность. Это не только мое мнение. Есть много информации на эту тему в интернете.
Даже если уязвимость есть надо еще получить доступ. На многих объектах государственного значения компьютеры с секретной информацией работают исключительно в закрытых зонах, где ни то что интернета, где даже флешку некуда воткнуть... Стоит тонкий клиент с портом для монитора, клавиатуры, мыши и больше ничего.
U> Что касается написания программ, я программирую на С++ и довольно большие, но не комерческие программы. Скажу так, можно научиться писать программы (и свои библиотеки) максимально строго, так что найти уязвимость будет очень сложно, но она обязательно будет. Без этого наверное невозможно. Но это дорого, по времени. Так что цена — увеличение размера и уменьшение скорости при использовании дот-нета наверное оправданно.
Вопрос производительности уж давным-давно не стоит ребром. Java на enterprise рынке уже с добрый десяток лет лидирует, а за это время: а) производительность и ресурсы компьютеров многократно выросли; б) производительность самой JVM многократно возросла. .NET CLR же не уступает, а возможно местами и превосходит JVM в плане производительности.
Вообще производительность и ресурсы имеют значение только тогда, когда они недостаточны. Да и возможность быстрее писать программы дает простор для более тщательной алгоритмической оптимизации и время на выявление и профилирование узких мест при той же стоимости разработки.
U> Куплил недавно ноутбук с Вистой на борту. Впечатление от операционки — тяжелое. Еще не осознал наверное преимуществ встроенной защиты. Если учесть что дыры там по определению есть, то нафиг все это нужно.
Обсуждали сто раз — на топовом железе Vista и особенно Vista 64 работает быстрее XP за счет сильно улучшенного менеджера памяти.
) — вполне себе современное и весьма популярное приложение, вопросы безопасности которого (в силу хотя бы того, что это веб-браузер) уж явно стоят не на последнем месте как у его разработчиков, так и его пользователей.
