В реализации файловой системы VFAT, входящей в состав ядра Linux,
выявлена (http://www.openwall.com/lists/oss-security/2013/02/26/5) уязвимость (CVE-2013-1773), связанная с возможностью переполнения буфера при обработке определённым образом оформленных имён файлов в кодировке UTF-8. Проблема проявляется только при преобразовании символов UTF8 в UTF16, которое выполняется при монтировании раздела с опцией "utf8". Указанная опция, в частности, используется при монтировании внешних накопителей в платформе Android и в Ubuntu 10.04. Проблема проявляется для ядра Linux до версии 3.2 (многие Android-устройства подвержены уязвимости).
В настоящий момент в Сети доступен эксплоит (http://www.exploit-db.com/exploits/23248/), инициирующий перезагрузку устройств на базе платформы Android при одновременной записи нескольких файлов с именами, размер которых превышает 2048 байт. Эксплоит был разработан ещё летом 2012 года и ограничивается проведением DoS-атаки. В основном ядре Linux проблема была молча исправлена (http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git...) в ноябре 2011 года, без информирования разработчиков дистрибутивов о том, что она связана с устранением уязвимости.
После публикации информации об уязвимости родилась дискуссия (http://www.openwall.com/lists/oss-security/2013/02/26/8) о возможных путях решения сложившейся ситуации с отсутствием оценки влияния исправляемых в ядре проблем на безопасность. Сейчас разработчики ядра не делают различий в том, связано исправление с уязвимостью или только влияет на стабильность. По словам одного из членов Red Hat Security Response Team в настоящее время нереально провести полный аудит всех вносимых в ядро исправлений, их слишком много, например, среди десятков тысяч изменений трудно выявить именно те единичные случаи, которые могут привести к нарушению безопасности. В качестве одного из вариантов выхода из сложившейся ситуации было упомянуто (http://www.openwall.com/lists/oss-security/2013/02/27/3) создание отдельной группы для рецензирования всех вносимых в ядро изменений на их возможное влияние на безопасность.
Отдельно обсуждается (http://www.openwall.com/lists/oss-security/2013/02/25/14) внесённое на днях исправление (http://git.zx2c4.com/linux/commit/?id=5f00110f7273f9ff04ac69...) в ядро Linux, связанное с возможностью обращения к областям памяти после их освобождения при манипуляции с разделами TMPFS. Рассматривается, что данное исправление связано с устранением потенциальной уязвимости (CVE-2013-1767).
URL: http://www.openwall.com/lists/oss-security/2013/02/26/5
Новость: http://www.opennet.me/opennews/art.shtml?num=36238
Вот вам и линукс. Хорошо что хоть закрывают, но на Debian и CentOS заплаток фиг дождешься.
Не знаю, как у красношляпников, но у дебианщиков подобные заплатки регулярно выходят.
Количество заплаток deb-based уже зашкаливает все разумные пределы.
Кстати, начиная с самого появления UTF-8 и NLS в ядре, при монтировании FAT/VFAT
с параметром iocharset=utf8 всегда вываливается вот такое предупреждение:
FAT-fs: utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive!Но гугля же крутая, им покласть болт и на людей и на законы природы.
Заодно некрофаги получат лишний стимул прекратить уже наконец свое гнусное занятие и пользоваться таки уже свежими ядрами.
> Заодно некрофаги получат лишний стимул прекратить уже наконец свое гнусное занятие и
> пользоваться таки уже свежими ядрами.Это ты вендузятников мордой в какашки суй, и приговаривай "strcasecmp() в 21 веке юзают только ламеры"
> Вот вам и линукс.А никто и не обещал что некромансия - это просто.
>на Debian и CentOS заплаток фиг дождешьсяhttps://bugzilla.redhat.com/show_bug.cgi?id=916115
5й RHEL (и соответсвенно CentOS) не подвержен уязвимости, 6й подвержен, но исправление скоро будет.
А вот не надо относиться к Linux как $$женной Винде. Нужно всегда быть внимательным при принятии решений о использование определенной ОС или конкретного ПО в конкретном контексте. Каждый контекст имеет и уровни ответственности и уровни гарантии. И в каждом конкретном случае должна быть "четко" видна "линия" ответственности за качество и гарантии ПО. Linux ничего не гарантирует и не требует. Он живет за счет "влияний" спонсоров и волонтеров. Однако никто не гарантирует что нет дер. Просто их не ищут. То, что находят иногда публично афишируют, но чаще наоборот. Более того разбирая исходники openssh со студентами в качестве "обучающего" предмета, находили ляпы и "удивленно" восхищались.
> Вот вам и линукс.У знакомого на винде каждый день приходят тонны исправлений уязвимостей, и что? Человеческий фактор, уязвимостей не может не быть. Их может быть минимальное количество и оперативное исправление.
Причем большая часть звучит так - Эта уязвимость позволяет злоумышленнику НЕ прошедшему проверку подлинности выполнить произвольный код на машине....
Сейчас у энтузиастов нет стимула искать уязвимости в ядре. Организовали бы на базе Linux Foundation отдельный фонд для финансирования выплаты вознаграждений за поиск уязвимостей и за каждую найденную дыру выплачивали бы несколько тысяч долларов, как это делает Google для Chrome. После такого не только бы толпы людей стали внимательно изучать на предмет безопасности каждый коммит, но и сами коммитеры и разработчики ядра по другому бы взглянули на проблему (несколько тысяч долларов не для кого не лишние) и не отмахивались бы как сейчас.
Ага, вот только кому-нибудь обязательно придёт в голову по-тихому вносить хитрые уязвимости, чтобы знакомый "выявлятель уязвимостей" через некоторое время эту уязвимость "находил" и делился гешефтом.
> Ага, вот только кому-нибудь обязательно придёт в голову по-тихому вносить хитрые уязвимости,
> чтобы знакомый "выявлятель уязвимостей" через некоторое время эту уязвимость "находил"
> и делился гешефтом.На поиске уязвимостей и сейчас можно неплохо заработать, продав эксплоит черным шляпам. Но продвинуть специально уязвимость в условиях сложившейся среди разработчиков ядра цепочке доверия невероятно сложно. По крайней мере прецедентов еще не было. Проблема то том, что часто данные об уязвимости сперва попадают не в те руки, Google блестяще перетянул на себя одеяло - можно неплохо заработать без какого-либо риска.
>> Ага, вот только кому-нибудь обязательно придёт в голову по-тихому вносить хитрые уязвимости,
>> чтобы знакомый "выявлятель уязвимостей" через некоторое время эту уязвимость "находил"
>> и делился гешефтом.
> На поиске уязвимостей и сейчас можно неплохо заработать, продав эксплоит черным шляпам.
> Но продвинуть специально уязвимость в условиях сложившейся среди разработчиков ядра цепочке
> доверия невероятно сложно. По крайней мере прецедентов еще не было. Проблема
> то том, что часто данные об уязвимости сперва попадают не в
> те руки, Google блестяще перетянул на себя одеяло - можно неплохо
> заработать без какого-либо риска."В 2008м году оборот в сфере киберпреступлений превысил оборот наркобизнеса". Гуглить самостоятельно для пруфа.
Так шта, я бы сказал, у черных шляп можно заработать риальни покруче.
> Так шта, я бы сказал, у черных шляп можно заработать риальни покруче.Во первых у людей есть определённые принципы (на продаже оружия/наркотиков можно курто заработать, но ведь только отморозки до этого спускаются). Во вторых вознаграждение Google по размеру сопоставимо с тем, что можно заработать на продаже эксплоита.
Из этой новости:
" В понятие киберпреступности входят сетевой промышленный шпионаж, детская порнография, манипуляции с акциями, пиратство и кража информации"В эту сумму они всё запихнули, включая "пиратство". А там суммы "недополученной прибыли" такие рисуют, что оно могло запросто оказаться больше оборота всей планеты.
Энтузиасты здесь ну совершенно не при чем. Чтобы прыгнуть в высоту на 8 метров, надо одного прыгуна, прыгающего на 8 метров, а не 8 прыгающих на 1 метр. Опачки?
> Энтузиасты здесь ну совершенно не при чем. Чтобы прыгнуть в высоту на
> 8 метров, надо одного прыгуна, прыгающего на 8 метров, а не
> 8 прыгающих на 1 метр. Опачки?Прыгуны есть, но сейчас им не интересно прыгать или они прыгают за чужую команду. Нужен стимул. Пример с Chrome я уже приводил - толпы людей постоянно ковыряют код для поиска уязвимостей, а для некоторых поиск дыр в Chome стал постоянным заработком.
Код? Код Хрома? Где они его находят?
> Код? Код Хрома? Где они его находят?
>> Код? Код Хрома? Где они его находят?
> http://src.chromium.org/Хром != Хромиум
> Хром != ХромиумХром = Хромиум + несколько малозначительных мелочей, типа Flash в комплекте и поддержка синхронизации через сервисы Google.
Если бы детали были малозначительными, то исходный код запросто бы публиковали. 3начит - детали не малознчительны.
> Хром != Хромиум...поэтому адоб патчит свое сито сам :)
> Ещё никто дважды награду за обнаруженные ошибки не получал. Так что брехня
> "постоянный заработок" не более чем маркетинг.http://www.chromium.org/Home/chromium-security/hall-of-fame
Посчитайте, сколько, например, Сергей Глазунов, Aki Helin и miaubiz заработали.
> ПосчитайтеЭто был http://wiki.opennet.ru/MSSP -- похоже, читать, считать и думать не обучены.
PS: престарелому студенту-прыгателю: уши торчат, кирпичом зацепить может.
А давайте поощрять таких людей лицензией на Debian со скидкой!Надо только красивый артворк нарисовать, чтобы они прониклись.
> А давайте поощрять таких людей лицензией на Debian со скидкой!Это как? Доплачивать за скачку дебиана? :)
а как же любимый аргумент шигорина что ядро смотрят милионы пользователей и ищут уязвимости и в этом прелесть GPL ?
> а как же любимый аргумент шигоринаУх ты, а можно ссылочку или сразу оставим на Вашей совести?
Вот поэтому не нужно добавлять PE парсер в ядро :)
Напоминаю, если что: "в основном ядре Linux проблема была молча исправлена в ноябре 2011 года".
Что значит молча?Тише просто некуда!
The utf8s_to_utf16s conversion routine needs to be improved. Unlike
its utf16s_to_utf8s sibling, it doesn't accept arguments specifying
the maximum length of the output buffer or the endianness of its
16-bit output....
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
CC: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>После слов "it doesn't accept arguments specifying the maximum length of the output buffer"
даже ежыку понятно, что переполнение буфера можно соорудить.Более того, под якобы исправлением, может скрываться алгоритмическая дыра,
"special for CIA, FBI, NSA", особо если патчик из Гарварда за именем Alan :)Так что, если вас действительно напрягают проблемы безопасности, в Вашей конторе
должен быть отдел безопасности, в крайнем случае отдельный человек.
Ну, я больше о том говорил, что обсуждается давно (больше года назад!) исправленная дыра. Да и вторую запатчили не после рапортов о взломах, а сами нашли и прикрыли. Нечего панику разводить.
> Ну, я больше о том говорил, что обсуждается давноТам реально немерено патчей, практически из любого можно создать
подобную новость с подробным разбором полётов и рекурсивным анализом.В идеале патч должен быть не только с изменёнными строками,
но и с деревом всех затрагиваемых функций.
Речь про то что "Новая функциональность => Новые баги". Соответственно включать малополезную функциональность в ядро не нужно
>> После публикации информации об уязвимости родилась дискуссия о возможных путях решения сложившейся ситуации с отсутствием оценки влияния исправляемых в ядре проблем на безопасность. Сейчас разработчики ядра не делают различий в том, связано исправление с уязвимостью или только влияет на стабильность. По словам одного из членов Red Hat Security Response Team в настоящее время нереально провести полный аудит всех вносимых в ядро исправлений, их слишком много, например, среди десятков тысяч изменений трудно выявить именно те единичные случаи, которые могут привести к нарушению безопасности. В качестве одного из вариантов выхода из сложившейся ситуации было упомянуто создание отдельной группы для рецензирования всех вносимых в ядро изменений на их возможное влияние на безопасность.либо можно просто не slowpoke'чить со своими fork'ами и backport'ами в них, а поставлят свежее ядро в своих полу'proprie'растных поделках.
но нет, пусть этим разрабы Linux'а бесплатно позанимаются, ага.