buffer overrun и уязвимости
От: Pavel Dvorkin Россия  
Дата: 25.02.10 11:40
Оценка: :))) :)))
Как известно, одна из страшилок современного программирования — переполнение буфера, из-за чего данные записываются не туда, куда надо, а из-за этого возникают все и всяческие уязвимости. Для борьбы с этой угрозой придуманы управляемые среды и т.д.

Вообще-то мне интуитивно кажется, что при произвольном buffer overrun дело скорее всего закончится access violation с последующим крахом приложения. Но, наверное, я не прав, раз все хором говорят, что это не так. Видимо, такие случаи действительно были.

А много ли их было ?

Кто знает о документированных случаях, когда было доказано, что именно buffer overrun привел именно к уязвимости (не к краху!) — дайте информацию.

Принимаются

1. Любые ссылки на описанные в Интернете случаи.
2. Рассказы о собственных или своей команды ошибках с такими последствиями.

Не принимаются

1. Какие бы то ни было рассуждения о том, как это опасно без конкретных данных об имевшей место уязвимости.
2. Рассказы типа "мой друг говорил, что у них на работе было...".
With best regards
Pavel Dvorkin
Re: buffer overrun и уязвимости
От: Roman Odaisky Украина  
Дата: 25.02.10 11:51
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Кто знает о документированных случаях, когда было доказано, что именно buffer overrun привел именно к уязвимости (не к краху!) — дайте информацию.


Да хотя бы недавний баг nginx, CVE-2009-2629. Пошлешь хитрозапутанный GET с косыми чертами не там, где надо, и при разборе URL указатель выйдет за пределы буфера, и при нормализации данные будут записаны куда следует, и ты сможешь выполнить свой код от имени www-data.
До последнего не верил в пирамиду Лебедева.
Re: buffer overrun и уязвимости
От: WFrag США  
Дата: 25.02.10 12:19
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Вообще-то мне интуитивно кажется, что при произвольном buffer overrun дело скорее всего закончится access violation с последующим крахом приложения. Но, наверное, я не прав, раз все хором говорят, что это не так. Видимо, такие случаи действительно были.


Прочитав статью ты сможешь создавать такие случаи самостоятельно
Re[2]: buffer overrun и уязвимости
От: Pavel Dvorkin Россия  
Дата: 25.02.10 12:52
Оценка:
Здравствуйте, WFrag, Вы писали:

WF>Прочитав статью ты сможешь создавать такие случаи самостоятельно


Меня не интересует как их создавать. Я хочу составить подборку реальных случаев, когда это было.
With best regards
Pavel Dvorkin
Re[3]: buffer overrun и уязвимости
От: Mazay Россия  
Дата: 25.02.10 19:28
Оценка: 2 (1)
Здравствуйте, Pavel Dvorkin, Вы писали:

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


WF>>Прочитав статью ты сможешь создавать такие случаи самостоятельно


PD>Меня не интересует как их создавать. Я хочу составить подборку реальных случаев, когда это было.


Results 1 — 10 of about 117 from securityvulns.ru for "Buffer Overrun" execution
Главное гармония ...
Re: buffer overrun и уязвимости
От: shrecher  
Дата: 25.02.10 20:04
Оценка: +1
Здравствуйте, Pavel Dvorkin, Вы писали:


PD>1. Любые ссылки на описанные в Интернете случаи.


Conficker, CodeRed, Slammer .
Re: buffer overrun и уязвимости
От: MescalitoPeyot Украина  
Дата: 25.02.10 20:44
Оценка:
http://www.metasploit.com/
... << RSDN@Home 1.2.0 alpha 4 rev. 1138>>
Re: buffer overrun и уязвимости
От: TarasCo  
Дата: 25.02.10 22:37
Оценка:
Отчеты о уязвимостях:
http://web.nvd.nist.gov/view/vuln/search-results?cid=6

Можешь поискать сплоиты для них. Довольно часто попадается PoC. Ну и 0day также бывали.
Да пребудет с тобою сила
Re[4]: buffer overrun и уязвимости
От: Pavel Dvorkin Россия  
Дата: 26.02.10 08:59
Оценка:
Здравствуйте, Mazay, Вы писали:

M>Здравствуйте, Pavel Dvorkin, Вы писали:


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


WF>>>Прочитав статью ты сможешь создавать такие случаи самостоятельно


PD>>Меня не интересует как их создавать. Я хочу составить подборку реальных случаев, когда это было.


Похоже, либо меня понимать перестали, либо я разучился формулировать запросы. Попробую еще раз.

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

Иными словами, мне неинтересно знать, что к этому замку от завода "Суперзамок" можно подобрать ключ. Меня интересует, сколько раз ключ в действительности подбирали и в чужую кваритру входили.

Такие данные есть ?
With best regards
Pavel Dvorkin
Re[5]: buffer overrun и уязвимости
От: TarasCo  
Дата: 26.02.10 10:29
Оценка:
PD>Меня интересуют документально описанные случаи, когда эти overrun реально привели к тому, что пользователям удалось взломать сайт, программу и т.д.

Возьми гугл, поищи слово 0day а потом немного почитай соответствующие CVE. Уверяю, среди них найдется и buffer overflow. Вот собственно тебя это и интересует: уязвимость -> сплоит -> 0day.
А ты хочешь, чтоб за тебя кто то такую аналитическую работу проделал. Вот поэтому и конкретных ответов нет.
Да пребудет с тобою сила
Re[5]: buffer overrun и уязвимости
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 26.02.10 10:33
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Иными словами, мне неинтересно знать, что к этому замку от завода "Суперзамок" можно подобрать ключ. Меня интересует, сколько раз ключ в действительности подбирали и в чужую кваритру входили.


PD>Такие данные есть ?


Slammer
Re[5]: buffer overrun и уязвимости
От: IID Россия  
Дата: 26.02.10 10:42
Оценка:
Здравствуйте, 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.
kalsarikännit
Re[6]: buffer overrun и уязвимости
От: Pavel Dvorkin Россия  
Дата: 26.02.10 10:54
Оценка:
Здравствуйте, IID, Вы писали:


IID>Поверь, если есть уязвимость, подзвояющая запуск payload-а, то её юзают для пробива дрочерских машин. Пробивают десятками и сотнями тысяч в сутки. Есть даже такое понятие — % пробива на трафе. Зависит от типа трафика, который льют на эксплоит. Количество заражённых машин зависит от свежести эксплоита (как давно существует заплатка), условий пробива (конкретное сторонее ПО/базовые сервисы ОС, если ли зависимость от версии, от языка и т.д.) и может колебаться от сотен тысяч до десятков миллионов машин.



Объясню, зачем я этот вопрос задал.

Меня не интересует вообще-то, используют это и нет, и где. Меня другое интересует в действительности — каков реально нанесенный ущерб имел место именно вследствие buffer overrun ? Соразмерен ли этот ущерб тем затратам, какие тратятся на защиту ? Можно ведь и ключ с замком сделать, которые никогда не взломаешь, но если на это надо потратить в 10 раз больше, то стоит ли, особенно если учесть, что в квартире есть только старый советский телевизор и просиженный диван.

PD>>Такие данные есть ?

IID>Ищи данные по троянским эпидемиям. Из старых, заметных и чисто ремотных были, например: ms-blaster, slammer, redcode.

Вот это уж ближе к тому, что меня интересует. Спасибо.
With best regards
Pavel Dvorkin
Re[6]: buffer overrun и уязвимости
От: Pavel Dvorkin Россия  
Дата: 26.02.10 11:00
Оценка:
Здравствуйте, TarasCo, Вы писали:

TC>А ты хочешь, чтоб за тебя кто то такую аналитическую работу проделал. Вот поэтому и конкретных ответов нет.


Я просто думал, что кто-то знает реальные случаи примерно такого вида "Фирма XYZ использовала такое-то ПО. В ПО оказалась уязвимосто по указаннной причине. Сайт фирмы был взломан, в результате фирма понесла ущерб в NNN долларов".
With best regards
Pavel Dvorkin
Re[7]: buffer overrun и уязвимости
От: TarasCo  
Дата: 26.02.10 11:10
Оценка:
PD>Я просто думал, что кто-то знает реальные случаи примерно такого вида "Фирма XYZ использовала такое-то ПО. В ПО оказалась уязвимосто по указаннной причине. Сайт фирмы был взломан, в результате фирма понесла ущерб в NNN долларов".

Ну, кто будет о своих убытках заявлять? Такой информации я думаю не найдешь. Обычная ситуация — юзер зашел на сайт, открыл документ pdf, подключился к ботнету. Вот примерно так:
http://www.f-secure.com/weblog/archives/00001836.html
Да пребудет с тобою сила
Re[7]: buffer overrun и уязвимости
От: IID Россия  
Дата: 26.02.10 11:11
Оценка: +2 :)
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Объясню, зачем я этот вопрос задал.


PD>Меня не интересует вообще-то, используют это и нет, и где. Меня другое интересует в действительности — каков реально нанесенный ущерб имел место именно вследствие buffer overrun ? Соразмерен ли этот ущерб тем затратам, какие тратятся на защиту ? Можно ведь и ключ с замком сделать, которые никогда не взломаешь, но если на это надо потратить в 10 раз больше, то стоит ли, особенно если учесть, что в квартире есть только старый советский телевизор и просиженный диван.


А вот это глубоко философский вопрос. Смотря что считать ущербом. Если у тебя на машине только фейсбуки-аськи-контакты, то ты можешь годами мирно сосуществовать с семейством троянов. Они будут тихонько свои делишки делать (ддосить, спам рассылать, почтовые адреса тырить), ты свои. Если трояны будут не очень бажными — ты их и не заметишь. Считать ли это ущербом ? А вот баннеры, флеш ролики и прочее дерьмо, щедро намазанное в интернете будет тебя раздражать постоянно, и гораздо сильнее. Или, например, бумажный спам у метро и в газетном ящике. Да что уж, куча назойливой рекламы в телике, по радио, развешенной на биллбордах/общественном транспорте.

А может быть ты параноик, хранящий супер-секретные чертежи мега вундервафли. И у тебя их трояном спёрли. А может рядовой сотрудник, у которого увели базу данных служащих предприятия, с номерами кредиток. Вообщем случае, без знания конкретики, неясно, нужна ли дополнительная зашита. Особенно в свете того факта что качество современных защит катастрофически падает. Куча false-positive у антивирусов, куча дыр у проактивных защит, обход персональных фаерволлов и т.д. А качество защиты built-in в ось растёт (UAC, IE8, MSFW).
kalsarikännit
Re[8]: buffer overrun и уязвимости
От: Eugeny__ Украина  
Дата: 26.02.10 15:52
Оценка:
Здравствуйте, IID, Вы писали:


IID>А может быть ты параноик, хранящий супер-секретные чертежи мега вундервафли. И у тебя их трояном спёрли. А может рядовой сотрудник, у которого увели базу данных служащих предприятия, с номерами кредиток. Вообщем случае, без знания конкретики, неясно, нужна ли дополнительная зашита. Особенно в свете того факта что качество современных защит катастрофически падает. Куча false-positive у антивирусов, куча дыр у проактивных защит, обход персональных фаерволлов и т.д. А качество защиты built-in в ось растёт (UAC, IE8, MSFW).


Кстати, а вот кражу номера кредитки можно ли считать ущербом? Ведь злоумышленник может им никогда и не воспользоваться(кредитки обычно обчищают весьма не сразу, а после накопления значительной базы).
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Re[7]: buffer overrun и уязвимости
От: kochetkov.vladimir Россия https://kochetkov.github.io
Дата: 03.03.10 10:47
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

Жаль, пропустил такую тему...

Павел, а вот, положа руку на сердце, что тебе даст сравнение затрат на обеспечение безопасности продукта (которые ложаться на его производителя) с ущербом, обусловленным эксплуатацией некоей уязвимости в продукте (который понесут его потребители)?
... << RSDN@Home 1.2.0 alpha 4 rev. 1437>>

[Интервью] .NET Security — это просто
Автор: kochetkov.vladimir
Дата: 07.11.17
Re[8]: buffer overrun и уязвимости
От: Pavel Dvorkin Россия  
Дата: 03.03.10 11:56
Оценка:
Здравствуйте, kochetkov.vladimir, Вы писали:

KV>Павел, а вот, положа руку на сердце, что тебе даст сравнение затрат на обеспечение безопасности продукта (которые ложаться на его производителя) с ущербом, обусловленным эксплуатацией некоей уязвимости в продукте (который понесут его потребители)?


Во-первых, ты не прав. Затраты на обеспечение безопасности продукта ложатся не на производителя, а на потребителя, потому что производитель с него эти деньги возьмет — больше ему брать их неоткуда.

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

С первым более или менее ясно, а вот про второе, я думал, мне кто-то что-то расскажет. Увы, не было ничего интересного сказанно, ну я и свернул дискуссию со своей стороны.
With best regards
Pavel Dvorkin
Re[9]: buffer overrun и уязвимости
От: kochetkov.vladimir Россия https://kochetkov.github.io
Дата: 04.03.10 16:52
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Во-первых, ты не прав. Затраты на обеспечение безопасности продукта ложатся не на производителя, а на потребителя, потому что производитель с него эти деньги возьмет — больше ему брать их неоткуда.


Ну ок. Предположим, что производитель затратил на обеспечение безопасности своего продукта 10 килобаксов и добавил к розничной стоимости самого продукта 100 баксов в рассчете на то, что первые 100 пользователей обеспечат ему выход на ноль по этой статье, а остальные принесут 100 баксов чистой прибыли от инвестиций в безопасность своего продукта.

Одного из пользователей первой сотни таки-расхачили по полной программе через дырку в таком продукте и увели со счета в интернет-банке кровно заработанные за месяц 2-3 килобакса.

Какие баксы с какими следует сравнивать и почему?

PD>А во-вторых, во всех технологиях затраты на обеспечение какой бы то ни было безопасности всегда соизмеряют с ценностью того, что представляет собой защищаемый объект и реальным риском угроз,


Между прочим, об этом тебе рассказывал я, если что

PD>основанном на анализе того, что уже было и какой ущерб принесло.


А если ничего не было и ущерба не принесло? На безопасность в этом случае можно забить?

PD>С первым более или менее ясно,


Да нифига там неясно, вообще-то.

PD>а вот про второе, я думал, мне кто-то что-то расскажет. Увы, не было ничего интересного сказанно, ну я и свернул дискуссию со своей стороны.


Я-то думал, ты какую-то крамольную мысль до всех донести хочешь...
... << RSDN@Home 1.2.0 alpha 4 rev. 1437>>

[Интервью] .NET Security — это просто
Автор: kochetkov.vladimir
Дата: 07.11.17
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.