Здравствуйте, frogkiller, Вы писали:
F>Здравствуйте, kochetkov.vladimir, Вы писали:
F>[многабукоф]
KV>>Ну вот, пожалуй и все. Можете рвать
F>Ну, рвать — не рвать, но контр-аргументов я парочку добавлю.
F>1. "Стоимость" необнаруженной уязвимости в управляемом фреймворке значительно превышает такую "стоимость" узявимости в нативном коде — за счёт масштабов распространения и унификации. Так что в "мат. ожидание" вреда (= вероятность уязвимости * вред от неё), полагаю, для двух наиболее популярных фреймворков повыше, чем для отдельного нативного приложения.
А если сравнивать управляемый фреймворк не с еденичным нативным приложением, а с нативной библиотекой типа boost'а или операционной системой?
F>2. Тенденции в отрасли таковы, что с каждым годом доля одиночных приложений будет только уменьшаться в пользу серверных (термин cloud computing мне не очень нравится, но пусть будет). И чем дальше, тем в большей степени это всё будет поддерживаться на аппаратном уровне. Соответственно, фоннеймовская архитектура в обозримом будущем если и не уйдёт в небытие, то очень сильно сдаст свои позиции — так что не будет самого предмета спора.
А на чем тогда сервера в облаке будут крутиться?
F>С этой точки зрения фреймворки в плане безопасности выглядят как временные костыли, возможно даже и препятствующие эффективной защите.
Ну суть-то этой защиты в том, чтобы перенести головную боль с клиентской стороны на серверную, не более того. Но боль-то останется?
Здравствуйте, Mamut, Вы писали:
KV>>P.S: Хочу обратить внимание, что в бюллетене http://secunia.com/advisories/31132/ сообщается об уязвимости переполнения буфера, применимой только к MacOSX. Это чтобы нарваться еще и на юниксоидов и Мамута
M>Ж)
M>На МакОСИ все это усугубляется сильной непрозрачностью процеса выпуска патчей. То есть если с Мозиллой все понятно — они-то могут среагировать и апдейтнуть, то с официальными Эппловскими продуктами не все так радужно. Часто security updates выходят с одной строчкой типа «fixed numerous issues» — и все
А они считают выделенное дополнительной мерой по безопасности (т.е. не раскрывать информацию об уязвимости, даже после ее обнаружения и исправления) Но учитывая то, что довольно большой процент эксплоитов пишется через реверсинг выпускаемых патчей, это какая-то неэффективная мера.
V>вы либо сильно перевираете сказанное мной, либо крайне невнимательно читали мои комментарии, либо почему-то сделали акцент на "выгодных" себе вещах.
Все понял, мы действительно о разных вещах говорим. Вы говорите о защите сферических и обособленных приложений от информационных угроз в вакууме. Т.е. рассматривая само приложение как цель защиты. Я же говорю о защите ОС и других приложений от угроз, которые несет за собой использование уязвимого приложения в этой "экосистеме".
Здравствуйте, 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 слабо отличается от простого многопоточного приложения — проблемы и пути решения абсолютно одинаковые
Здравствуйте, 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>Я прав?
Здравствуйте, 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>Нет, можно конечно рассылать ссылки голубиной почтой, или устроить обзвон кывтюгкцев и надиктовку им эксплоита голосом...
Ага — НЛП. А потом человек сам удаляет у себя файлы, рассылает спам и пр.
Мне кажется, vayerx неправильно выбрал позицию для поливания дотнета. Дыры, связанные с переполнением буфера случаются сплошь и рядом и никакие отмазки тут неуместны. Другое дело, что в С++ есть все средства для написания кода в стиле, предотвращающем их появление, и при этом накладывающие оверхед небольший, чем дотнет. Основная проблема состоит в том, что большинство продолжают писать на С++ как на С с классами, даже в крупных и уважаемых проектах.
Здравствуйте, roman10, Вы писали:
R>Мне кажется, vayerx неправильно выбрал позицию для поливания дотнета.
Мне кажется, вы тоже не отличаетесь внимательностью, либо не утруждаете себя чтением перед выдвижением гипотез.
Я не "поливаю дотнет", я поливаю опус г-на kochetkov.vladimir
и мнение о том, что прилагать дополнительные меры по защите софта от атак нужно далеко не в любом софте. и меня очень сильно удивляет, когда в контрпримерах мне приводят, например, дыры в браузерах — браузеры безусловно относятся к разряду того софта, который защищать необходимо.
R>Дыры, связанные с переполнением буфера случаются сплошь и рядом и никакие отмазки тут неуместны.
опечатался:
V>Мне кажется, вы тоже не отличаетесь внимательностью, либо не утруждаете себя чтением перед выдвижением гипотез. V>Я не "поливаю дотнет", я поливаю опус г-на kochetkov.vladimir
V>мнение о том, что прилагать дополнительные меры по защите софта от атак нужно абсолютно в любом софте.
Почему же? Дыра это баг, отказаться от устранения дыр равносильно признанию, что мы намеренно отдаем заказчику глючный продукт.
R>>Дыры, связанные с переполнением буфера случаются сплошь и рядом и никакие отмазки тут неуместны.
V>Где?
Да везде
Здравствуйте, 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% в браузере такая защита потребуется. но есть и менее однозначные виды ПО и возникает несколько путей разработки, если вдруг заказчик не хочет тратить деньги на реализацию и даже тестирование безопасности: обеспечить безопасность в свое личное время и потратить свои деньги (возможно, подняв свою репутацию, а, возможно, и нет, если заказчик этого даже не заметит); неявно включить стоимость безопасности в смету и, возможно, потерять клиента; сделать то, что хочет клиент (если в последствии защита ему потребуется, это будет дополнительным заказом, возможно, потребующим переписания значительной части софта).
