Как известно, одна из страшилок современного программирования — переполнение буфера, из-за чего данные записываются не туда, куда надо, а из-за этого возникают все и всяческие уязвимости. Для борьбы с этой угрозой придуманы управляемые среды и т.д.
Вообще-то мне интуитивно кажется, что при произвольном buffer overrun дело скорее всего закончится access violation с последующим крахом приложения. Но, наверное, я не прав, раз все хором говорят, что это не так. Видимо, такие случаи действительно были.
А много ли их было ?
Кто знает о документированных случаях, когда было доказано, что именно buffer overrun привел именно к уязвимости (не к краху!) — дайте информацию.
Принимаются
1. Любые ссылки на описанные в Интернете случаи.
2. Рассказы о собственных или своей команды ошибках с такими последствиями.
Не принимаются
1. Какие бы то ни было рассуждения о том, как это опасно без конкретных данных об имевшей место уязвимости.
2. Рассказы типа "мой друг говорил, что у них на работе было...".
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Кто знает о документированных случаях, когда было доказано, что именно buffer overrun привел именно к уязвимости (не к краху!) — дайте информацию.
Я по-прежнему считаю, что ты пытаешься сравнить цвет теплого и твердого, но ок, вот тебе пример:
в махровом 2003, когда я еще руководил серверным отделом региона и отвечал в т.ч. за доступность всех ИТ-систем компании в регионе, в выходной раздался звонок столичного дежурного с тем, что сети нашего региона стали медленно но уверенно пропадать с радаров централизованной системы мониторинга. Я выехал в офис, попутно дернув одного из моих ребят. Прибыв на место мы наблюдали любопытную картину: хосты внутри одной подсети вполне себе были доступны, но связи между подсетями не было. Локальный мониторинг верещал о критичной загрузке межофисных каналов, критической загрузке процов серверов БД под управлением MSSQL и машрутизаторов, обслуживающих подсети с этими серверами. Собственно, лежали все подсети, если маршрутизатор, на который они были заведены, обслуживал хотя бы одну подсеть с хостом у которого на борту был MSSQL или MSDE. Т.е. у нас лежали практически все сети, включая те, в которых хостилось оборудование, обслуживающее абонентов.
Попутно выяснилось, что так повезло не только солнечному югу. Подобное наблюдалось буквально во всех филиалах компании, что означало, что услуги абонентам не предоставлялись почти во всей России. Сколько это стоит сотовому оператору в тысячах баксов в час в n-ом порядке, я думаю рассказывать не надо? О принятых нами контрмерах, попытках минимизировать убытки и о том, как мы восстанавливали работоспособность сети, я с твоего позволения рассказывать не буду, ибо речь не об этом. Виновником торжества оказался некий helkern, атакующий переполнение буфера в MSSQL. Из-за его чрезвычайно агресивной политики распространения, он нагружал роутеры до их практически полного отказа, кроме того, весьма существенно глушил каналы. В итоге, двух-трех зараженных машин хватало на то, чтобы потушить всю подсеть класса "С"... Точную цифру понесенных убытков я тебе, извини, не скажу, но смею заметить, что затраты на последовавшие вскоре после этого:
а) модернизацию сетевой инфраструктуры с целью усиления защиты технологических сетей
б) внедрение централизованного патч-менеджмента
в) организацию штатной структуры ИБ в регионах (где я в итоге и очутился)
г) внедрение централизованного мониторинга ИБ по всей стране
мы не затратили за прошедшие 7 лет столько, сколько потеряли за почти 5 часов полного простоя всей инфраструктуры и последовавшего частичного простоя ее же в течении ~17 часов, можешь мне поверить.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Объясню, зачем я этот вопрос задал.
PD>Меня не интересует вообще-то, используют это и нет, и где. Меня другое интересует в действительности — каков реально нанесенный ущерб имел место именно вследствие buffer overrun ? Соразмерен ли этот ущерб тем затратам, какие тратятся на защиту ? Можно ведь и ключ с замком сделать, которые никогда не взломаешь, но если на это надо потратить в 10 раз больше, то стоит ли, особенно если учесть, что в квартире есть только старый советский телевизор и просиженный диван.
А вот это глубоко философский вопрос. Смотря что считать ущербом. Если у тебя на машине только фейсбуки-аськи-контакты, то ты можешь годами мирно сосуществовать с семейством троянов. Они будут тихонько свои делишки делать (ддосить, спам рассылать, почтовые адреса тырить), ты свои. Если трояны будут не очень бажными — ты их и не заметишь. Считать ли это ущербом ? А вот баннеры, флеш ролики и прочее дерьмо, щедро намазанное в интернете будет тебя раздражать постоянно, и гораздо сильнее. Или, например, бумажный спам у метро и в газетном ящике. Да что уж, куча назойливой рекламы в телике, по радио, развешенной на биллбордах/общественном транспорте.
А может быть ты параноик, хранящий супер-секретные чертежи мега вундервафли. И у тебя их трояном спёрли. А может рядовой сотрудник, у которого увели базу данных служащих предприятия, с номерами кредиток. Вообщем случае, без знания конкретики, неясно, нужна ли дополнительная зашита. Особенно в свете того факта что качество современных защит катастрофически падает. Куча false-positive у антивирусов, куча дыр у проактивных защит, обход персональных фаерволлов и т.д. А качество защиты built-in в ось растёт (UAC, IE8, MSFW).
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, WFrag, Вы писали:
WF>>Прочитав статью ты сможешь создавать такие случаи самостоятельно
PD>Меня не интересует как их создавать. Я хочу составить подборку реальных случаев, когда это было.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Кто знает о документированных случаях, когда было доказано, что именно buffer overrun привел именно к уязвимости (не к краху!) — дайте информацию.
Да хотя бы недавний баг nginx, CVE-2009-2629. Пошлешь хитрозапутанный GET с косыми чертами не там, где надо, и при разборе URL указатель выйдет за пределы буфера, и при нормализации данные будут записаны куда следует, и ты сможешь выполнить свой код от имени www-data.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Вообще-то мне интуитивно кажется, что при произвольном buffer overrun дело скорее всего закончится access violation с последующим крахом приложения. Но, наверное, я не прав, раз все хором говорят, что это не так. Видимо, такие случаи действительно были.
Прочитав статью ты сможешь создавать такие случаи самостоятельно
Здравствуйте, Mazay, Вы писали:
M>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Здравствуйте, WFrag, Вы писали:
WF>>>Прочитав статью ты сможешь создавать такие случаи самостоятельно
PD>>Меня не интересует как их создавать. Я хочу составить подборку реальных случаев, когда это было.
Похоже, либо меня понимать перестали, либо я разучился формулировать запросы. Попробую еще раз.
Меня не интересуют обнаруженные ошибки типа buffer overrun и их возможный последствия. Про экплойты от MS я и сам знаю.
Меня интересуют документально описанные случаи, когда эти overrun реально привели к тому, что пользователям удалось взломать сайт, программу и т.д.
Иными словами, мне неинтересно знать, что к этому замку от завода "Суперзамок" можно подобрать ключ. Меня интересует, сколько раз ключ в действительности подбирали и в чужую кваритру входили.
PD>Меня интересуют документально описанные случаи, когда эти overrun реально привели к тому, что пользователям удалось взломать сайт, программу и т.д.
Возьми гугл, поищи слово 0day а потом немного почитай соответствующие CVE. Уверяю, среди них найдется и buffer overflow. Вот собственно тебя это и интересует: уязвимость -> сплоит -> 0day.
А ты хочешь, чтоб за тебя кто то такую аналитическую работу проделал. Вот поэтому и конкретных ответов нет.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Иными словами, мне неинтересно знать, что к этому замку от завода "Суперзамок" можно подобрать ключ. Меня интересует, сколько раз ключ в действительности подбирали и в чужую кваритру входили.
PD>Такие данные есть ?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, Mazay, Вы писали:
M>>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>Здравствуйте, WFrag, Вы писали:
WF>>>>Прочитав статью ты сможешь создавать такие случаи самостоятельно
PD>>>Меня не интересует как их создавать. Я хочу составить подборку реальных случаев, когда это было.
PD>Похоже, либо меня понимать перестали, либо я разучился формулировать запросы. Попробую еще раз.
PD>Меня не интересуют обнаруженные ошибки типа buffer overrun и их возможный последствия. Про экплойты от MS я и сам знаю. PD>Меня интересуют документально описанные случаи, когда эти overrun реально привели к тому, что пользователям удалось взломать сайт, программу и т.д.
Поверь, если есть уязвимость, подзвояющая запуск payload-а, то её юзают для пробива дрочерских машин. Пробивают десятками и сотнями тысяч в сутки. Есть даже такое понятие — % пробива на трафе. Зависит от типа трафика, который льют на эксплоит. Количество заражённых машин зависит от свежести эксплоита (как давно существует заплатка), условий пробива (конкретное сторонее ПО/базовые сервисы ОС, если ли зависимость от версии, от языка и т.д.) и может колебаться от сотен тысяч до десятков миллионов машин.
PD>Иными словами, мне неинтересно знать, что к этому замку от завода "Суперзамок" можно подобрать ключ. Меня интересует, сколько раз ключ в действительности подбирали и в чужую кваритру входили.
Миллиарды раз. В некоторые "двери" по сотне раз, разные "воры".
PD>Такие данные есть ?
Ищи данные по троянским эпидемиям. Из старых, заметных и чисто ремотных были, например: ms-blaster, slammer, redcode.
IID>Поверь, если есть уязвимость, подзвояющая запуск payload-а, то её юзают для пробива дрочерских машин. Пробивают десятками и сотнями тысяч в сутки. Есть даже такое понятие — % пробива на трафе. Зависит от типа трафика, который льют на эксплоит. Количество заражённых машин зависит от свежести эксплоита (как давно существует заплатка), условий пробива (конкретное сторонее ПО/базовые сервисы ОС, если ли зависимость от версии, от языка и т.д.) и может колебаться от сотен тысяч до десятков миллионов машин.
Объясню, зачем я этот вопрос задал.
Меня не интересует вообще-то, используют это и нет, и где. Меня другое интересует в действительности — каков реально нанесенный ущерб имел место именно вследствие buffer overrun ? Соразмерен ли этот ущерб тем затратам, какие тратятся на защиту ? Можно ведь и ключ с замком сделать, которые никогда не взломаешь, но если на это надо потратить в 10 раз больше, то стоит ли, особенно если учесть, что в квартире есть только старый советский телевизор и просиженный диван.
PD>>Такие данные есть ? IID>Ищи данные по троянским эпидемиям. Из старых, заметных и чисто ремотных были, например: ms-blaster, slammer, redcode.
Вот это уж ближе к тому, что меня интересует. Спасибо.
Здравствуйте, TarasCo, Вы писали:
TC>А ты хочешь, чтоб за тебя кто то такую аналитическую работу проделал. Вот поэтому и конкретных ответов нет.
Я просто думал, что кто-то знает реальные случаи примерно такого вида "Фирма XYZ использовала такое-то ПО. В ПО оказалась уязвимосто по указаннной причине. Сайт фирмы был взломан, в результате фирма понесла ущерб в NNN долларов".
PD>Я просто думал, что кто-то знает реальные случаи примерно такого вида "Фирма XYZ использовала такое-то ПО. В ПО оказалась уязвимосто по указаннной причине. Сайт фирмы был взломан, в результате фирма понесла ущерб в NNN долларов".
Ну, кто будет о своих убытках заявлять? Такой информации я думаю не найдешь. Обычная ситуация — юзер зашел на сайт, открыл документ pdf, подключился к ботнету. Вот примерно так: http://www.f-secure.com/weblog/archives/00001836.html
IID>А может быть ты параноик, хранящий супер-секретные чертежи мега вундервафли. И у тебя их трояном спёрли. А может рядовой сотрудник, у которого увели базу данных служащих предприятия, с номерами кредиток. Вообщем случае, без знания конкретики, неясно, нужна ли дополнительная зашита. Особенно в свете того факта что качество современных защит катастрофически падает. Куча false-positive у антивирусов, куча дыр у проактивных защит, обход персональных фаерволлов и т.д. А качество защиты built-in в ось растёт (UAC, IE8, MSFW).
Кстати, а вот кражу номера кредитки можно ли считать ущербом? Ведь злоумышленник может им никогда и не воспользоваться(кредитки обычно обчищают весьма не сразу, а после накопления значительной базы).
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Павел, а вот, положа руку на сердце, что тебе даст сравнение затрат на обеспечение безопасности продукта (которые ложаться на его производителя) с ущербом, обусловленным эксплуатацией некоей уязвимости в продукте (который понесут его потребители)?
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Павел, а вот, положа руку на сердце, что тебе даст сравнение затрат на обеспечение безопасности продукта (которые ложаться на его производителя) с ущербом, обусловленным эксплуатацией некоей уязвимости в продукте (который понесут его потребители)?
Во-первых, ты не прав. Затраты на обеспечение безопасности продукта ложатся не на производителя, а на потребителя, потому что производитель с него эти деньги возьмет — больше ему брать их неоткуда.
А во-вторых, во всех технологиях затраты на обеспечение какой бы то ни было безопасности всегда соизмеряют с ценностью того, что представляет собой защищаемый объект и реальным риском угроз, основанном на анализе того, что уже было и какой ущерб принесло.
С первым более или менее ясно, а вот про второе, я думал, мне кто-то что-то расскажет. Увы, не было ничего интересного сказанно, ну я и свернул дискуссию со своей стороны.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Во-первых, ты не прав. Затраты на обеспечение безопасности продукта ложатся не на производителя, а на потребителя, потому что производитель с него эти деньги возьмет — больше ему брать их неоткуда.
Ну ок. Предположим, что производитель затратил на обеспечение безопасности своего продукта 10 килобаксов и добавил к розничной стоимости самого продукта 100 баксов в рассчете на то, что первые 100 пользователей обеспечат ему выход на ноль по этой статье, а остальные принесут 100 баксов чистой прибыли от инвестиций в безопасность своего продукта.
Одного из пользователей первой сотни таки-расхачили по полной программе через дырку в таком продукте и увели со счета в интернет-банке кровно заработанные за месяц 2-3 килобакса.
Какие баксы с какими следует сравнивать и почему?
PD>А во-вторых, во всех технологиях затраты на обеспечение какой бы то ни было безопасности всегда соизмеряют с ценностью того, что представляет собой защищаемый объект и реальным риском угроз,
Между прочим, об этом тебе рассказывал я, если что
PD>основанном на анализе того, что уже было и какой ущерб принесло.
А если ничего не было и ущерба не принесло? На безопасность в этом случае можно забить?
PD>С первым более или менее ясно,
Да нифига там неясно, вообще-то.
PD>а вот про второе, я думал, мне кто-то что-то расскажет. Увы, не было ничего интересного сказанно, ну я и свернул дискуссию со своей стороны.
Я-то думал, ты какую-то крамольную мысль до всех донести хочешь...
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Ну ок. Предположим, что производитель затратил на обеспечение безопасности своего продукта 10 килобаксов и добавил к розничной стоимости самого продукта 100 баксов в рассчете на то, что первые 100 пользователей обеспечат ему выход на ноль по этой статье, а остальные принесут 100 баксов чистой прибыли от инвестиций в безопасность своего продукта.
Да нет, не так. Эти 10 Кбаксов (ну пусть не 10, пусть меньше) полностью слупили с пользователя. Потому что слупить их больше не с кого. Не производитель лично слупил, а все вместе — непосредственный производитель, производители платных библиотек, Микрософт, наконец. Или эти хотфиксы, о которых мне тут писали, она за счет доходов аглицкого короля делает ? За наши деньги в конечном счете.
Что же касается розничной стоимости — лукавишь . Для десктопного софта уязвимость порой фактор вообще третьестепенный (не для любого, конечно). Ну а если есть — затраты раскладываются на всех покупателей. А для сайта ? Вся сумма на одного заказчика.
KV>Одного из пользователей первой сотни таки-расхачили по полной программе через дырку в таком продукте и увели со счета в интернет-банке кровно заработанные за месяц 2-3 килобакса.
KV>Какие баксы с какими следует сравнивать и почему?
В данном случае — не знаю. Но вот тебе другой пример. Создается сайт третьего заборостроительного завода. Программируется вся защита, как оно там положено, контроль доступа... На это , естественно, тратятся деньги. Между тем a) этот сайт ломать скорее всего никто не будет по причине неуловимого Джо и b) если его сломают, то его восстановить из бэкапа — дело минут на 15. Фактически эти деньги потрачены впустую.
PD>>А во-вторых, во всех технологиях затраты на обеспечение какой бы то ни было безопасности всегда соизмеряют с ценностью того, что представляет собой защищаемый объект и реальным риском угроз,
KV>Между прочим, об этом тебе рассказывал я, если что
Я помню, но полагаю, что я и сам об этом мог догадаться
PD>>основанном на анализе того, что уже было и какой ущерб принесло.
KV>А если ничего не было и ущерба не принесло? На безопасность в этом случае можно забить?
PD>>С первым более или менее ясно,
KV>Да нифига там неясно, вообще-то.
Я имел в виду, что концептуально ясно.
PD>>а вот про второе, я думал, мне кто-то что-то расскажет. Увы, не было ничего интересного сказанно, ну я и свернул дискуссию со своей стороны.
KV>Я-то думал, ты какую-то крамольную мысль до всех донести хочешь...
Я просто хочу получить ответ на вопрос — какой РЕАЛЬНЫЙ ущерб был до сих пор нанесен кому бы то ни было и как это соизмеримо с затратами.
Здравствуйте, kochetkov.vladimir, Вы писали:
k> В связи с чем, у меня вопрос: как тебе помог этот пример и какие выводы нужно сделать в свете твоего вопроса?
Отказаться от MSSQL — по принципу искоренения причины, а не последствий. С учетом потерянного бабла, которого наверняка хватило бы и на ораклы и на юниксовых админов лет на N-цать вперед — вполне себе вложение.
Здравствуйте, Anton Batenev, Вы писали:
AB>Здравствуйте, kochetkov.vladimir, Вы писали:
k>> В связи с чем, у меня вопрос: как тебе помог этот пример и какие выводы нужно сделать в свете твоего вопроса?
AB>Отказаться от MSSQL — по принципу искоренения причины, а не последствий.
В таком разрезе — это плохой принцип. Ибо следуя ему, рано или поздно придется отказаться и от оракла, коль скоро в нем обнаружаться подобные уязвимости (а они в нем нет-нет, да и обнаруживаются, если что).
AB>С учетом потерянного бабла, которого наверняка хватило бы и на ораклы и на юниксовых админов лет на N-цать вперед — вполне себе вложение.
Да есть у нас (и были на тот момент) и оракл и юниксовые админы. Просто есть продукты, жестко привязанные к MSSQL, например, система мониторинга и управления базовыми станциями, поставляемая вендором самих станций, MSSMS, ISA + IIS (логирование), корелляция событий безопасности, практически все веб-приложения (их около полусотни снаружи и под пару сотен внутри) и т.п. Боюсь тотальный переход на никсы и оракл выльется в такую копеечку, по сравнению с которой наши потери в тот день вообще затеряются среди остальных статей
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Боюсь тотальный переход на никсы и оракл выльется в такую копеечку, по сравнению с которой наши потери в тот день вообще затеряются среди остальных статей
PD> каков реально нанесенный ущерб имел место именно вследствие buffer overrun ?
кому ущерб, а кому и прибыль :=) а вот тут еще и аврора подоспела с дырой в ie. про дыры в pdf я вообще молчу. из не buff overflow за последнее время был только баг в jit компилере as.
PD> Соразмерен ли этот ущерб тем затратам, какие тратятся на защиту ?
пока что на защиту не сильно тратяться. а вот сколько денег тратится на то, чтобы облегчить хакерам жизнь... скажите, вы действительно думате, что без жаба скриптов pdf никуда? и as там очень сильно нужен, да? а сколько бабла стоило туда все это впихать? и главное — зачем оно конечному юзеру?
PD> Можно ведь и ключ с замком сделать, которые никогда не взломаешь, но если на это надо потратить в 10 раз больше,
да элементарно все защищается. просто никому нафиг это не нужно.
PD> то стоит ли, особенно если учесть, что в квартире есть только старый советский телевизор и просиженный диван.
понимаете, если делать все по уму, то взломать это будет трудно и без капитальных вложений. но это же не клево, если без вложений.
PD>>>Такие данные есть ? IID>>Ищи данные по троянским эпидемиям. Из старых, заметных и чисто ремотных были, например: ms-blaster, slammer, redcode.
PD>Вот это уж ближе к тому, что меня интересует. Спасибо.
аврора свежее будет. кстати, правильно codered, а не redcode (а почему червя морриса не назвали? если уж брать древние эпидемии... и тут надо различать троянов и червей. аврора — троян. а выше — тройка червей)
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Здравствуйте, Pavel Dvorkin, Вы писали: PD>Кто знает о документированных случаях, когда было доказано, что именно buffer overrun привел именно к уязвимости (не к краху!) — дайте информацию.
PD>Принимаются
PD>1. Любые ссылки на описанные в Интернете случаи.
Luck in life always exists in the form of an abstract class that cannot be instantiated directly and needs to be inherited by hard work and dedication.
KV>Я по-прежнему считаю, что ты пытаешься сравнить цвет теплого и твердого, но ок, вот тебе пример:
<skipped>
Вообще-то про подобное и я и ты слышали намного раньше — см. вирус Морриса.
KV>В связи с чем, у меня вопрос: как тебе помог этот пример и какие выводы нужно сделать в свете твоего вопроса?
Никак не помог. То, что в определенных случаях ущерб может быть очень большим, не означает, что защиту надо планировать на максимум для любого случая. Меня же интересует иной вопрос — какой ущерб нанесен отрасли в целом. Тот факт. что в отдельных случаях он может быть очень большим, не имеет особого значения, если эти случаи достаточно редки. Если вероятность такого события 0.00001%, то от него вполне можно застраховаться при необходимости в страховой фирме. Они (страховые фирмы) и большие риски страхуют — например, гибель супертанкера по масштабам абсолютно несравнима с твоей проблемой.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD> То, что в определенных случаях ущерб может быть очень большим, не означает, что защиту надо планировать на максимум для любого случая. PD> Если вероятность такого события 0.00001%, то от него вполне можно застраховаться при необходимости в страховой фирме.
страховаться -- это правильно. и на синхронизацию не заморачиваться. упадет -- ну так оно же все равно застраховано.
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
