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)

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

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

А, я понял, т.е. надо явно указывать зависимости для сборки, а после сборки сгенерятся новые зависимости для установки бинарного пакета. В Генте тоже предусмотрены DEPEND и RDEPEND, но, ЕМНИП, сейчас их влияние на процесс сборки одинаково.

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

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

Именно.

В Генте тоже предусмотрены DEPEND и RDEPEND, но, ЕМНИП, сейчас их влияние на процесс сборки одинаково.

В случае rpm-а они почти всегда разные. Причем зависимости сборки обычно намного толще, чем зависимости установки. Это — такая себе альтернатива use-флагам.

Вместо того, чтобы собирать пакеты с разными опциями, в rpm-дистрибутивах делают иначе — в исходниках при сборке все опции включают, а потом собранные из этих исходников файлы складывают в несколько разных бинарных пакетов. Это дает возможность устанавливать не все сразу, а только нужное. Например из одного mesa-8.0.2-2.fc17.src.rpm собирают:

mesa-debuginfo-8.0.2-2.fc17.i686.rpm
mesa-dri-drivers-8.0.2-2.fc17.i686.rpm
mesa-dri-filesystem-8.0.2-2.fc17.i686.rpm
mesa-libEGL-8.0.2-2.fc17.i686.rpm
mesa-libEGL-devel-8.0.2-2.fc17.i686.rpm
mesa-libGL-8.0.2-2.fc17.i686.rpm
mesa-libGL-devel-8.0.2-2.fc17.i686.rpm
mesa-libGLES-8.0.2-2.fc17.i686.rpm
mesa-libGLES-devel-8.0.2-2.fc17.i686.rpm
mesa-libGLU-8.0.2-2.fc17.i686.rpm
mesa-libGLU-devel-8.0.2-2.fc17.i686.rpm
mesa-libOSMesa-8.0.2-2.fc17.i686.rpm
mesa-libOSMesa-devel-8.0.2-2.fc17.i686.rpm
mesa-libgbm-8.0.2-2.fc17.i686.rpm
mesa-libgbm-devel-8.0.2-2.fc17.i686.rpm
mesa-libglapi-8.0.2-2.fc17.i686.rpm
mesa-libwayland-egl-8.0.2-2.fc17.i686.rpm
mesa-libwayland-egl-devel-8.0.2-2.fc17.i686.rpm
mesa-libxatracker-8.0.2-2.fc17.i686.rpm
mesa-libxatracker-devel-8.0.2-2.fc17.i686.rpm
А из исходников gcc собирается четыре десятка разных бинарных пакетов.

И если, например, нужно установить Qt, который требует libGL.so.1 и libGLU.so.1, то в систему будут установлены только пакеты mesa-libGL и mesa-libGLU. Если понадобится этот самый Qt пересобрать, то к ним добавятся mesa-libGL-devel и mesa-libGLU-devel. Но еще полтора десятка пакетов устанавливаться не будут.

Получается, что пользователь может поставить в себе только те пакеты, которые нужны для работы. Если ему не нужно ничего собирать, то он не будет ставить ни autotools, ни gcc, ни debug ни devel-пакеты. Это экономит кучу места. Благодаря этому на 700МБ livecd влазит полностью рабочая система с DE, офисом и еще кучей софта. :)

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

Это — такая себе альтернатива use-флагам.

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

Фатальный недостаток этого метода — опции линковки нельзя выделить в отдельный пакет. Поэтому если pulseaudio в rpm-based линуксах еще можно выпилить, то libpulseaudio уже нельзя, потому что тысячи пакетов слинкованы с ним.

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

Ну... все познается в сравнении... если ты работал с малокософтовским CryptoAPI, то я тебя понимаю.

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