LINUX.ORG.RU

Критическая уязвимость в OpenSSL

 ,


0

1

В экстренном порядке выпущены корректирующие релизы библиотеки OpenSSL 1.0.1a, 1.0.0i и 0.9.8v, устраняющие критическую уязвимость, которая потенциально может быть применена для совершения атаки на приложения, использующие функции OpenSSL. При успешном совершении атаки может быть инициировано выполнение кода злоумышленника.

Проблема выявлена группой исследователей безопасности из компании Google. Информации о наличии в публичном доступе готового к использованию эксплоита пока нет, но теоретически создание такого эксплоита не составит труда, поэтому всем пользователям рекомендуется в кратчайшие сроки обновить OpenSSL.

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

Проблема вызвана ошибкой приведения типов в функции asn1_d2i_read_bio() при разборе данных в формате DER, используемого при работе с S/MIME и CMS. Уязвимость позволяет инициировать переполнение буфера и выполнить код злоумышленника при обработке специально оформленных данных. Теоретически эксплуатация уязвимости возможна только на 64-разрядных системах.

Опасность эксплуатации уязвимости отмечается для приложений, использующих для разбора MIME-блоков функции SMIME_read_PKCS7 и SMIME_read_CMS, а также любые другие функции, связанные с декодированием DER-блоков через функции на базе BIO (d2i_*_bio) и FILE (d2i_*_fp), например, 2i_X509_bio или d2i_PKCS12_fp. В частности, уязвимости подвержена штатная утилита командной строки из состава OpenSSL; уязвимость может быть использована при обработке данных в формате DER. Приложения, использующие только процедуры PEM или функции ASN1 (d2i_X509, d2i_PKCS12 и т.п.), не подвержены данной уязвимости. Код, связанный с SSL и TLS, проблеме не подвержен, тем не менее следует обратить внимание на то, не используют ли приложения проблемных функций, подобных d2i_X509_bio.

взято с opennet.ru

>>> Подробности

★★★★★

Проверено: mono ()
Последнее исправление: JB (всего исправлений: 7)

Тега «РЕШЕТО» не хватает.

renya ★★★★★
()

читать совершенно невозможно! разбейте хоть на абзацы. cast Silent

ymn ★★★★★
()

я уже обновился в генте, а они тут только новость в неподтвержденные добавили :)

Harald ★★★★★
()
Ответ на: комментарий от Harald

я уже обновился в генте, а они тут только новость в неподтвержденные добавили :)

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

vaino
()

В Debian Stable фикс уже есть

openssl (0.9.8o-4squeeze11) squeeze-security; urgency=low

  * Really apply CVE-2012-2110

 -- Kurt Roeckx <kurt@roeckx.be>  Thu, 19 Apr 2012
anonymous
()
Ответ на: комментарий от Harald

в Debian тоже прилетело обновление.

ymn ★★★★★
()

С утра в дебиане обновилось.

З.Ы. На опеннете новость появилась раньше :-)

Debasher ★★★★★
()

Акутуальный вопрос: если у меня, к примеру, собран Postfix с поддержкой openssl, нужно ли мне его персобирать после обновления?

Yustas ★★★★
()
Ответ на: комментарий от Yustas

Нет, не нужно. Хотя, если ты его умудрился собрать статиком, то да. :D

imul ★★★★★
()

Что-то слишком много багов в разном софте в последнее время.

Теоретически эксплуатация уязвимости возможна только на 64-разрядных системах.

Хоть это немного радует.

gentoo_root ★★★★★
()

Ни сна, ни отдыха. Поделие.

UNiTE ★★★★★
()

Ребят, а можно пример тестого кода и эксплойта к нему, с описанием переполнения буфера и пример эксплойта для него с выполнением любой команды. Хочется на это взглянуть..

fjfalcon ★★★
()
Ответ на: комментарий от fjfalcon

можно пример тестого кода и эксплойта к нему, с описанием переполнения буфера и пример эксплойта для него с выполнением любой команды. Хочется на это взглянуть..

по ссылке присутствует вполне внятный код с разбором ситуации, комментариями и чуть не инстукциями по применению.

вам хочется наличия configure или бинарного rpm ?

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

MKuznetsov ★★★★★
()
Ответ на: комментарий от MKuznetsov

Мне в данном случае интересует не сколько данная уязвимость - а сколько уязвимость с переполнением буфера.

fjfalcon ★★★
()

Да, опять проблемы с этим решетом.

lucentcode ★★★★★
()

поэтому всем пользователям рекомендуется в кратчайшие сроки обновить OpenSSL.

Хы, как раз за пару минут до прочтения новости обновил.

Akamanah ★★★★★
()
Ответ на: комментарий от fjfalcon

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

вкратце, иллюстративно, пусть есть код:

char buffer[BUF_SIZE];
void (*)f();
..
int main() {
  gets(buffer);
  f();
}

остаётся сформировать строку, содержащую shell-код и со смещения BUF_SIZE - адрес входа в него. И сунуть это строку на стандартный ввод. Учитывая что адрес входа (расположение buffer) фиксирован - формирование такой строки просто дела навыка и в крайнем случае автоматизируется.

заменой седого gets() на сложнопроизносимые функции 2i_X509_bio, а стандартный ввод на DER-кодированные данные получаем эксплойт указанный в топике.

MKuznetsov ★★★★★
()

Про решето уже написали?

hobbit ★★★★★
()

Я всегда говорил, что надо переходить на GnuTLS и PolarSSL.

powerpc
()
Ответ на: комментарий от gentoo_root

Теоретически эксплуатация уязвимости возможна только на 64-разрядных системах.

И сюда эту хрень с опеннета скопипастили. http://seclists.org/fulldisclosure/2012/Apr/225

Correct me if I am wrong, but shouldn't this only be a problem on
systems where a size_t is wider than an int i.e. not on 32 bit systems?

No because size_t is unsigned. Some attacks would rely on being 64 like he stated, but not all.

Хоть это немного радует.

Радует, что у вас на современном оборудовании работает код, собранный для устаревшей архитектуры? Напрасно.

anonymous
()
Ответ на: комментарий от anonymous

Радует, что у вас на современном оборудовании работает код, собранный для устаревшей архитектуры?

Вообще-то, из моих персональных компьютеров только один умеет 64 бита (тот, что с 4-ым пнём). Остальные не умеют. А 32-битную систему на 64-битном компе я использую, потому что 64 бита ещё не готовы. Костыль в виде мультилиба заставляет меня ставить бинарные 32-битные либы, которые в Генте нельзя скомпилировать без геморроя и которые занимают лишнее место на диске — меня это не устраивает. Без мультилиба некоторые проприетарные программы не заработают, если их нужно будет внезапно запустить. А ещё была проблема с установкой cnijfilter для принтера на 64-битную систему, когда у меня было 64 бита, — файлы не в те каталоги ставились, приходилось перемещать их, устанавливать пакет руками и получил геморрой с незапускающимися бинарями. Это не говоря о том, что какой-то костыль для KDE (ЕМНИП, для внешнего вида gtk-программ, не помню уже, какой) не работал на 64-битной системе.

В общем, не готовы 64 бита для десктопа. Были бы готовы — с радостью использовал бы.

gentoo_root ★★★★★
()
Ответ на: комментарий от gentoo_root

Костыль в виде мультилиба заставляет меня ставить бинарные 32-битные либы, которые в Генте нельзя скомпилировать без геморроя

Проблемы с multilib сугубо у Gentoo, тебе не кажется?

dexpl ★★★★★
()
Ответ на: комментарий от dexpl

Проблемы с multilib сугубо у Gentoo, тебе не кажется?

Нет, в других дистрибутивах проблем с multilib ещё больше. Если в Генте проблема в том, что из коробки не компилируются 32-битные либы, а ставятся бинари, то в других дистрибутивах ситуация ещё хуже: не компилируются ни 32-битные, ни 64-битные либы.

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

gentoo_root ★★★★★
()
Ответ на: комментарий от gentoo_root

в других дистрибутивах ситуация ещё хуже: не компилируются ни 32-битные, ни 64-битные либы

Откуда тогда в репозиториях этих дистрибутивов пакеты с библиотеками?

dexpl ★★★★★
()
Ответ на: комментарий от dexpl

Откуда тогда в репозиториях этих дистрибутивов пакеты с библиотеками?

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

gentoo_root ★★★★★
()
Ответ на: комментарий от gentoo_root

Их компилируют мейнтейнеры

Чуть выше ты утверждал принципиальную невозможность их компиляции, если я правильно понял

dexpl ★★★★★
()
Ответ на: комментарий от dexpl

Чуть выше ты утверждал принципиальную невозможность их компиляции, если я правильно понял

Нет, я, конечно, имел в виду только компиляцию на своём локалхосте.

В бинарных дистрибутивах мейнтейнеры могут вообще просто взять сборку пакета из 32-битной версии, поменять lib на lib32, перезапаковать и выкинуть в репозиторий. Или они могут собрать либы кросскомпилятором. Мне бы подошёл второй вариант для сборки у себя, но готового решения (ебилды) для Генты нет, и это плохо.

gentoo_root ★★★★★
()

трагедия! трагедия!

bernd ★★★★★
()
Ответ на: комментарий от anonymous

Есть оверлей, кажется multilib или как-то так. Там ебилды для сборки 32-битных библиотек.

Прикольно, не знал о таком. Если вдруг стану переходить на 64 бита, учту это.

gentoo_root ★★★★★
()
Ответ на: комментарий от gentoo_root

Вообще-то, из моих персональных компьютеров только один умеет 64 бита (тот, что с 4-ым пнём). Остальные не умеют.

Работу найти не пробовал? У меня если что МК-52 в кладовке 20 лет лежит, но я не делаю из этого далекоидущих выводов что 16 бит не готовы для продакшена.

и которые занимают лишнее место на диске — меня это не устраивает

446 мегабайт, это ужасно, попроси родителей подарить тебе новый винчестер и положи на полку свой гиговый. У меня он уже 11 лет там.

В общем, не готовы 64 бита для десктопа. Были бы готовы — с радостью использовал бы.

Ты их не умеешь готовить. Или гентушник из тебя поддельный. У меня система уже больше 6 лет на 64 битах живет и все ок.

black7
()
Ответ на: комментарий от black7

У меня система уже больше 6 лет на 64 битах живет и все ок.

Двачую. То же самое, причём даже pure 64-bit, без никаких multilib. Проприетарные 32-битные быдлоподелия не нужны.

anonymous
()
Ответ на: комментарий от fjfalcon

Ребят, а можно пример тестого кода и эксплойта к нему, с описанием переполнения буфера и пример эксплойта для него с выполнением любой команды. Хочется на это взглянуть..

Экплоита нет, вроде, проблему только теоретически нашли в коде. Причем SSL/TLS проблеме не подвержен. Кроме него с сертификатами работают только браузеры, а они openssl не используют. К тому же, похоже, для 32 и 64-бит ее надо эксплуатировать по-разному. Дурацкая уязвимость какая-то.

anonymous
()
Ответ на: комментарий от gentoo_root

Нет, в других дистрибутивах проблем с multilib ещё больше. Если в Генте проблема в том, что из коробки не компилируются 32-битные либы, а ставятся бинари, то в других дистрибутивах ситуация ещё хуже: не компилируются ни 32-битные, ни 64-битные либы.

Не везде все так плохо. В федоре проблему мультилиба решили еще с самых первых версий. В системе параллельно могут быть установлены пакеты от разных архитектур. Зависимости рассчитываются автоматически с учетом архитектуры. И никаких проблем со сборкой 32-битных пакетов на 64-битной системе тоже нет:

rpmbuild --target x86_64 ...

rpmbuild --target i686 ...

anonymous
()
Ответ на: комментарий от anonymous

И никаких проблем со сборкой 32-битных пакетов на 64-битной системе тоже нет: rpmbuild --target x86_64 ...

И как этому rpmbuild'у указать опции конфигурирования, патчи, CFLAGS, LDFLAGS и прочие нужные вещи? И что-то я сомневаюсь, что это вообще возможно, а тем более он не может уметь определять зависимости пакета от опций конфигурирования. Отсутствие этих всех возможностей на корню сжигает все преимущества сборки из исходников.

gentoo_root ★★★★★
()

Ололо, в списке рассылки разработчики сообщили, что версия 0.9.8v оказалась недоисправленной и всем пользователям ветки 0.9 следует обновиться до 0.9.8w.

anonymous
()
Ответ на: комментарий от gentoo_root

И как этому rpmbuild'у указать опции конфигурирования

rpmbuild --with baseonly --without debuginfo ...

CFLAGS, LDFLAGS

Так обычно никто не делает, но если хочется:
CFLAGS=«blabla» LDFLAGS=«bububu» rpmbuild ...

Дефолтные опции можно изменить, задав в ~/.rpmmacros переменную %optflags.

По-умолчанию там лежит что-то вроде: -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4, плюс свои опции для каждой архитектуры. Для i686, например, добавляется: -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables.

и прочие нужные вещи?

Для того, чтобы собрать rpm-пакет, достаточно всего два файла — тарбол с исходниками и spec-файл.

Вся инструкция сборки rpm-пакета хранится в одном текстовом файле имяпакета.spec. В нем указываются имя пакета, его версия и описание, команды для сборки (configure, make, python setup.py, pear install или perl Makefile.PL), имена/версии нужных для сборки зависимостей. Чтобы добавить патч, в spec-файл вписывают две строки:

Patch: имя-файла-с-патчем.patch
и в нужном месте в секции распаковки исходников:
%patch -p1

Если хочется, чтобы один и тот же пакет из одного спека собирался с разными параметрами, то в спек добавляют эти параметры, а потом задают их через --with и --without в rpmbuild-е.

а тем более он не может уметь определять зависимости пакета от опций конфигурирования.

А это — главное преимущество rpm-а перед, например, deb-ом. Почти все зависимости rpm определяет сам, просто глядя на ldd собранных бинарников.

anonymous
()
Ответ на: комментарий от anonymous

В общем, из этого я делаю вывод, что rpmbuild — это нечто среднее между гентушным portage и арчевским makepkg. Есть spec-файл, который — нечто вроде ебилда или пкгбилда, есть локальные одноразовые USE-флаги (типа как «USE="-nls -readline" emerge sys-apps/somepackage»), но сохраняемых локальных и вообще глобальных юзов нет — всё равно есть не все возможности portage. И ещё смущает эта фраза:

Если хочется, чтобы один и тот же пакет из одного спека собирался с разными параметрами, то в спек добавляют эти параметры, а потом задают их через --with и --without в rpmbuild-е.

Это значит, что по дефолту все спеки, распространяемые мейнтейнером rpm-дистрибутивов, написаны вообще без «USE-флагов», но есть возможность их руками добавить? Это уже арч какой-то получается, в котором пкгбилды без юзов, или LFS, в котором надо самому писать скрипты сборки.

Почти все зависимости rpm определяет сам, просто глядя на ldd собранных бинарников.

Это, конечно, круто, но только есть одна проблема: на ldd собранных бинарников можно посмотреть только после сборки, но эта информация нужна до сборки, чтобы удовлетворить зависимости. Как они выкручиваются?

gentoo_root ★★★★★
()
Ответ на: комментарий от gentoo_root

но эта информация нужна до сборки

если написатель программы не уёбок, он приводит список зависимостей в readme
иначе, можно посмотреть в исходниках и скриптах autotools/cmake

anonymous
()
Ответ на: комментарий от anonymous

он приводит список зависимостей в readme

иначе, можно посмотреть в исходниках и скриптах autotools/cmake

Это никак не относится к автоматическому определению зависимостей по библиотекам, с которыми слинковался получившийся бинарник. Раз уж есть такая возможность, то она же как-то работает. Вот мне и интересно знать, как оно работает, если там 2 события (линковка и установка зависимостей), каждое из которых должно произойти раньше другого. То, как можно узнать зависимости вручную, очевидно и так.

PS Ответил не на то сообщение, чтобы не потёрли всю ветку обсуждения в случае удаления сообщения с матом.

gentoo_root ★★★★★
()
Ответ на: комментарий от gentoo_root

В общем, из этого я делаю вывод, что rpmbuild — это нечто среднее между гентушным portage и арчевским makepkg.

Скорее, это что-то вроде bash-а, интерпретатор для spec-файлов, язык которого заточен под сборку пакетов. Он не лазит по репозиториям, и не выкачивает зависимости сам (для этого есть apt/yum). Его задача — это только сборка пакета.

Например, «пакет» исходников mc-4.8.3-1.fc16.src.rpm — это архив, внутри которого лежат исходники mc-4.8.3.tar.xz с официального сайта и mc.spec.

Его можно распаковать и собрать командой `rpmbuild -ba --target i686 mc.spec`. Либо, если spec править не нужно, можно не распаковывая запустить сборку `rpmbuild --rebuild --target i686 mc-4.8.3-1.fc16.src.rpm`.

В результате этой одной команды получится файл бинарного пакета mc-4.8.3-1.fc16.i686.rpm. Этот бинарный пакет можно установить себе, а можно записать на флешку и отнести другу. Или разослать puppet-ом и установить на кучу серверов...

по дефолту все спеки, распространяемые мейнтейнером rpm-дистрибутивов, написаны вообще без «USE-флагов»

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

на ldd собранных бинарников можно посмотреть только после сборки, но эта информация нужна до сборки

В rpm это — разные зависимости. Есть исходники, а есть собранный из них бинарный пакет. Для сборки исходников нужны одни зависимости, а для использования собранного бинарного пакета нужны другие.

Например для сборки mc нужен gcc, но для его использования gcc не нужен. В rpm-е это называется Requires и BuildRequires. Зависимости, которые нужны для сборки (BuildRequires), явно указываются в spec-файле. А зависимости собранного бинарного пакета (Requires) определяются автоматически.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.