Это плохой пример.

Описанный юз кейс , является достаточно четким добросовестным применением калькулятора. И если он валится , он не выполняет своей функциональности.

А вот изменение бинарного кода калькулятора из FAR а однозначно недобросовестное использование.

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


KV>Но что еще более важно:

KV>2. В случае с управляемыми платформами, ответственность за устранение уязвимостей, обусловленных архитектурой фон-Неймана берут на себя ее разработчики, избавляя тем самым от этой возни разработчиков приложения. Хочу заметить, что разработчиками данной платформы являются отнюдь не студенты трех месяцев выпуска, а достаточно серьезная компания, вкладывающая в безопасность своих продуктов огромные деньги, средства и ресурсы. И заинтересованная в том, чтобы их продукт, позиционирующийся как в т.ч. "матрица" для аппаратной архитектуры в плане безопасности, был реально безопасен. Вам известно много случаев обнаружения и/или эксплуатации уязвимостей нулевого дня в рантайме дотнета?

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


KV>Наивно полагать, что в общем случае, разработчик приложения сможет организовать меры по обеспечению ИБ ХОТЯ БЫ на таком же уровне, на котором это делает данная конкретная "серьезная компания". Тем более, что ему и так есть чем заняться, помимо обеспечения безопасности своего продукта.

Что есть серьёзная компания ? В "серьёзных компаниях" безопасность обеспечивают.... или вы считаете,что везде работают "студенты трех месяцев выпуска"?

KV>Не менее наивно полагать, что (например) среднестатический LAMP-разработчик в состоянии обеспечить хотя 1/10 тех мер безопаности, которую за него ему обеспечили разработчики php/perl/python, mysql, apache с mod_security и используемого дистрибутива linux. Когда же речь заходит об аналогичных мерах от MS это почему-то вызвает эффект красной тряпки

А при чём тут вообще win/lin?

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

+ верифицировать дотнет рантайм ,наверно, попроще чем вин/лин...

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

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

KV>>Успешных атак (повлекших за собой ущерб) за рассматриваемый период не было.

V>либо вы о них не знаете

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

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

E>Т.е. корпорации, на потенциал которой здесь так уповают, было проще в течении 9-ти месяцев молчать и не выпускать патч.

Тебе не кажется, что если бы ей было реально воспользоваться, для компроментации то шумиха поднялась конкретная, и пресса мимо такого бы не прошла?

Но ОК, одна уязвимость засчитана Но она была закрыта 10.07.2007 и теперь ее, увы — нет.

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

M>>>Я например разрабатываю программы которые направленны на работу с добросовестным пользователем. А попытки неправильного использования не рассматриваются как use case

KV>>Вы готовы поговорить тут об этом (ваших программах и решаемых ими задачах) подробнее?
M>Нет ни малейшего желания, но на всякий случай я не педалю "web придожения", а занимаюсь наукоемкими тяжелыми вычислениями.

Тогда извиняюсь за пример с калькулятором. Знал бы — вместо него выбрал веб-приложение

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

V>собственно, оставшиеся две трети =)
V>ну а если серьезно, то "более высокие риски" — сферическое понятие. его стоит разделить, как минимум, на сложность взлома, потенциальный причиняемый урон.
V>начнем с "банального" sql injection — никак не зависит от архитектуры фон-Неймана. реализация значительно проще code injection. в случае успеха атаки утечка данных может быть практически максимальной. code injection, конечно, может принести чуть больший ущерб, кражи той же самой клиентской приватной информации может оказаться вполне достаточной для банкротсва компании, особенно на начальной стадии ее развития.

V>password cracking — никак не зависит от архитектуры фон-Неймана. регулярное явление. если на сервере нужен внешний ssh, управляемый код не поможет.

V>и т.д.

Это-то так, но суть как раз в том, что разрабатывая под неуправляемую платформу, разработчикам приходится думать И об инъекциях бинарного кода, И о более "прикладных" атаках. Честно говоря, я это уже устал повторять.

V>>>1. "уронить сервер" — это потенциально огромные финасовые потери.
KV>>А "оставить в сервере закладку и взять его под контроль" — это еще большие риски, т.к. с использованием данной закладки на сервер может осуществляться и DoS атаки в том числе.

V>чтобы оставить на "сервере закладку" именно code injection не обязателен.

Но если был code injection, то можно оставить на сервере закладку, в отличии от DoS атаки.

V>>>во-вторых, на *nix эта фича .net уже портированна?
KV>>да
V>>>а на C64?
KV>>хз, к чему этот вопрос?

V>вопрос к портируемости.

Это не ко мне.

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

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

KV>>После этого, мы идем в "Коллеги улыбнитесь" и еще на десяток подобных ресурсов и постим там подготовленную нами строку под видом пасхального яйца с подробными инструкциями по его активации. Разумеется, для якобы активации яйца нужно скопировать нашу строку в буфер и затем вставить в калькулятор.

V>а зачем так сложно-то? рассылаем коллегам ссылочку "ой! какая классная программка: url"

От коллег потом можно и в дыню получить, если что

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

KV>>1. В виндовом калькуляторе есть парсер арифметических выражений, причем не самый тривиальный.
KV>>2. Теоретически, данный парсер может быть уязвим к атакам на переполнение буфера, если в его реализации допущены ошибки.

E>Этот сценарий когда-нибудь для Windows-калькулятора был реализован в реальной жизни?

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

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

E>Читать забавно:
E>

E>Security consultant and researcher at Security-Assessment.com Matthew Strahan said a filename which contains a null byte in the .Net environment can launch a Null byte injection attack which allows servers to be fully compromised.

E>He said a flaw exists in an upload file code when the .Net Common Language Runtime (CLR) considers Null bytes as data to directly call a native C function call.

Мутное какое-то описание. Вот здесь мне понравилось больше.

E>Поскольку никакая мейнстримовая управляемая среда на работает на голом железе, то появляется возможность добить ее с помощью нативного кода.

Смести немного акценты и фраза зазвучит иначе: т.к. нативный код оч. легко подвержен эксполоитам, то его стоит максимально замещать управляемым кодом.

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

E>>Т.е. корпорации, на потенциал которой здесь так уповают, было проще в течении 9-ти месяцев молчать и не выпускать патч.

KV>Тебе не кажется, что если бы ей было реально воспользоваться, для компроментации то шумиха поднялась конкретная, и пресса мимо такого бы не прошла?

Судя по тому, что написано здесь, воспользоваться ей все-таки можно. Например при определенных условиях можно получить доступ к web.config-у.

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

V>ну а если серьезно, то "более высокие риски" — сферическое понятие. его стоит разделить, как минимум, на сложность взлома, потенциальный причиняемый урон.
V>начнем с "банального" sql injection — никак не зависит от архитектуры фон-Неймана. реализация значительно проще code injection.

ну вообще-то sql injection — это тоже в своем роде code injection

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

KV>После этого, мы идем в "Коллеги улыбнитесь" и еще на десяток подобных ресурсов и постим там подготовленную нами строку под видом пасхального яйца с подробными инструкциями по его активации. Разумеется, для якобы активации яйца нужно скопировать нашу строку в буфер и затем вставить в калькулятор.

Я попробовал себе представить внешний вид данной "строки", чтобы на программерском форуме человек не увидел подвоха и "вставил" бы это дело в калькулятор

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

KV>>>А почему многие считают, что незащищенный код == рабочий код?
ГВ>>Наверное, потому что этот код работает.

KV>Ровно до тех пор, пока ему не передали на вход то, что там совсем не ожидалось. Или тут схема "пока петух в ж не клюнет..."?

Тут схема такая, что всякая сложная проблема имеет простое и очевидное неправильное решение. Вот тебе и вся схема.

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

L>Мутное какое-то описание. Вот здесь мне понравилось больше.

Я привел первые ссылки, которые мне выдал Google на запросы "Java vulnerability" и ".NET vulnerability"

E>>Поскольку никакая мейнстримовая управляемая среда на работает на голом железе, то появляется возможность добить ее с помощью нативного кода.

L>Смести немного акценты и фраза зазвучит иначе: т.к. нативный код оч. легко подвержен эксполоитам, то его стоит максимально замещать управляемым кодом.

Нативный код нативному рознь. Мне кажется, что фобии, которые здесь обсуждают являются следствием распространенности C и C++ (унаследовавшего проблемы C). Тогда как для нативных языков вроде Modula-2, Oberon, Eiffel и OCaml ситуация должна быть гораздо, гораздо лучше. Не говоря уже о строгих функциональных языках, которые транслируются в нативный код.

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

B>Здравствуйте, kochetkov.vladimir, Вы писали:


KV>>Но что еще более важно:

KV>>2. В случае с управляемыми платформами, ответственность за устранение уязвимостей, обусловленных архитектурой фон-Неймана берут на себя ее разработчики, избавляя тем самым от этой возни разработчиков приложения. Хочу заметить, что разработчиками данной платформы являются отнюдь не студенты трех месяцев выпуска, а достаточно серьезная компания, вкладывающая в безопасность своих продуктов огромные деньги, средства и ресурсы. И заинтересованная в том, чтобы их продукт, позиционирующийся как в т.ч. "матрица" для аппаратной архитектуры в плане безопасности, был реально безопасен. Вам известно много случаев обнаружения и/или эксплуатации уязвимостей нулевого дня в рантайме дотнета?

B>А вам не кажется,что их нет по той простой причине,что искать и использовать их гораздо менее выгодно,чем уязвимости в native?

Безусловно, количество обнаруженных уязвимостей напрямую зависит от популярности продукта. Но ASP.NET (например) не такой уж и не популярный, чтобы на него не стоило обратить внимание пытливым black-hat'ам.

KV>>Наивно полагать, что в общем случае, разработчик приложения сможет организовать меры по обеспечению ИБ ХОТЯ БЫ на таком же уровне, на котором это делает данная конкретная "серьезная компания". Тем более, что ему и так есть чем заняться, помимо обеспечения безопасности своего продукта.

B>Что есть серьёзная компания ? В "серьёзных компаниях" безопасность обеспечивают.... или вы считаете,что везде работают "студенты трех месяцев выпуска"?

Разумеется не везде. Но если политика компании "нам отдельно не заплатили за то, чтобы наш код был безопасным", то в моем понимании, серьезно относится к такой конторке и ее продуктам не стоит. И строить на них свой или чужой бизнес — тоже, btw.

KV>>Не менее наивно полагать, что (например) среднестатический LAMP-разработчик в состоянии обеспечить хотя 1/10 тех мер безопаности, которую за него ему обеспечили разработчики php/perl/python, mysql, apache с mod_security и используемого дистрибутива linux. Когда же речь заходит об аналогичных мерах от MS это почему-то вызвает эффект красной тряпки

B>А при чём тут вообще win/lin?

Ну прозвучало же про кроссплатформенность. Почему бы и нет?

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

M>Это плохой пример.

M>Описанный юз кейс , является достаточно четким добросовестным применением калькулятора. И если он валится , он не выполняет своей функциональности.

M>А вот изменение бинарного кода калькулятора из FAR а однозначно недобросовестное использование.

Если честно, то после этого сообщения я вообще потерял нить твоих рассуждений о добросовестности использования ПО

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

L>>Смести немного акценты и фраза зазвучит иначе: т.к. нативный код оч. легко подвержен эксполоитам, то его стоит максимально замещать управляемым кодом.

E>Нативный код нативному рознь. Мне кажется, что фобии, которые здесь обсуждают являются следствием распространенности C и C++ (унаследовавшего проблемы C). Тогда как для нативных языков вроде Modula-2, Oberon, Eiffel и OCaml ситуация должна быть гораздо, гораздо лучше.

Так ситуация для них и так гораздо-гораздо лучше. Если такая лажа — в первых строчках гугла, то это наиболее "громкая" уязвимость на .Net-е. А она даже произвольный код не дает исполнить. На неуправляемых языках такого рода проблемы гораздо более на слуху.

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

E>>Нативный код нативному рознь. Мне кажется, что фобии, которые здесь обсуждают являются следствием распространенности C и C++ (унаследовавшего проблемы C). Тогда как для нативных языков вроде Modula-2, Oberon, Eiffel и OCaml ситуация должна быть гораздо, гораздо лучше.

L>Так ситуация для них и так гораздо-гораздо лучше.

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

L>Если такая лажа — в первых строчках гугла, то это наиболее "громкая" уязвимость на .Net-е.

Либо другой взгляд на мир -- .Net как "неуловимый Джо", который нафиг никому пока не упало взламывать
А для Java, afaik, это уже не первая уязвимость.

L>На неуправляемых языках такого рода проблемы гораздо более на слуху.

Visual Basic for Application из MS Word/Excel, насколько я знаю, управляемые языки. А вредоносных программ на них написано столько, что С/C++ и не снилось.

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

KV>Я не имею права назвать конкретные цифры, к сожалению

Чёрт с ними с цифрами, ты хочешь сказать, что у вас в инсайдерах сидят "профессионалы" и занимаются тем, что атакуют ваши системы??? То что на внешнем периметре такие есть — я не сомневаюсь, но вот внутренние товарищи должны болеть за своё дело в прямом и переносном смысле.

Ладно, попробуем погадать:
1) Внутренний периметр == внешнему периметру.
Если внутренний и внешний периметр не имеют специально выделенных областей (например honeypots), то статистически понятно: чем больше пользователей — тем больше будет зафиксировано "подозрительных" событий, независимо от самих событий. Конкретные атаки на статистику повлиять не смогут — их гораздо меньше.
2) Внутренний периметр меньше внешнего,
Внутри сидят специалисты и автоматические системы, которые только тем и занимаются, что атакуют внутренний периметр (например, тот же XSpider отрабатывает свою стоимость),
3) Внутренний периметр больше внешнего (но периметры не имеют выделенных областей),
Пусть соотношение будет 1:50, то есть на 1 внутреннее "подозрительное" событие, существует 50 внешних. Если оценить кол-во интранет пользователей и умножить на 50, то мы получим примерное кол-во атакующих ежедневно внешний периметр. Есть сомнения, что атакующих снаружи больше (статистически) чем кол-во ваших пользователей*50 (второй множитель можно увеличить без вреда для производства)?
4) Внутренний периметр гораздо больше внешнего, то есть грубо говоря — снаружи сидит один веб-сервер с файрволом, а внутри тысячи серверов открытых внутреннему периметру.
На такой случай вопросов нет, но вызывают вопросы компетентность "краеведов", у которых внутренний периметр так хорошо "простреливается".
5) Статистический период выбран специально на тот момент, когда внутри проводился аудит безопасности с использованием спецсредств.

Вне конкурса:
6) IDS настроена как попало, и срабатывает от случай к случаю (причём центром притяжения является внутренний трафик, там анализировать проще — событий меньше),
Привет "краеведам"!
7) Ваша IDS срабатывает на каждые два пинга (атака СКАН ПОРТОВ!),
Статистически абсолютно неважно.
8) IDS очень точно настроена и срабатывает только на конкретные атаки.
У вас внутри есть набор инсайдеров, которые занимаются тем, что атакуют системы используя инструменты из того набора, который распознаёт IDS — опять аудит.

Во всех случаях, статистически внешних атак должно быть больше с учётом размера периметра. Кол-во компетентных специалистов (даже с учётом scripts kiddie) внутри гораздо меньше кол-ва внешних.
Единственные факторы, которые внутри "радуют" специалистов: это меньшая защищённость и большая заинтересованность. А это уже забота специалистов по инф.безопасности. [сарказм]Чем же они заняты? Пишут отчёты о конкретных атаках и статьи о некомпетентых программистах?[/сарказм]

С Уважением, Andir!