Здравствуйте, vayerx, Вы писали:

V>Здравствуйте, DOOM, Вы писали:

DOO>>Покажи мне хоть одно ТЗ, определяющее функционал АС с точностью до последнего входного сигнала и реакции на него.
V>АС в данном контексте — аналоговая схема, автоматизированная система, атомная станция, etc?


V>тз бывают формальными, тз бывают педанитичными. в околоисследовательских задачах тз могут вообще не содержать конкретики. это все понятно. тем не менее, если перед вами лежит тз на разработку нового браузера и в нем (тз) нет раздела про безопасность, включающего защиту от атак, это странно. думаю, любой квалифицированный разработчик не увидев такого пункта, поинтересовался бы причиной его отсутсвия — то ли заказчик забыл, то ли рассчитывет на услугу "все включенно", то ли ему на это вдруг наплевать и он платить за это не будет.
Каким бы ни было ТЗ оно не может описать весь входной язык, все состояния автомата и функцию перехода. Это просто нереально.


DOO>>Честное определение бага было бы что-то вроде — недетерминированность конечного автомата, соответсвующего АС (это более менее понятно, хотя и не совсем верно). Т.е. если программа при получении определенных входных данных или сигнала или еще чего-то попадает в неопределенное разработчиком состояние, то это баг. Даже, если в результате ничего страшного не происходит.

V>недетерминированность конечного автомата — это, безусловно, ошибка.
Замечательно.

V>но если в тз явно указанно, что лигитимным входом считается, например, число в некотором диапазоне в строковой форме, а программе на вход подали кусок исполнямого кода, то это можно рассматривать как выход за определение конечного автомата.
Нет-нет-нет. Еще раз — так нечестно. Входной язык в данном случае это именно любой набор сигналов, которые возможно передать в систему. ТЗ тут не при чем абсолютно.

V>безусловно, я соглашусь, что квалифицированно написанная программа должна, вероятно (если вдруг обратное не обуславливается спецификой задачи), должна проверять входные данные и если уж не каким-либо образом сообщать об ошибке, то уж по крайней мере не нарушать целостности своих данных и кода и не пытаться выполнить входные данные как код. тем не менее, как бы варварски это не звучало, в общем случае некорректная работа программы при некорректных входных данных для некоторого подмножества ПО, имхо, может быть отнесена к нецелевому использованию этого ПО.
А почему ты все сводишь только к входным данным, причем только к тем, которые может ввести пользователь системы? У примеру, я видел уязвимость в web приложении, которая заключалась в том, что в таблицу БД складывалось значение HTTP заголовка User-Agent безо всякой предварительной фильтрации.
А если речь вообще идет о каком-нибудь race condition (это тоже прокол в построении автомата)?

V>разумеется, наличие верификации данных — это не бинарная характеристика ПО
ишь как излагает шельма (с)

V> если, к примеру, математический пакет падает при попытке вычислить в действительной системе корень от отрицательного числа, то это по меньшей мере "некрасиво", но если этот пакет падает, если ему подсунуть вместо аргумента для корня вместо числа в строковой форме поток бинарных данных, то это "значительно менее некрасиво" %)
Абсолютно одинаково. Если, допустим, речь идет о системе АСУ ТП, которой в результате сбоя в сети пришли искаженные данные от датчика и она помера от
этого? Тут даже злого умысла не надо... Тот же clipboard приводит к тому, что приложение потенциально должно быть готово получить из него все, что угодно.

Здравствуйте, roman10, Вы писали:

R>А если бы "лису" писали на дотнете, их бы не было.
И бОльшей части пользователей лисы — тоже.
Вы хоть один браузер на .net видели?

R>Представим такую ситуацию. Мы настраиваем рабочее место в Интернет-кафе. Чтобы пользователи не натворили дел, запрещаем запуск regedit. Но доступ к calc.exe оставляем, мало ли кому что посчитать захочется. Но: преположим, в ТЗ к калькулятору не было требования обеспечить устойчивость к атакам. Ведь его можно отнести к "прикладным математическим пакетам, не содержащего сетевых компонентов". И если в нем оставили баг с переполнением, то у посетителя появляется возможность писать в реестр все, что угодно.
Если пользователь может скачать и запустить что либо у него тоже есть доступ к реестру.

Здравствуйте, 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>тем не менее, асутп аэс и асутп арбузорастительного комбината — разные вещи с точки зрения требований к надежности. именно минимальных требований, но, разумеется, никак не верхнего ограничения культуры разработки.
В общем-то да. Но опять же, если речь о коробочном продукте (в смысле для массового использования), то тут ты уже не знаешь будет это АЭС или арбузорастительный комбинат.

Здравствуйте, DOOM, Вы писали:

DOO>>>Каким бы ни было ТЗ оно не может описать весь входной язык, все состояния автомата и функцию перехода. Это просто нереально.
V>>it depends (c)
DOO>Пример такого ТЗ, раз depends :)

боюсь, придется поверить на слово. если интересует область ПО: рентгеноспектральный анализ; контроллеры излучателей.


DOO>>>А почему ты все сводишь только к входным данным, причем только к тем, которые может ввести пользователь системы?
V>>где я говорю только о пользователях системы?
DOO>Хорошо переформулируем — ты все ограничиваешь только синхронными данными, не учитывая, например, асинхронные сигналы.

где?

DOO>Про обработку отказов оборудования я вообще молчу.

я отношу это тоже к входным воздействиям на систему.


V>>Это не входные данные системы?
DOO>По твоим рассуждениям создается такое впечатление.

по каким именно рассуждениям?


V>>асутп аэс и асутп арбузорастительного комбината — разные вещи с точки зрения требований к надежности. именно минимальных требований, но, разумеется, никак не верхнего ограничения культуры разработки.
DOO>В общем-то да. Но опять же, если речь о коробочном продукте (в смысле для массового использования), то тут ты уже не знаешь будет это АЭС или арбузорастительный комбинат.

в общем-то, согласен. но будет ли в аэс кто-либо использовать коробочный продукт школьника Васи Пупкина? если речь идет о выполнении требований надежности, то для системы подбираются компоненты, удовлетворяющие этим требованиям, ибо итоговая надежность условно не выше минимально надежного компонента ("условно" — потому, что "надежность" без конкретики применения — это сферический конь в вакууме). соответственно, ничто не мешает совместно существовать коробочным продуктам с надежностью 95%, 99%, 99.999%, решающим одну и ту же задачу, но с различной стоимостью. вряд ли много кому нужен стандартный калькулятор, с надежностью "пять девяток" за $5000 за одну лиценцию.

Здравствуйте, 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 к ПО, уязвимости в котором вполне допустимы.

Я привел его как пример того, насколько разлагающе могут действовать на разработчиков мысле, которые вы тут проталкиваете.

Здравствуйте, vayerx, Вы писали:

V>>>в калькуляторе windows?
R>>Может быть . Гарантировать их отстутвие мы не можем.

V>строго доказать отсутствие уязвимостей крайне дорого практически для любого софта — примем это как данное.

А можно узнать подробнее о методиках пусть и дорогого, но вполне строго доказательства отсутствия уявзимостей в конкретном приложении? Я весь во внимании

V>вы же утверждали, что "дыры, связанные с переполнением буфера случаются сплошь и рядом" и, более того, везде. извиняюсь за такую придирчивость, но вы таки знаете о дырах в калькуляторе windows?

А вы таки можете с уверенностью утверждать что их там нет лишь на основании того, что ранее они не были обнаружены?

R>>Представим такую ситуацию. Мы настраиваем рабочее место в Интернет-кафе. Чтобы пользователи не натворили дел, запрещаем запуск regedit. Но доступ к calc.exe оставляем, мало ли кому что посчитать захочется. Но: преположим, в ТЗ к калькулятору не было требования обеспечить устойчивость к атакам. Ведь его можно отнести к "прикладным математическим пакетам, не содержащего сетевых компонентов". И если в нем оставили баг с переполнением, то у посетителя появляется возможность писать в реестр все, что угодно.

V>в данном вопросе у меня другое вероисповедание. вместо заковывания в броню каждого калькулятора, вопрос защиты реестра должен решаться ограничением прав доступа пользователя к уязвимым веткам. это, имхо, исключительно вопрос администрирования/разработки системного ПО, а не разработки прикладного.

А еще этот вопрос может решаться помещением калькулятора в песочницу, дабы исключить какое-либо пагубное влияние на систему. Или переписыванием его на управляемой платформе...

R>>Получается, мы вынуждены требовать надежности от любого софта. И если в ТЗ нет таких требований, то это скорее по незнанию, а не тщательно обдуманное решение.
V>таки как раз наоборот. надежности от любого софта требовать не нужно, как минимум, из-за того, что это обойдется сильно дороже.

А необходимая надежность софта тоже определяется его принадлежностью к какому-либо классу, или нет?

V>низкоквалифицированные разработчики всегда были, есть, и, видимо, будут есть. ориентироваться на них тоже не стоит. так же, как и не стоит забывать, что допускать ошибки могут все. много ли существует "серьезных" коммерческих продуктов, написанных неквалифицированными разработчиками, код которых никто ни разу не просматривал?

Это все верно, однако верно и то, что софт на дотнете потенциально содержит меньше дыр, чем на С++. Причем это уменьшение дается нам фактически бесплатно. Допустим перед нами две программы, реализующих одинаковый функционал, только одна на C++, другая на C#. Вы не можете наперед точно сказать, в какой меньше дыр, но можете заявить, что в варианте C# как минимум дыр с переполнением нет.

V>вряд ли вы сочтете более защищенным продукт написанный на управляемой платформе, но, к примеру, хранящий все пароли в тесктовом файле и позволяющий выполнить произвольный sql запрос пользователя.

Мне кажется, переполнение буфера и хранение паролей в текстовом файле — дыры разного уровня. Допустить дыру с паролями (или аналогичную) просто так не получится, нужно сознательно принять решение и написать код. Дыры же с переполнением случаются почти машинально, едва ли не на уровне опечатки, и допустить их может кто угодно и когда угодно. Единственный надежный способ от них избавиться — лишить программиста возможности совершить их.


V>строго доказать отсутствие уязвимостей крайне дорого практически для любого софта — примем это как данное.

Дорого — для произвольного, уже имеющегося софта. Но если при его разработке использована "правильная" технология, доказательство у нас в кармане .

V>в данном вопросе у меня другое вероисповедание. вместо заковывания в броню каждого калькулятора, вопрос защиты реестра должен решаться ограничением прав доступа пользователя к уязвимым веткам. это, имхо, исключительно вопрос администрирования/разработки системного ПО, а не разработки прикладного.

А причем тут ваше вероисповедание? . Интернет-кафе лишь пример. Мало ли какая возникнет ситуация и потребуется обеспечить разграничение прав на более высоком уровне, чем позволяет механизм безопасности Windows. Всего не предусмотришь. И решение будет принимать сотрудник кафе, а он не обязан держать в голове, какие программы с какими требованиями разрабатывались. А если потребовать от него это знание, или пытать разграничивать, где и когда можно использовать калькулятор, наступит сплошной хаос.

Другими словами, если мы хотим кардинально решить проблему дырявого софта, то гораздо эффективнее сделать безопасной каждую программу в отдельности, чем выдумать всякие разграничительные меры.

V>таки как раз наоборот. надежности от любого софта требовать не нужно, как минимум, из-за того, что это обойдется сильно дороже.

Дороже на С++. Но дотнете дешевле .

Здравствуйте, CreatorCray, Вы писали:

R>>А если бы "лису" писали на дотнете, их бы не было.
CC>И бОльшей части пользователей лисы — тоже.
CC>Вы хоть один браузер на .net видели?

Ну имелся в виду не конкретно дотнет, а вообще платформы и методики, где у программиста нет доступа к голым указателям и буферам.

CC>Если пользователь может скачать и запустить что либо у него тоже есть доступ к реестру.

Скачку чего-либо тоже запрещаем .

Здравствуйте, дорогие коллеги, искатели уязвимостей! Мне кажется что как-то однобоко тема обсуждается. А что если дыры в системе делаются умышленно? Например, почему у Ирака вышли из строя компьютеры когда американские самолеты полетели бомбить эту страну?
Во всяком случае соблазн оставить в форточках дыры для личных нужд Пентагона достаточно велик. И врядли там упустили такую возможность. Это не только мое мнение. Есть много информации на эту тему в интернете.
Что касается написания программ, я программирую на С++ и довольно большие, но не комерческие программы. Скажу так, можно научиться писать программы (и свои библиотеки) максимально строго, так что найти уязвимость будет очень сложно, но она обязательно будет. Без этого наверное невозможно. Но это дорого, по времени. Так что цена — увеличение размера и уменьшение скорости при использовании дот-нета наверное оправданно.
Куплил недавно ноутбук с Вистой на борту. Впечатление от операционки — тяжелое. Еще не осознал наверное преимуществ встроенной защиты. Если учесть что дыры там по определению есть, то нафиг все это нужно.

Здравствуйте, ua1zcl, Вы писали:

U>Здравствуйте, дорогие коллеги, искатели уязвимостей! Мне кажется что как-то однобоко тема обсуждается. А что если дыры в системе делаются умышленно? Например, почему у Ирака вышли из строя компьютеры когда американские самолеты полетели бомбить эту страну?
U>Во всяком случае соблазн оставить в форточках дыры для личных нужд Пентагона достаточно велик. И врядли там упустили такую возможность. Это не только мое мнение. Есть много информации на эту тему в интернете.
Даже если уязвимость есть надо еще получить доступ. На многих объектах государственного значения компьютеры с секретной информацией работают исключительно в закрытых зонах, где ни то что интернета, где даже флешку некуда воткнуть... Стоит тонкий клиент с портом для монитора, клавиатуры, мыши и больше ничего.

U> Что касается написания программ, я программирую на С++ и довольно большие, но не комерческие программы. Скажу так, можно научиться писать программы (и свои библиотеки) максимально строго, так что найти уязвимость будет очень сложно, но она обязательно будет. Без этого наверное невозможно. Но это дорого, по времени. Так что цена — увеличение размера и уменьшение скорости при использовании дот-нета наверное оправданно.
Вопрос производительности уж давным-давно не стоит ребром. Java на enterprise рынке уже с добрый десяток лет лидирует, а за это время: а) производительность и ресурсы компьютеров многократно выросли; б) производительность самой JVM многократно возросла. .NET CLR же не уступает, а возможно местами и превосходит JVM в плане производительности.

Вообще производительность и ресурсы имеют значение только тогда, когда они недостаточны. Да и возможность быстрее писать программы дает простор для более тщательной алгоритмической оптимизации и время на выявление и профилирование узких мест при той же стоимости разработки.

U> Куплил недавно ноутбук с Вистой на борту. Впечатление от операционки — тяжелое. Еще не осознал наверное преимуществ встроенной защиты. Если учесть что дыры там по определению есть, то нафиг все это нужно.
Обсуждали сто раз — на топовом железе Vista и особенно Vista 64 работает быстрее XP за счет сильно улучшенного менеджера памяти.