Mikolaj Izdebski обнаружил (http://lists.debian.org/debian-security-announce/2010/msg001...) в функции BZ2_decompress целочисленное переполнение, способное привести к выполнению кода злоумышленника или отказу в обслуживании (denial of service) при обработке специально сформированного потока данных для распаковки.
Проблема устранена в вышедшем сегодня релизе сайте bzip2 1.0.6 (http://www.bzip.org), обновления с исправлениями также выпущены в Debian GNU/Linux (http://www.debian.org/security/) (DSA-2112-1). Статус выхода исправлений для других дистрибутивов: Slackware (http://www.slackware.com/security/list.php?l=slackware-secur...), FreeBSD (http://www.vuxml.org/freebsd/), Gentoo (http://www.gentoo.org/security/en/index.xml), Mandriva (http://www.mandriva.com/en/security/advisories?dis=2010.1), openSUSE (http://lists.opensuse.org/opensuse-security-announce/2010-09/), CentOS (http://lists.centos.org/pipermail/centos-announce/2010-Septe...), Fedora (https://...URL: http://lists.debian.org/debian-security-announce/2010/msg001...
Новость: http://www.opennet.me/opennews/art.shtml?num=28021
Вот как не програмист я удивляюсь, сколько же можно дырок-то "напихать" в таких, казалось бы, маленьких библиотеках как zlib, gzip, bzip. К тому же активно используемых ну просто везде. За несколько лет работы с unix перед глазами нет-нет, да и промелькнет сообщение об очередном переполнении в одной из них. Это, конечно, все очень субьективно, по статистике ( если смотреть их чейнджлоги ), все может быть совсем не фатально.
Ну тут они хоть находятся и правятся, и шансов, что они юзаются годами в тихую меньше, чем сами знаете где.
> что они юзаются годами в тихую меньшеага, пару дней назад была новость про уязвимость в 64-битных ядрах
>ага, пару дней назад была новость про уязвимость в 64-битных ядрахВ винде обычно все колоритнее. Ну вот например немало разработчиков разного софта влинковывает какойнить там злиб в основной бинарь так что хрен заменишь, а если и не влинковывают то обновлять разбросанные по всей системе десятки копий либы - малореально. И если софт без исходников - авторы не будут поддерживать его вечно. В итоге у виндовых юзеров и по сей день можно что-нить с уязвимой злибой найти.
>по сей день можно что-нить с уязвимой злибой найтину например?
Пожалуйста. Вот так навскидку из того что под руку попадалось под хексэдитор. Игра Герои меча и магии. Скажем III и IV. Они есть, в них до сих пор играют (потому что прямых аналогов толком не сделали). Там злиба статически влинкована в бинарь и хрен ее такую заменишь. Какая версия была на момент выпуска какихнить там HMM III - понятно. А что веселее всего - там данные при игре по сети как раз злибом и жмутся. Нормально так, да? :) Ну и понятное дело что на обновление ископаемых версий героев производитель давно забил - они там заняты рубанием бабла, а проблемы негров шерифа не волнуют. А вот так поиграешь в игрушку по сети. И трояна как бонус получишь, например. При том наверняка такая же Ж и в других программах - поскольку у системы нельза попросить актуальную копию zlib.dll которую бы системный апдейтер поддерживал в исправном состоянии, каждый воротит кто на что горазд. И далеко не любой автор программы столь же дотошен в части security как майнтайнеры репов например и неленив для того чтобы следить за всеми дырами всех либ и написать апдейтер который еще и работать будет нормально. В итоге в винде валяются десятки копий либы, где-то влинкованых в блобятину, где-то в виде либ в разных каталогах, разных версий. И никто за этим супергадюшником разумеется не следит. Потому что нереально это. В линухах с их пакетными системами такое как-то сильно культурнее рюхается.
хорошо бы посмотреть как давно эта ошибка добавлена..
что-то мне говорит что она не один год уже существует..
Как знаете где ?
> что-то мне говорит что она не один год уже существует..Речь не о просто ошибках, а об _известных_ ошибках.
>> что-то мне говорит что она не один год уже существует..
>
>Речь не о просто ошибках, а об _известных_ ошибках.Хрень редьки не слаже.
Тут регулярно раздаются вопли что СПО содержит меньше ошибок чем закрытый код.
А на практике дыры существуют годами и никому до них дела нету.То 3 дырки в ядре которые позволяют написать легкий root exploit, то вот дырка в bz2..
Где же хваленое качество ?
>Где же хваленое качество ?Что такое - "качество"? (подсказка: http://slovari.yandex.ru/качество/БСЭ/Качество/ ) Вы сами сформировали стереотип - "если свободное ПО, то оно будет бесплатно и при том не будет содержать ошибок", а теперь сердитесь на разрушение этого стереотипа? Выполните команду
$bzip --version
и насладитесь текстом, добавленным по рекомендации FSF ( http://www.gnu.org/copyleft/gpl.html#howto ): "This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE."
>>Где же хваленое качество ?
>
>Что такое - "качество"? (подсказка: http://slovari.yandex.ru/качество/БСЭ/Качество/ ) Вы сами сформировали стереотип -Вы плохо знаете русский язык? Словосочетание "хваленое качество" однозначно указывает не на Ваш вариант значения, а на http://slovari.yandex.ru/качество/Лопатников/Качество/ - это quality как "добротность".
>"если свободное ПО, то оно будет бесплатно и при том не
>будет содержать ошибок", а теперь сердитесь на разрушение этого стереотипа?"не будет содержать" - это, очевидно, верхний предел, тогда как требуется просто достаточно высокий уровень.
>is distributed in the hope that it will be useful, but
>WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>FITNESS FOR A PARTICULAR PURPOSE."А это вообще стандартная отмазка в любой лицензии, не только в опенсорсе. Она не имеет отношения к декларируемым goals.
Впрочем, для исходного автора: действительно, Free Software не гарантирует никакого качества, хуже того, это не является их целью! И даже в некоторых случаях прямо противоречит. Цитата из интервью Столлмана:
<<The rest of this question presents an argument based on the premise
that the principle goal is faster technical progress. I disagree with
that goal, because I value freedom more than technical progress>>
>Где же хваленое качество ?В СПО дырку можно запатчить по факту обнаружения. А как мне запатчить скажем древний zlib в какихнить героях меча и магии на которых производитель давно забил, не забыв влинковать проблемный код прямо в блоб? Что еще веселее - этот код потенциально работает с внешним миром по сети - вероятно можно раздолбать через него проблемную либу только так. А потом виндузятники удивляются - "ой, винлокеры". "Ой, спам!". "Ой, порнобаннер на десктопе!И кравивую аську увели!". Ну конечно, когда либу с дырой хрен обновишь - там что угодно будет, блин. Мне вот не нравится когда вместо системы - большая свалка приватных копий либ на которые всем наплевать.
> Как знаете где?Запятую куда?
>Запятую,
>куда?
>Запятую куда?"Гусары, молчать!"
> Вот как не програмист я удивляюсь, сколько же можно дырок-то "напихать" в таких, казалось бы, маленьких библиотеках как zlib, gzip, bzipВот были-бы программистом, знали-бы как неожиданно просто делаются ошибки :)
Для создания программы нужно учесть очень много подробностей [картинка: человек несёт большую охапку свёрточков и коробочек]. Так много, что иногда теряется физическая возможность их всех контролировать [картинка: что-то упало]. Безусловно, что пропажу ценных вещей замечают довольно скоро, а вот проблемы с редко используемыми вещами обнаруживаются позже [картинка: опять забыл зубную щётку]. В нулевом приближении как-то как...
FreeBSD-SA-10:08.bzip2
ага, оперативно, пошли обновляться.
# fetch http://security.FreeBSD.org/patches/SA-10:08/bzip2.patch
# fetch http://security.FreeBSD.org/patches/SA-10:08/bzip2.patch.asc
# cd /usr/src
# patch < /path/to/bzip2.patch
# cd /usr/src/lib/libbz2
# make obj && make depend && make && make install
не для всех архитектур катит. но в целом верно, патчи уже есть.