В библиотеке libXfont, входящей в состав X.Org и используемой в X-сервере, обнаружена (http://lists.x.org/archives/xorg-announce/2014-January/00238...) опасная уязвимость (CVE-2013-6462), позволяющая организовать выполнение кода при обработке специально оформленного файла со шрифтом в формате BDF. Проблема была выявлена при проверке кода X.Org в статическом анализаторе cppcheck (http://cppcheck.sourceforge.net/) и связана с возможностью выхода за пределы выделенного буфера при наличии в BDF строк большого размера.
Проблему усугубляет то, что библиотека libXfont используется во всех вариантах X-серверов, в том числе том, что выполняется с правами пользователя root, что позволяет использовать данную уязвимость для повышения локальным пользователем своих привилегий в системе. Примечательно, что уязвимость появилась в кодовой базе ещё в мае 1991 года. Проблема исправлена (http://cgit.freedesktop.org/xorg/lib/libXfont/commit/?id=4d0...) в опубликованном (http://lists.x.org/archives/xorg-announce/2014-January/00238...) сегодня выпуске libXfont 1.4.7.URL: http://lists.x.org/archives/xorg-announce/2014-January/00238...
Новость: https://www.opennet.ru/opennews/art.shtml?num=38809
Ха. АНБ? :)// Капитанствую насчёт того, что в любом софте вполне могут быть уязвимости, в т.ч. сознательно внедренные, остающиеся незамеченными десятки лет. //
всё может быть, но сумлеваюсь. гораздо проще и надёжнее встраивать недокументированные возможности в железо.
не только в железо, ещё в операционные системы с закрытым кодом.
ну это хоть как. особенно, если обфускацией все тёмные делишки прикрыть. хотя, фанатичные закрытофилы об этом любят помалкивать
>фанатичные закрытофилыНе бывает таких. Бывают те, кро зарабатывают на закрытом и боятся угрозы...
ой ли!
> ой ли!Ой. Представляешь, есть много на свете, что тебе тоже трудно представить.
камменты к этой новости почитайте, благо - далеко ходить не надо, и соизвольте увидеть тех самых закрытофилов. сами в open source не участвуют, но зато неистово осуждают, да. одного из этих пришибков уже несколько раз здесь банили за неприкрытую ложь в стиле "get the facts".
p.s. если благородный Дон не является фанатом пропиретарщины, то это не значит, что оных нет.
Как показала практика, продукты с открытым исходным кодом тоже весьма надёжны для всяких закладок. Надо просто умело делать вид, что уязвимость незаметна.Это надо же: со времён Союза живёт. Уже и архитектуры процессоров сменились, и перефирия мощнее компов той давности, а уязвимость только сейчас отловили.
Это в тему "открытый софт = безопасный софт".Короче, следи за собой, будь осторожен, товарищ!
Безопасного софта не существует, как и безбажного. Но качество у открытого на порядок лучше. Тоже покапитанствую сегодня...
Это какое качество, то что у гимпа против фотошопа? Или опенофиса против мелкософтового? Или может открытые драйвера к видяхам круче блобов?
А, нет, я знаю - у блендера против макса! :)Ох уж мне эти капитаны...
> Как показала практикаЭто аргумент из твоей новой методички, табуретка?
> Как показала практика, продукты с открытым исходным кодом тоже весьма надёжны для
> всяких закладок. Надо просто умело делать вид, что уязвимость незаметна.
> Это надо же: со времён Союза живёт. Уже и архитектуры процессоров сменились,
> и перефирия мощнее компов той давности, а уязвимость только сейчас отловили.Примеры приведи, "перефир" ты наш просвещенный. Или заткнись.
Просто этой части кода никто не касался, и BDF не пользовался.
Xorg - зато с сетевой прозрачностью!
это скорее о мифах open source..
каких?
Миф?
Вы можете проприетарный продукт через cppcheck прогнать?
> Вы можете проприетарный продукт через cppcheck прогнать?Он может только просто - прогнать, как и все опеннетовские MS-табуретки
В закрытом продукте вы бы:
а) вообще бы не узнали о такой уязвимости никогда
б) не сможете прогнать его ч/з cppcheck.
1) ее там бы нашли раньше
2) есть много других статических анализаторов - качеством получше cppcheck.
И откуда ты знаешь, что программа которой ты пользуешься так проверена. Вот Windows 7 или 8 твою так кто-нибудь проверял, у тебя пруфлинк на это есть?
> в нормальных конторах - запуск статических анализаторов это не случайность как в xorg, а рутинный процесс - который выполняется раз в неделю.Ты в скольки "нормальных конторах" работал, чтобы делать такие выводы обо всех?
Не смеши людей. Собирается, работает - вот и ладненько. А статические анализаторы и прочая хрень - это никому премию не увеличит. В проприетарщине люди работают не ради качества, а ради зарплаты.
И чем другие анализаторы в вашем случаи помогут вам анализировать бинарную программу ?
> И чем другие анализаторы в вашем случаи помогут вам анализировать бинарную программу
> ?стоит заглянуть на сайт коверти и посмотреть кто у них покупает лицензии. Видимо они все анализируют свой бинарный блоб..
Разовью подтухшую дискуссию. Если разраб знает о уязвимости, а остальные нет, то это бэкдор. Оставить или закрыть - дело его доброй воли. Если известные всем дыры в жабе и оффтопике не закрываются месяцами, а то и годами, значит это кому-нибудь нужно, кому-нибудь, кто знал о дырах заранее и согласование закрытия дыр с этим кем-нибудь суть долгая бюрократическая процедура.
С другой стороны, никто не мешает тебе, рандомному Васе Пупкину, воспользоваться платным проприерастным анализатором кода для поиска дыр в опенсорсном проекте. Фил зе дифференс.
> Если разраб знает о уязвимости, а остальные нет, то это бэкдор.чёрт, тогда программы просто переполнены бэкдорами! особенно когда программист обнаружил ошибку, знает о ней, записал в TODO, но сразу не починил по каким-либо причинам.
сильное заявление, короче.
Тут согласен, но начал не я.
> 1) ее там бы нашли раньшеЕе бы не нашли, а рассказали о ней нужным людям, а не писали на opennet.
> 1) ее там бы нашли раньшеOh yea, вспоминается дырка с использованием *.ani файлов.
Уязвимы были все системы, с Windows NT по Windows Vista.
http://www.phreedom.org/research/vulnerabilities/ani-header/> 2) есть много других статических анализаторов - качеством получше cppcheck.
Ну с этим никто не спорит.
Они, по факту, есть :)
> 1) ее там бы нашли раньше
> 2) есть много других статических анализаторов - качеством получше cppcheck.Даладна... Тебе напомнить "историю успеха" заплаток Майкрософта? И какими "веселыми" историями из реальной жизни все это сопровождалось? Ага, проверяют они там, анализируют в поте лица, щаз. Расскажи еще чего-нибудь.
Угумс. Дыра в RPC (DCOM RPC) от обнаружения возможности DoS до заплатки - более 14 месяцев. В ответ на письма (сначала нормальные, потом - гневные, ибо студенты накропали массовый DoS'ер) мотивируют тем, что это только DoS, без эксплуатации - типа, закрывайте файрволом. Активный эксплоит - MS Blast (Blaster) - появился где-то месяце на 5-6... мсявным плевать, пока не перешло в эпидемию.С дырой в LSASS почти то же самое. От обнаружения до заплатки - 5 месяцев, Sasser появляется на 3-м, и портит очень много крови.
А дальше через полтора года появляется семейство Pushdo/Cutwail, которое замечательно эксплоитит оба этих бага, и еще один новый в LSASS... ВНЕЗАПНО огромное количество систем всё еще уязвимо.
>В закрытом продукте вы бы:
>а) вообще бы не узнали о такой уязвимости никогдаМожет или не может - трудно сказать. Я тоже могу так сказать: может там ещё более древняя и опасная уязвимость есть, и всплывёт лет через сорок. Обратного доказать у вас не выдет, как и у меня.
> это скорее о мифах open source..Если посмотреть на реалии а не мифы, то на открытом проекте я могу прогнать cppcheck, а на закрытом - фига. В результате есть причина полагать что в целом качество открытого кода имеет тенденцию быть выше. К тому же хреновый код просто стыдно выкладывать бывает, знаете ли.
>> это скорее о мифах open source..
> Если посмотреть на реалии а не мифы, то на открытом проекте я
> могу прогнать cppcheck, а на закрытом - фига. В результате есть
> причина полагать что в целом качество открытого кода имеет тенденцию быть
> выше. К тому же хреновый код просто стыдно выкладывать бывает, знаете
> ли.и шиндошс тому пример!!!)))
это лишь говорит о том, что у мс нет стыда и совести :-P
> это лишь говорит о том, что у мс нет стыда и совести
> :-Pбабло порождает зло!
заберите все бабло у мс и отдайте его гуглу и зло возродится там!
>> это лишь говорит о том, что у мс нет стыда и совести
>> :-P
> бабло порождает зло!
> заберите все бабло у мс и отдайте его гуглу и зло возродится
> там!жадность порождает зло :)
> и шиндошс тому пример!!!)))Кстати, да. Одна из уязвимостей в Windows (проявлялась при загрузке wmf) была обнаружена после утечки кода.
> была обнаружена после утечки кода.была *обнародована* после утечки кода.
> В результате есть причина полагать что в целом качество открытого кода имеет тенденцию быть выше.Это называется средняя температура по больнице - то есть любой содержит 2% багов.
никто и не говорил за всех, если тебя не упомянули в списке людей которым стыдно показывать корявый код, то это не повод искать виноватых
>> это скорее о мифах open source..
> Если посмотреть на реалии а не мифы, то на открытом проекте я
> могу прогнать cppcheck, а на закрытом - фига. В результате есть
> причина полагать что в целом качество открытого кода имеет тенденцию быть
> выше.Если код открыт, то его проще использовать для всяких там нелицеприятных вещей. Попробуйте тоже самое сделать с кодом закрытым - затрат времени много больше. Авторы нуво блестящий пример - как не стараются реинженерить код нвидии, получается только .. :-)
> Авторы нуво блестящий примерНуво отличнейший драйвер. Уже года 4 на нем, полет нормальный. Стим ос выйдет, тогда можно будет и о 3D задуматься...
> Если код открыт, то его проще использовать для всяких там нелицеприятных вещей.
> Попробуйте тоже самое сделать с кодом закрытым - затрат времени много больше.Нужно рассказать это авторам миллионов вирусов для виндовз. А то мужики-то не знают, пишут себе и пишут...
> Xorg - зато с сетевой прозрачностью!чтоб дыры были сразу remote
>> Xorg - зато с сетевой прозрачностью!
> чтоб дыры были сразу remotessh -Y user@host 'firefox'
дыры ремотные, а вот ключик на ssh таки придётся искать, такие дела, да.
Дайте удобные инструменты воспользоваться этой уязвимостью? а?
Скрипткиддисам - только за $$$$, извините
> Дайте удобные инструменты воспользоваться этой уязвимостью? а?apt-get install gcc xorg-dev
Надо бы ещё и шрифты в репозиториях проверить - а вдруг кто-то уже давно построил ботнет на Linux-десктопах ;)
> libXfontкто-то этим ещё пользуется? Все давно же закопали исковые шрифты.
>> libXfont
> кто-то этим ещё пользуется? Все давно же закопали исковые шрифты.Ну я. Правда, там, где пользуюсь -- и так рутшелл на tty[2-4] болтается.
>> libXfont
> кто-то этим ещё пользуется? Все давно же закопали исковые шрифты.Нукась, покаж непорезанный вывод
# lsof | grep libXfont
$ lsof | grep libXfont
$
видимо никто.
Пичалька"... библиотека libXfont используется во всех вариантах X-серверов, в том числе том, что выполняется с правами пользователя root ..."
От рута пускай lsof
действительно ошибочка
sudo lsof | grep -i libXfont
X 1711 root mem REG 253,4 221776 1183667 /usr/lib/libXfont.so.1.4.1
В этом-то вся фигня. Грузилось бы не от рута, была бы не уязвимость, а просто баг.
> кто-то этим ещё пользуется? Все давно же закопали исковые шрифты.Я ими пользуюсь. У них есть, как минимум, 2 киллер-фичи:
1. Независимость от костыля под названием "хинтинг"
2. Хорошие гарнитуры "adobe-helvetica" и "misc-fixed" почти "искаропки"
>> кто-то этим ещё пользуется? Все давно же закопали исковые шрифты.
> Я ими пользуюсь. У них есть, как минимум, 2 киллер-фичи:
> 1. Независимость от костыля под названием "хинтинг"Независимость от хорошего отображения идет в комплекте :-)
> Независимость от хорошего отображения идет в комплекте :-)Гыыыыыыы. Сразу чувствуется человек ничего не видевший кроме размытых федор и убунт, косящих под макось.
Могу посоветовать сделать следующее:
1. Попросить Шигорина отсыпать чуток Альту. В нем в битовые шрифты, по крайней мере раньше, были включены кириллические глифы для стандартных x-шрифтов, когда-то готовившиеся Болховитяновым для включения в на тот момент еще XFree, но так и не попавшие туда.
2. Левак под названием xorg-fonts-cyrillic категорически не ставить ни в коем случае
3. Настроить X-ы проглотить шрифты из п.1
4. Настроить gtk и qt на стандартные X-овые битовые Adobe Helvetica 12 pt в качестве пропорционального и misc-fixed в качестве моноширинного.
5. Позапускать различный софт, тихо прифигеть и понять что за последние 25 лет прогресса в шрифтах для пользовательских интерфейсов не наблюдалось.P.S. Размытые символы в интерфейсах пользовательских программ я считаю шагом в сторону, а зависимость изображения глифа от фазы луны, что получается от применения хинтинга в векторных шрифтах - вообще багом.
Ностальгия по вшитым в ПЗУ шрифтам тоже идет в комплекте? :-)
Не надо считать шрифтовиков за идиотов - люди десятилетиями стараются сделать их лучше, чем битовая хренотень.
Helvetica хороший шрифт, но уже давно есть и получше
> Ностальгия по вшитым в ПЗУ шрифтам тоже идет в комплекте? :-)Не идет. Есть, как минимум 4 фатальных недостатка, на примере VGA:
1. Только моноширинные с фиксированной шириной 9px
2. Только 3 размера в высоту, притом не самых удобных.
3. Только однобайтовые кодировки.
4. В массе своей сделаны людьми далекими от проектирования шрифтов> Не надо считать шрифтовиков за идиотов - люди десятилетиями стараются сделать их
> лучше, чем битовая хренотень.Я уже 2 раза написал область применения битовых шрифтов и почему они там лучше векторных. 3-й раз не буду, все-равно не дойдет.
> Helvetica хороший шрифт, но уже давно есть и получше
Абсолютно голословное утверждение. Для начала советую составить критерии для отбора шрифта для UI и потом уже выяснить какой-же лучше. Для затравки рекомендую подумать, почему всегда используются не оптимизированные для чтения шрифты, т.е. с засечками, а гротески. Ответ на этот вопрос и скажет, почему все шрифты для UI будут клонами Helvetica, а с уменьшением размеров символов будут от нее вообще неотличимы. Задача вписывания символа латиницы в знакоместо при ограничениях на количество пикселей и читаемость текста уже решена оптимально несколько десятков лет тому назад и, как показывает история, новых сильно отличающихся решений не предвидится.
Я согласен только с одним - когда яббло изобретет мониторы SuperHertina c разрешением 20000*10000, то битовые шрифты будут иметь преимущества, но сейчас нет, и именно из-за недостатки техники, а вовсе не потому что они изначально корявые. Все эти методы улучшения придуманы только из-за недостатков техники, а не из-за недостатков самих шрифтов, но эти улучшалки бесполезно применять к битовым шрифтам и другой техники сейчас нет.
> Я согласен только с одним - когда [...] то битовые шрифты будут иметь преимущества12x22 прекрасно смотрится на нынешних дисплеях достаточно высокого разрешения в качестве консольного шрифта, если что. Это ещё сановские.
>> Я согласен только с одним - когда [...] то битовые шрифты будут иметь преимущества
> 12x22 прекрасно смотрится на нынешних дисплеях достаточно высокого разрешения в качестве
> консольного шрифта, если что. Это ещё сановские.Консольного шрифта в голой консоли имеется ввиду? Может быть, откровенного говоря, я ее наблюдаю только при загрузке или когда запускаю сборку чего-то большого в другой консоли. Вполне возможно, что битовые шрифты будут иметь свои преимущества на еще не созданных мониторах супервысокого разрешения. Но это будут уже совсем другие битовые шрифты.
> Консольного шрифта в голой консоли имеется ввиду?Виноват, это было легче понять именно так. Подразумевал "шрифта, используемого в графическом эмуляторе терминала".
>> Я согласен только с одним - когда [...] то битовые шрифты будут иметь преимущества
> 12x22 прекрасно смотрится на нынешних дисплеях достаточно высокого разрешения в качестве
> консольного шрифта, если что. Это ещё сановские.О, так для таких как мы есть "fbcon=font:SUN12x22" в параметрах ядра. Для ядер (знаешь для каких) это изначально возможно было.
> 1. Попросить Шигорина отсыпать чуток Альту.Совершенно излишне, можно взять и самому. :)
> В нем в битовые шрифты, по крайней мере раньше, были включены кириллические глифы
> для стандартных x-шрифтов, когда-то готовившиеся Болховитяновым для включения
> в на тот момент еще XFree, но так и не попавшие туда.http://packages.altlinux.org/ru/search?query=fonts-bitmap-cy...
> 3. Настроить X-ы проглотить шрифты из п.1
В альте сами. Странно, почему-то не вижу rfx в дебиане.
> P.S. Размытые символы в интерфейсах пользовательских программ я считаю шагом в сторону
На эту тему знаю, что у разных людей глаза разные...
>> 1. Попросить Шигорина отсыпать чуток Альту.
> Совершенно излишне, можно взять и самому. :)Утянул fonts-bitmap-cyr_rfx-iso10646-0400
:-)
Классный в пакете список майнтейнеров..Список всех майнтейнеров, принимавших участие
в данной и/или предыдущих сборках пакета:ALT QA Team Robot
Alexey Dyachenko
Игорь Власенко:-)
> http://packages.altlinux.org/ru/search?query=fonts-bitmap-cy...Михаил, Вы поражаете :-) Это называется "Угадал все буквы но не смог прочитать слово".
Конечно я имел ввиду шрифты cyr_rfx, но не в виде в котором их выложил автор, т.е. набора кириллических символов для iso10646-0400. В таком виде они присутствуют во многих дистрибутивах. Подразумевались то, что в альте их интегрировали непосредственно в стандартные x-овые шрифты, как это должно было бы случится в случае несостоявшегося вливания в XFree. Смотри набор патчей к http://packages.altlinux.org/ru/Sisyphus/srpms/fonts-bitmap-... . А вот этого уже в других дистрибутивах, насколько я знаю, нету :-)
Чтобы не быть голословным, сделал скриншот с только битовыми шрифтами. На скриншоте wireshark (gtk2), virtualbox (qt4), urxvt (pure xlib). В фоне, правда, firefox с MS-овскими ttf-ами, но это я изменить не могу. 99,9% веба верстается именно под них.
в первый раз за долгое время вижу нормальные шрифты на скриншотах! а то я думал, у всех уже сопли мозг съели.
> Это называется "Угадал все буквы но не смог прочитать слово".Так было удобнее сослаться на всю группу сразу :-)
> Подразумевались то, что в альте их интегрировали непосредственно в стандартные x-овые
> шрифты, как это должно было бы случится в случае несостоявшегося вливания в XFree.А вот этого не знал, спасибо. Может, добавите своей рукой к страничке http://www.altlinux.org/Features?
> Может, добавите своей рукой к страничке http://www.altlinux.org/Features?Оставляю эту честь Вам. Мне сначала надо проверить что эти патчи не только присутствуют, но и последовательно накладываются->компилируются->устанавливаются->регистрируются в xorg.conf->регистрируются в fontconfig.conf->отображаются. А желание устанавливать ALT только ради этого - отсутствует. 10 лет назад все было ОК, как сейчас - не знаю.
Вообще, если хочется узнать больше о происхождении этого "привета от BlackCat-а" можно почитать гномовский мэйллист https://mail.gnome.org/archives/gnome-cyr/2002-January/msg00...
>> Может, добавите своей рукой к страничке http://www.altlinux.org/Features?Добрался, добавил; спасибо!
> Мне сначала надо проверить что эти патчи не только присутствуют, но и последовательно
> накладываются->компилируются->устанавливаются->
> регистрируются в xorg.conf->регистрируются в fontconfig.confЭто видно и по пакету:
http://packages.altlinux.org/en/Sisyphus/srpms/fonts-bitmap-...
http://packages.altlinux.org/en/Sisyphus/srpms/fonts-bitmap-...> ->отображаются.
Факт. :)
> А желание устанавливать ALT только ради этого - отсутствует.
Если что, то альт "на посмотреть" можно быстро взять по ссылкам с http://altlinux.org/regular и засунуть в виртуалку; на этих LiveCD работает и apt-get.
> https://mail.gnome.org/archives/gnome-cyr/2002-January/msg00...
(KOI8-R) М-ндя, узнаю Лёню.
> Все давно же закопали исковые шрифты.отучаемся говорить за всю сеть.
- бат вай?
- бат хау?// английский юмор
в смысле, а как этим пользоваться? иксовые шрифты ставятся один раз, и на всю жизнь.
> в смысле, а как этим пользоваться? иксовые шрифты ставятся один раз,А иксовый клиент свои шрифты подпихнуть может?
man xset
Debian. Обновления пришли незадолго до прочтения этой новости.
убунту. обновления шрифтов также недавно пришли
> Debian. Обновления пришли незадолго до прочтения этой новости.http://packages.altlinux.org/ru/Sisyphus/srpms/libXfont/chan... :)
>> незадолго до прочтения этой новости."Опасная уязвимость в X.Org, присутствующая с 1991 года" +/–
Сообщение от opennews (ok) on 08-Янв-14, 11:16(tz по всей видимости MSK)
>packages.altlinux.org/ru/Sisyphus/srpms/libXfont/changelog :)
Миша, а почему там (на странице) нет _времени_, а только дата? Если уж *наперегонки*, то и время с секундной скоростью, и тайм-зону. И не время чендж-лога, а время аплоада?
>>packages.altlinux.org/ru/Sisyphus/srpms/libXfont/changelog :)
> Миша, а почему там (на странице) нет _времени_, а только дата?Потому что таков формат rpm %changelog.
> Если уж *наперегонки*, то и время с секундной скоростью, и тайм-зону.
Наперегонки -- это к Шумахеру.
PS: в смысле это было "me too". :)
> И не время чендж-лога, а время аплоада?
http://git.altlinux.org/tasks/archive/done/_108/111475/logs/... (UTC)
https://bugzilla.altlinux.org/show_bug.cgi?id=19202
> Наперегонки -- это к Шумахеру.Нехорошо так говорить.
угу. Только это нестабильная ветка, а в стабильной
Built: almost 2 years ago
http://packages.altlinux.org/en/p7/srpms/libXfont
в то время как в дебиан уже давно бэкпортировали исправление.
> угу. Только это нестабильная ветка, а в стабильной
> Built: almost 2 years agoУгу -- завтра cas@ проверит и отправит, думаю. Соответственно в репозитории послезавтра.
он один проверяет?
> он один проверяет?Перед пропуском в стабильный бранч -- скорее да.
> Debian. Обновления пришли незадолго до прочтения этой новости.мы все с нетерпением ждали, пока ты нам это расскажешь.
Они первый раз что-ли cppcheck запустили?
Ну да а че
дауж это самое забавное
Подтверждаю. Есть такое обновление: http://www.freshports.org/x11-fonts/libXfont/
> Подтверждаю. Есть такое обновление: http://www.freshports.org/x11-fonts/libXfont/Не-не-не, дэвид блейн. Твоим палёным портам мы верим ещё меньше, чем lists.x.org и git.fd.o. От тебя - ни коммита, ни ссылки! А то потом паники ядра начнём запретом версий джаввы "лечить". >/<
libxfont (1:1.4.7-1) unstable; urgency=high* New upstream release
+ CVE-2013-6462: unlimited sscanf overflows stack buffer in
bdfReadCharacters()
* Don't put dbg symbols from the udeb in the dbg package.
* dev package is no longer Multi-Arch: same (closes: #720026).
* Disable support for connecting to a font server. That code is horrible and
full of holes.
-- Julien Cristau <jcristau@debian.org> Tue, 07 Jan 2014 17:51:29 +0100
> libxfont (1:1.4.7-1) unstable; urgency=high
> * New upstream release
> + CVE-2013-6462: unlimited sscanf overflows stack buffer in
> bdfReadCharacters()
> * Don't put dbg symbols from the udeb in the dbg package.
> * dev package is no longer Multi-Arch: same (closes: #720026).
> * Disable support for connecting to a font server. That code is horrible and
> full of holes.А вот и время [чендж-лога] до секунды с тайм-зоной!
+libxfont (1:1.4.7-1) unstable;
+ -- Julien Cristau <jcristau@debian.org> Tue, 07 Jan 2014 17:51:29 +010020:51:29 по MSK
---- Желающие посоресноваться могут заглянуть сюда:
https://security-tracker.debian.org/tracker/CVE-2013-6462В забеге участвуют версии squeeze =oldstable (security) и wheezy =stable (security) от 26 декабря.
+libxfont (1:1.4.1-4) squeeze-security; urgency=high
+ * unlimited sscanf can overflow stack buffer in bdfReadCharacters()
+ -- Julien Cristau <jcristau@debian.org> Thu, 26 Dec 2013 21:36:57 +0100+libxfont (1:1.4.5-3) wheezy-security; urgency=high
+ * unlimited sscanf can overflow stack buffer in bdfReadCharacters()
+ -- Julien Cristau <jcristau@debian.org> Thu, 26 Dec 2013 21:54:48 +0100
author Alan Coopersmith <alan.coopersmith@oracle.com> 2013-12-24 02:34:02 (GMT)
committer Alan Coopersmith <alan.coopersmith@oracle.com> 2013-12-31 02:09:45 (GMT)Дебиановский патч ссылается аж на 17ое сентября
+From b07483b605e77ea475b97d5dc829a7d5eb10a5d6 Mon Sep 17 00:00:00 2001
+From: Alan Coopersmith <alan.coopersmith@oracle.com>
+Date: Mon, 23 Dec 2013 18:34:02 -0800
$ find /usr/share/fonts -name \*.[bB][dD][fF]
$Опа, опа, ганг-гам-стайл...
>Как жить, Митрофаныч?!проспись, завтра на работу.
>>Как жить, Митрофаныч?!
> проспись, завтра на работу./tmp/libXfont-1.4.7/src > make
...CC dirfile.lo
dirfile.c: In function 'FontFileReadDirectory':
dirfile.c:117:2: warning: format not a string literal, argument types not checked [-Wformat-nonliteral]
113 if (format[0] == '\0')
114 sprintf(format, "%%%ds %%%d[^\n]\n",
115 MAXFONTFILENAMELEN-1, MAXFONTNAMELEN-1);
116
117 while ((count = fscanf(file, format, file_name, font_name)) != EOF) {Чо, ещо одна бага?!! :D
Шлангу тоже не понравилось
dirfile.c:117:31: warning: format string is not a string literal [-Wformat-nonliteral]
while ((count = fscanf(file, format, file_name, font_name)) != EOF) {
^~~~~~
CC ftenc.lo
ftenc.c:90:33: warning: variable 'reg' is uninitialized when used here [-Wuninitialized]
if(strlen(enc) + strlen(reg) > 18)
^~~
ftenc.c:71:26: note: initialize the variable 'reg' to silence this warning
const char *enc, *reg;
^
= NULL
ftenc.c:90:19: warning: variable 'enc' is uninitialized when used here [-Wuninitialized]
if(strlen(enc) + strlen(reg) > 18)
^~~
ftenc.c:71:20: note: initialize the variable 'enc' to silence this warning
const char *enc, *reg;
^
= NULL
2 warnings generated.
CC pcfread.lo
pcfread.c:490:21: warning: comparison of unsigned expression < 0 is always false [-Wtautological-compare]
if (bitmapSizes[i] < 0) goto Bail;
~~~~~~~~~~~~~~ ^ ~
1 warning generated.
С ужасом думаю, что же обнаружится, если прогнать через PVS. :-)
Ты что, pvs же проприетарщина! Только открытый софт.
> Ты что, pvs же проприетарщина! Только открытый софт.PVS просто дико неудобна для проверки X'ов. Именно из-за того, что код PVS закрыт.
В общем, я сделал по злому :)$ ./configure --disable-bdfformat --prefix=/usr --libdir=/usr/lib64; make; make install;
Ну а чё, ни одного BDF шрифта не нашёл, накой хрен оно нужно.
> $ ./configure --disable-bdfformat --prefix=/usr --libdir=/usr/lib64; make; make install;Это че? На зло маме отморо^W^W^W поставил LFS?
Ну а фигли, к тому же оптимизация под мой проц.
в гентах если что тоже обновили ;D зачем же лфсничать
мяу
Зато ещё 4 варнинга закрыл (см. выше)
Мда, проблемка-то старше меня и подовляющего большинства остальных анонимусов здеся.
1. Многочисленные уязвимости безопасности в ядре Linux
http://securityvulns.ru/news/Linux/kernel/1401.html
Опубликовано: 8 января 2014 г.
Источник: BUGTRAQ
Тип: библиотека
Опасность: 9
Описание: Утечка информации в ptrace, повышение привилегий через функции
отладки, слабый PRNG генератор в cprng, DoS в сетевом
функционале, многочисленные целочисленные переполнения,
переполнения буфера в драйверах USB, WiMax и других
устройств, кратковременные условия в реализации shared
memory, неиницилизированная память в UDP fragmentation
offload.
Продукты: LINUX: kernel 2.6
LINUX: kernel 3.11
LINUX: kernel 3.12
Многочисленные высеры MS-табуретки, вызванные хроническим батхэртом.
> http://securityvulns.ru/news/Linux/kernel/1401.htmlВнимательно читаем до конца.
Оригинальный текст: http://securityvulns.ru/docs30152.html
"The problem can be corrected by updating your system to the following
package versions:Ubuntu 13.10:
linux-image-3.11.0-15-generic 3.11.0-15.23
linux-image-3.11.0-15-generic-lpae 3.11.0-15.23"
Усё. Закрыто.
Поищи еще чего-нибудь. :)
Вы процитировали http://www.ubuntu.com/usn/usn-2075-1/Это сборное обновление к пакету с ядром из состава Ubuntu 13.10, там собраны дыры за несколько месяцев. Например, CVE-2013-2929 поправлена ещё в апреле прошлого года. Все уязвимости минорные (в secunia им присвоен минимальный уровень опасности), т.е. в лучшем случае DoS или возможность получить значения пары байт памяти ядра. Поэтому для пакета их так много накопили, так как нет смысла без повода дергать пользователей ребутить систему.
> 1. Многочисленные уязвимости безопасности в ядре Linux
> http://securityvulns.ru/news/Linux/kernel/1401.html
> Опубликовано: 8 января 2014 г.
> Источник: BUGTRAQБаян! Пока вы там бухали!
https://www.opennet.ru/opennews/art.shtml?num=38768#48
> Описание:
IPIP - юзают все! ,
UDP_CORK - если найдёшь софт где оно ваще есть.
Alchemy LCD frame-buffer drivers - в каждом доме
WiMax - так ваще у каждого.
AACRAID - как же без него.
Ну и конечно же PTRACE на IA64
> неиницилизированная память в UDP fragmentation offload.Пля, пичаль. У меня юзается патчик который спецом отрубает инициализацию памяти.
Нате вам: http://media.ccc.de/browse/congress/2013/30C3_-_5499_-_en_-_...
- "In the past couple of months I've found 120 bugs there, and I'm not close to done."Обсуждение: http://www.rsdn.ru/forum/flame.comp/5422197.all
умиляют камменты всяких баранов, которые никогда не использовали, или почти не использовали cppcheck. у этой утилиты может быть множество ложных срабатываний. например, если инициализация структуры выносится в отдельную подпрограмму. и некоторые другие тонкости. зато такие "спецы" начинают сразу разводить словесный понос, важно почёсывая своё ЧСВ