В свете недавней очень серьёзной уязвимости Heartbleed протокола Heartbeat в сторонней библиотеке OpenSSL, разработчики OpenBSD решили окончательно и бесповоротно переписать всю библиотеку SSL, удалив груду разных кодов совместимости и поддержки несуществующих архитектур (например, big-endian i386/amd64), сохранив лишь API-совместимость с upstream OpenSSL.

Данное начинание некоторые временно называли OpenOpenSSL (т.к. оригинальный OpenSSL разрабатывается вне OpenBSD), но OpenBSD Foundation теперь объявило официальное название — «LibreSSL (the OpenBSD fork of OpenSSL)». Название также можно воспринимать как «lib-re-ssl» — переработка библиотеки ssl.

Что именно принудило проект OpenBSD отказаться от какого-либо сотрудничества с OpenSSL в будущем? Разработчик tedu@openbsd решил описать историю нового libressl на свежую память:

• Протокол Heartbeat никто до сих пор не использует, однако он был всегда включён с момента поддержки в OpenSSL пару лет назад, и его нельзя было выключить без перекомпиляции с OPENSSL_NO_HEARTBEATS. (Поддержка теперь была полностью удалена из OpenBSD libressl.)
• Предполагалось, что для избежания Heartbleed на OpenBSD достаточно будет установить опцию J в malloc.conf. Однако разработчики OpenSSL специально позаботились и сделали это невозможным, и поэтому даже на OpenBSD необходимо пересобирать всю библиотеку для устранения серьёзной уязвимости Heartbleed (в 5.3, 5.4 и 5.5, OpenSSL 1.0.0f в 5.2 и ранее не уязвим).
• В процессе тестирования опции J с OpenSSL была обнаружена старинная ошибка в OpenSSL, о которой уже несколько лет было известно разработчикам OpenSSL, и даже имелось очень простое исправление. Однако разработчики OpenSSL до сих пор не приняли это к сведению. Командам OpenBSD, FreeBSD и Debian пришлось исправлять ошибку без какой-либо помощи от OpenSSL. Пару недель спустя, в upstream CVE-2010-5298 до сих пор исправить не удосужились.

Так как сотрудничество с таким upstream нереально и в дальнейшем не предполагается, было принято решение улучшить читаемость всего кода в соответствии с style(9) — KNF, а также удалить весь неиспользуемый код для упрощения аудита. В будущем планируется выпуск портативной версии, после периода стабилизации.

>>> http://BXR.SU/OpenBSD/lib/libssl/src/ssl/

Появляется все больше хороших и плохих известий, связанных с уязвимостью “Heartbleed”.

Хорошие новости заключаются в том, что уже около трети серверов обновились и перестали быть уязвимыми. Плохая новость — по меньшей мере 600 тысяч машин остаются незащищёнными, вдобавок необходимо учесть количество встраиваемых систем, к которым уже перестали выходить обновления прошивок. Более того, зафиксированы свидетельства того, что уязвимость эксплуатировалась злоумышленниками еще в 2013 году. Компания MediaMonks обнаружила это после исследования журналов аудита за ноябрь прошлого года.

Эксперт по безопасности Брюс Шнайер назвал Heartbleed катастрофой. «По десятибалльной шкале это тянет на 11», написал он у себя в блоге. Шнайер оценивает вероятность того, что различные спецслужбы уже успели воспользоваться уязвимостью для массового извлечения приватных ключей, как близкую к единице. Следует рассматривать любой сертификат и пароль, как скомпрометированный, поскольку обнаружить следы атаки было практически невозможно. Неизвестно, где и как отзовутся нам эти утечки.

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

Команда разработчиков OpenSSL Project выпустила срочный бюллетень безопасности, гласящий о критической уязвимости в библиотеке OpenSSL, которую обнаружили подразделение Google Security и компания Codenomicon.

Уязвимость, которой присвоен код CVE-2014-0160, находится в расширении Heartbeat (RFC6520) протокола TLS. Из-за отсутствия необходимой проверки в одной из функций, злоумышленник мог получить прямой доступ к оперативной памяти компьютеров, использующих OpenSSL. В том числе, доступ к секретным ключам, именам/паролям пользователей и всему зашифрованному трафику. При этом, на компьютере не оставалось никаких следов проникновения.

Любой, кому было известно об уязвимости, мог прослушивать зашифрованный трафик в Интернете с марта 2012 года (когда вышла OpenSSL 1.0.1). Как раз тогда была опубликована методика атаки на протокол SSL - BEAST, в связи с чем многие перешли на более защищенную версию TLS 1.2, поддержка которой появилась именно в OpenSSL 1.0.1. Уязвимая версия OpenSSL используется практически во всем Интернете: веб-серверами Nginx и Apache, почтовыми и IM-серверами, VPN-серверами и клиентами, и массой других программ.

Уязвимы все ветки OpenSSL 1.0.1 и 1.0.2-beta. Всем пострадавшим нужно как можно скорее обновиться до версии 1.0.1g, а также создать новые ключи и сертификаты. В случае невозможности немедленного обновления необходимо пересобрать OpenSSL с флагом -DOPENSSL_NO_HEARTBEATS.

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

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

( читать дальше... )

взято с opennet.ru

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

Среди основных изменений:

• долгожданная поддержка TLS v1.1 и v.1.2 *
• поддержка протоколов SCTP, SRP
• поддержка Next Protocol Negotiation
• поддержка PSS в сетрификатах, запросах, а также в списках отозванных сертификатов (CRL)
• поддержка TLS/DTLS heartbeat
• RFC 5705 TLS key material exporter
• RFC 5764 DTLS-SRTP negotiation
• Support for password based recipient info for CMS
• Preliminary FIPS capability for unvalidated 2.0 FIPS module

* напомню, что начиная с TLS версии 1.1 закрыта уязвимость протокола TLS, позволяющая расшифровать часть трафика с помощью js скрипта в браузере жертвы (даже открытого в другой вкладке). Подробнее об уязвимости: на opennet.ru и на LOR

Источник

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

OpenSSL core team любезно извещает нас об устранении уязвимости в OpenSSL based TLS server. Пользователи всех релизов OpenSSL 0.9.8 должны незамедлительно обновиться до OpenSSL 0.9.8p, в котором проблема уже исправлена. Пользователям OpenSSL 1.0.0 и 1.0.0a необходимо обновиться до 1.0.0b.

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

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

Bodo Moeller and Adam Langley из Google обнаружили и исправили уязвимость в OpenSSL, приводящую к краху сервера или клиента в случае использования некорректных пакетов в TLS соединениях.

Уязвимости подвержены OpenSSL 0.9.8m и, в зависимости от компилятора (если short = 16 bit int), OpenSSL 0.9.8f - 0.9.8m.

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

В библиотеке OpenSSL была обнаружена уязвимость, позволяющая злоумышленнику провести DoS атаку через исчерпание доступной памяти. Уязвимая функция CRYPTO_free_all_ex_data() используется в таких приложениях как Apache с модулем PHP.

Патч

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

В своём блоге небезызвестный программист Линус Торвальдс сообщает, что на его рабочей станции с процессором на ядре Nehalem его реализация SHA1 для git работает быстрее SHA1 из библиотек OpenSSL. Он отмечает, что это позволило отказаться от привязки к libcrypt и на несколько секунд увеличить результаты прохождения тестов. Причём он выделяет, что он писал на «почти кросс-платформенном ассемблере» С, в отличие от разработчиков OpenSSL, писавших на ассемблере.

В своей обычной манере Торвальдс отзывается о компиляторах ("...it turns out that getting good results from SHA1 really is mostly about trying to fight the compilers tendency to try to be clever" - "...ясно, что чтобы получить хорошую реализацию SHA1, надо бороться с тенденцией компиляторов быть самыми умными"), процессорных архитектурах («On my Nehalem machine (but not Netburst or Atom - poor fragile micro-architectures that they are)...» - «На моей машине с Nehalem (ни в коем случае не с Netburst или Atom - убогие хрупкие микро-архитектуры)...») и даже бибилиотеках, к которым привязывался git ("...I get rid of two silly runtime loadable libraries that git no longer needs" - "...Я избавился от двух глупых загружаемых библиотек времени исполнения, которые больше не нужны git")

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

Было обнаружено, что ГСЧ в пакете openssl в Debian (а также Debian-based дистрибутивах) был предсказуемым с версии 0.9.8c-1 (добавленной в unstable 2006-09-17) из-за Debian-специфичной поправки. Могли быть затронуты ключи SSH, OpenVPN, DNSSEC и ключевой материал для сертификатов X.509, а также ключи сессий SSL/TLS-соединений. Рекомендуется пересоздать весь криптографический материал, созданый OpenSSL начиная с версии 0.9.8c-1 на системах Debian. Также следует считать скомпрометированными все ключи DSA, использованные для подписывания или авторизации на затронутых системах Debian, т.к. Digital Signature Algorithm завязан на секретное случайное число, используемое при генерации.

Должны быть выложены: детектор слабого ключевого материала http://security.debian.org/project/ex... и инструкции по смене ключей.

Ошибка была исправлена в stable ветке (etch) с версии 0.9.8c-4etch3. В unstable ветке (sid) и тестовой (lenny) ошибка исправлена с 0.9.8g-9. Старая stable ветка (sarge) не затронута. Также в пакете openssl были исправлены еще две уязвимости.

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