О "списках уязвимостей в программах"

lexa - 28/Май/2013 21:22

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

Читаем:

LibRaw версии до 0.15.1

LibRaw-demosaic-pack-GPL2 версии до 0.15.1

LibRaw-demosaic-pack-GPL3 версии до 0.15.1

Имею сказать:
  • Не являясь специалистом в области ИБ, не могу сказать, является ли выход за пределы массива по фиксированному(!) адресу +4GB-1 (потому что там всегда 0xffffffff в индексе) возможностью выполнения произвольного кода. Возможно. Равно как является ли проблемой такой псевдокод a = malloc(..); free(a); free(a);. Возможно.
  • Эти проблемы в LibRaw 0.15.0 - были. Возможно, они серьезные, хотя мне так не кажется. Представить, что "удаленного пользователя" допустят до кода коррекции экспозиции - не могу.
  • Вот что я знаю точно:
    • Этих ошибок нет в LibRaw-demosaic-pack-GPL3, оно тут никоим боком.
    • этих ошибок нет в "версии до 0.15.1". Они есть в 0.15.0, а ветки 0.7...0.14 - не подвержены (по причине отсутствия соответствующего кода).
    Что позволяет мне предполагать, что никакого анализа никто не делал.

    SecurityFocus пишет что дескать vendor reported. Но ни одна скотина не пыталась сконтактировать с вендором и узнать подробностей.

Я собственно к чему - что теперь читая всякие security reports буду делить минимум на десять.

Upd: я не хочу спорить с наличием ошибок (они были, программы, как минимум падали). Мой поинт в том что

  • Если вы вендор - не надо репортить проблемы подробно (double call to free), все что вы написали - будет использовано против вас. Пишите просто "исправлена ошибка в обработке битых файлов Foveon"
  • Авторы этих репортов - не анализируют что сделано на самом деле, в каких версиях была ошибка и т.п. Соответственно нужно к этим репортам относиться: наличие репорта не означает проблемы (а отсутствие - отсутствия проблемы).

Comments

Anonymous (not verified) - 28/Май/2013 22:35

free(0) и free(NULL) по стандартам C и C++ безопасно.

lexa - 28/Май/2013 22:39

Нет, нам не free(0);

Там ptr_a = ptr_b = malloc(..);
free(ptr_a); free(ptr_b);

Anonymous (not verified) - 28/Май/2013 22:53

Это на самом деле плохо, особенно с многопоточностью.
(кстати, между двумя free в одном потоке эта память может быть испорчена другими потоками)

P.S. нет гарантий, что free не портит информацию про ptr_a.

kika (not verified) - 28/Май/2013 22:30

псевдокод - является, как минимум являлся, я на эти грабли наступил разок.

lexa - 28/Май/2013 22:39

А как? Нужно чтобы в окошке кто-то что-то аллоцировал?

kika (not verified) - 29/Май/2013 00:11

ну там просто было - аллоцировался буфер, в него читалось (со всеми проверками границ). А потом двойное освобождение, которое на той версии гцц и либсей давало переход по адресу из прочитанных данных. все что надо было сделать - подобрать данные чтобы прочитать :-)
я-то на резиновые грабли наступил - хакнул сам себя, и остановился на proof of concept, но вполне удачно.

ostapru (not verified) - 28/Май/2013 22:40

Там написано:
Credit: The vendor reported this issue.

Я понимаю это, что "вендор сам зарепортил проблему и получил кредит за это".

lexa - 28/Май/2013 22:44

Вендор - я.

И вот хер я теперь буду писать нормальные описания решенных проблем в changelog.

ostapru (not verified) - 29/Май/2013 00:25

> Вендор - я.

Я в курсе ;)

> И вот хер я теперь буду писать нормальные описания решенных проблем в changelog.

Ну почему?
Реально заэксплоитить большинство таких вещей очень трудно, но иногда попадаются реальные проблемы, поэтому так и носятся с этой фигнёй.
Я бы в чейнжлоге писал "affected releases x.xx - y.yy" чтобы исключить какое-либо 2е толкование. Наверняка в чейнжлоге для 0.15.1 было написано, что пофиксено, а когда появилось - нет, вот они и вписали все релизы до фикса.
Скорее всего реально никто ничего не анализировал - просто увидели чейнжлог, увидели фикс попадающий по определённый патерн и отрепортили проблему в предыдущих релизах, чтобы народ знал и не наступал на грабли. А то, что он появилось только в 15.0 - там не было написано ;)
Но конечно обидно ;)

lexa - 29/Май/2013 10:30

Если бы репорту предшествовала хоть какая-то попытка спросить "в чем суть ошибки" и вообще вступить в обсуждение с вендором - имело бы смысл писать "правду" (в смысле - подробности), дабы такой диалог произошел.

Так как никакой попытки пообщаться я не заметил - не имею желания кормить этих людей контентом дальше.

kiryl (not verified) - 28/Май/2013 22:53

> Равно как является ли проблемой такой псевдокод a = malloc(..); free(a); free(a);

http://cwe.mitre.org/data/definitions/415.html

When a program calls free() twice with the same argument, the program's memory management data structures become corrupted. This corruption can cause the program to crash or, in some circumstances, cause two later calls to malloc() to return the same pointer. If malloc() returns the same value twice and the program later gives the attacker control over the data that is written into this doubly-allocated memory, the program becomes vulnerable to a buffer overflow attack.

lexa - 28/Май/2013 23:05

Или becomes. Или не becomes. Тут уж как пойдет....

J0hn - 29/Май/2013 00:53

a = malloc(..); free(a); free(a);

Так делать не нужно даже не потому что плохо, а потому что можно проще - RAII

SecurityFocus пишет что дескать vendor reported. Но ни одна скотина не пыталась сконтактировать с вендором и узнать подробностей.

vendor != author

Я собственно к чему - что теперь читая всякие security reports буду делить минимум на десять.

Возможно. ИМХО всё зависит от специфики - например если брать apache - reporter'ы должны относится более ответственно, то есть не всё так плохо.

lexa - 29/Май/2013 08:22

RAII - хорошая штука, да. В данном случае, конечно, имел место хак: есть два буфера (для Raw и для обработанного изображения), но чтобы старый код работал без изменений, эти два буфера в момент работы этого кода - один буфер. А в обработчике исключений освобождаются оба.

И в моем случае вендор и автор - тоже одно. Т.е. любой E-mail на вендорские контакты попадает опять ко мне.

J0hn - 29/Май/2013 11:41

И в моем случае вендор и автор - тоже одно. Т.е. любой E-mail на вендорские контакты попадает опять ко мне.

Если так, то конечно позор им!!

Хотя, например, вот тут, owner (это vendor пакета как я понимаю) некий Limb, Linux Administrator in Chicago. Но, тем не менее, адрес проекта там указан.

lexa - 29/Май/2013 11:56

Вендор библиотеки - я. За перепаковщиков отвечать не могу.

Ilirium (not verified) - 29/Май/2013 10:53

trll md 1

По сообщению авторитетных разработчиков, анализ безопасности систем на базе Linux выполняется частично и выборочно, что вызвано проблемами во взаимодействии сообщества разработчиков, аналитиков и остальных специалистов. Рекомендуется для избегания подобные проблем использовать системы, разрабатываемые компаниями с высокой корпоративной культурой. От себя добавим, что такими в 2012 году журналом F>>> были признаны...

+)

lexa - 29/Май/2013 11:08

Да, наблюдаю эти проблемы воочию - никаких попыток общения с вендором вендор в моем лице не заметил.

jabbervorx - 29/Май/2013 16:58

> По сообщению авторитетных разработчиков,

Видимо, тех самых, из высокой корпоративной культуры...

> Рекомендуется для избегания подобные проблем использовать системы, разрабатываемые компаниями с высокой корпоративной культурой

Каждый подъезд борется за звание дома высокой культуры...

Всё блин держится на людях и только. Высока была корпоративная культура в японском олимпусе...

jabbervorx - 29/Май/2013 17:09

Забавно представить как битые raw-фовеоны раздаются с записанными вирусами для пользователей библиотеки LibRaw версии 0.15.0. Высокая, говорите, опасность...

lexa - 29/Май/2013 17:14

Вообще, если представить себе сетевой сервис, который торчит наружу LibRaw - то таки да.

Но представить себе такой я не могу.

Anonymous (not verified) - 31/Май/2013 11:00

Честно говоря, от "западных источников" подобной фигни тоже не ожидал. Но и не удивлён почему-то.

Вообще-то, это универсальная и повсеместно повседневная проблема. Как там у Тютчева, "Мысль изречённая..."
Однако, если общаться с окружающими формулировками, не допускающими другого толкования, можно легко наступить на грабли, лежащие с другой стороны. Запишут в педанты и зануды.

С другой стороны, то что касается проблем работы софта, лучше всё же писать аккуратнее.
Написали бы 1 лишнее слово "касается только" версии ххх, и всё было бы хорошо.

В этом есть ведь и позитив: Вы повысили скилл написания ченджлогов. По крайней мере для собственного софта.

lexa - 31/Май/2013 13:30

Это не скилл "написания ченджлогов", это стиль "заметания под ковер". Сказать правду, но строго дозированную.

Anonymous (not verified) - 31/Май/2013 15:05

Возьмите, например, описание последней уязвимости линуксового ядра:
"... присутствует во всех ядрах, начиная с 2.6.37 и включая 3.8.8 (ядра 3.9.x проблеме не подвержены). ...".

ИМХО, Вы поленились и опустили очевидные Вам подробности, они поленились проверить и изложили Ваш репорт как поняли, наши тоже поленились и "тупо перевели".

Не далее как вчера, находясь в цейтноте, я пытался пересечься с женой, и дважды ходили в разные места. А это жена всё же, не дяди из-за бугра. :-D

lexa - 31/Май/2013 15:21

Ну у меня это первый опыт попадания в security reports.

А дальше есть два варианта действий
а) не писать что починена "страшная бага" (особенно если я ее таковой не считаю), а писать "исправлена ошибка там-то" (без конкретизации что за ошибка, чтобы всякие роботы, механические и билологические, не срабатывали на слова из описания)
б) писать именно что про buffer overrun и подобное с точным указанием версий.

С точки зрения моей головной боли, вариант "а" кажется предпочтительнее.

Anonymous (not verified) - 31/Май/2013 15:46

А кому Вы отписывались-то?

Кстати, есть и третий вариант. Делаете шаблон отписки:
"В предпоследней версии (х.х.х)появилась новая фича, которая в последней версии (y.y.y)убрана из-за невостребованности (либо "переписана на новых оптимизированных алгоритмах по просьбам трудящихся")".

))))

lexa - 31/Май/2013 15:50

Я отписывался changelog-у.