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

Что именно представляет собой CVE-2014-0160 aka "Heartbleed"?

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

Ошибка была независимо обнаружена Нилом Мехта из Google Security (21 марта 2014 г.) и финской компанией по тестированию ИТ-безопасности Codenomicon (2 апреля 2014 г.).

В чем причина?

Ну, ошибочный код в OpenSSL. Вот коммит, который представил уязвимость, и вот коммит, который исправил уязвимость. Ошибка обнаружилась в декабре 2011 года и была исправлена ​​сегодня, 7 апреля 2014 года.

Ошибка также может рассматриваться как признак более серьезной проблемы. Две связанные проблемы: (1) какой процесс используется, чтобы гарантировать, что ошибочный код не введен в кодовую базу, и (2) почему протоколы и расширения настолько сложны и трудны для тестирования. Пункт (1) - это проблема управления и процесса с OpenSSL и многими другими проектами. Многие разработчики просто сопротивляются таким практикам, как проверка кода, анализ и сканирование. Пункт (2) обсуждается в рабочей группе IETF по TLS. См. Heartbleed / сложность протокола.

Был ли ошибочно вставлен ошибочный код?

Я не буду размышлять о том, действительно ли это было ошибкой или, возможно, был добавлен фрагмент кода от имени плохого актера. Однако, человек, который разработал код для OpenSSL, утверждает, что он был непреднамеренным. См. Человек, который ввел серьезный недостаток безопасности "Heartbleed" отрицает, что он вставил его намеренно.

Какие ОС и версии OpenSSL уязвимы?

Как упомянуто выше, любая операционная система, которая использует, или приложение, которое связано с OpenSSL 1.0.1 до 1.0.1f.

Каковы симптомы, существуют ли какие-либо методы для обнаружения успешного использования?

Это страшная часть. Насколько нам известно, не существует известного способа определить, была ли эта уязвимость использована. Теоретически возможно, что в ближайшее время будут выпущены сигнатуры IDS, которые могут обнаружить этот эксплойт, но на момент написания они недоступны.

Существуют свидетельства того, что Heartbleed активно эксплуатировался в условиях дикой природы уже в ноябре 2013 года. См. EFF Wild in the Heart: были ли разведывательные агентства, использующие Heartbleed в ноябре 2013 года? И Bloomberg сообщает, что АНБ применило эксплойт вскоре после того, как была обнаружена уязвимость. Посмотрите, что АНБ сказал, что эксплуатирует ошибку Heartbleed для разведки в течение многих лет. Однако разведывательное сообщество США отрицает претензии Bloomberg. Смотрите IC на записи.

Как я могу проверить, не повреждена ли моя система?

Если вы поддерживаете OpenSSL в вашей системе, то вы можете просто выпустить openssl version:

$ openssl version
OpenSSL 1.0.1g 7 Apr 2014

Если в дистрибутиве поддерживается OpenSSL, вы, вероятно, не сможете определить версию OpenSSL из-за обратного исправления с использованием openssl команда или информация о пакете (например, apt-get, dpkg, yum или же rpm). Процесс обратного исправления, используемый большинством (всеми?) Дистрибутивами, использует только базовый номер версии (например, "1.0.1e"); и не включает эффективную версию безопасности (например, "1.0.1g").

У Супер пользователя есть открытый вопрос, чтобы определить эффективную версию безопасности для OpenSSL и других пакетов, когда пакеты возвращаются. К сожалению, нет полезных ответов (кроме как проверить сайт дистрибутива). См. Определить эффективную версию безопасности, когда сталкиваются с Backpatching?

Практическое правило: если вы когда-либо устанавливали одну из уязвимых версий и когда-либо запускали программы или службы, связанные с OpenSSL для поддержки TLS, то вы уязвимы.

Где я могу найти программу для проверки на уязвимость?

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

Как эта уязвимость смягчается?

Обновите версию до незащищенной и сбросьте или повторно защитите уязвимые данные. Как отмечено на сайте Heartbleed, соответствующие шаги ответа в широком смысле:

1. Патч уязвимых систем.
2. Восстановить новые закрытые ключи.
3. Отправьте новый CSR в свой CA.
4. Получите и установите новый подписанный сертификат.
5. Неправильные ключи сеанса и куки
6. Сбросить пароли и общие секреты
7. Отменить старые сертификаты.

Более подробный анализ и ответ см. В разделе Что должен делать оператор веб-сайта в отношении эксплойта Heartbleed OpenSSL? на бирже стеков безопасности.

Должен ли я быть обеспокоен тем, что мои ключи или другие личные данные были скомпрометированы? Какие еще побочные эффекты мне следует беспокоить?

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

Вскоре после того, как уязвимость была обнаружена, Cloudfare предложила проверить, можно ли на практике восстановить личный ключ сервера. В соревнованиях независимо друг от друга победили Федор Индутный и Илкка Маттила. Смотрите "Вызов из сердца".

Где я могу найти больше информации?

Ссылка на дамп, для тех, кто ищет более подробную информацию:

• OpenSSL SECADV 2014047
• CVE-2014-0160
• Heartbleed
• Объявление об Ubuntu
• Объявление RHEL
• Официальный анонс OpenSSL

Довольно подробный график событий раскрытия можно найти на графике раскрытия Heartbleed: кто знал, что и когда.

Если вы программист и интересуетесь различными хитростями программирования, такими как обнаружение атаки Heartbleed через OpenSSL msg_cb обратного вызова, затем см. рекомендации по безопасности OpenSSL 2014047.

Простое объяснение ошибки XKCD:

Ubuntu 12.04, 12.10 и 13.10

Ubuntu выпустила USN-2165-1, в котором говорится, что обновленные пакеты теперь доступны в архивах. Выполните следующие две команды, чтобы получить исправление.

sudo apt-get update
sudo apt-get upgrade

Ubuntu 14.04

Я загрузил пакет Debian, содержащий новую версию (1.0.1g), в PPA, который я настроил для этой цели. Эти три команды добавят мой PPA в вашу систему, обновят список доступных пакетов и обновят все:

sudo add-apt-repository ppa:george-edison55/openssl-heartbleed-fix
sudo apt-get update
sudo apt-get upgrade

_{Примечание: PPA также предоставляет пакеты для Ubuntu 12.04 и 13.10, на тот случай, если вы предпочитаете запустить новую версию (1.0.1g), а не просто использовать исправленные версии в архивах.}

Ubuntu 10.04

Это версия LTS, версия сервера все еще поддерживается и получает обновления безопасности. Но эта уязвимость не повлияла на пакет openssl стандартной установки ubuntu 10.04, потому что версия ниже 1.0.1.

Настольная версия достигла конца срока службы и нуждается в обновлении / переустановке.

Ubuntu 13.04 и другие устаревшие версии

У Ubuntu 13.04 был очень короткий цикл поддержки, который вы не могли ожидать. Он уже достиг конца жизни и больше не получает обновлений безопасности. Надо было давно модернизировать. Если это все еще кто-то использует, пожалуйста, обновите сейчас, либо с нуля, либо его можно обновить неразрушающим до 13.10, следуя этой простой процедуре: http://www.tecmint.com/upgrade-ubuntu-13-04-raring-ringtail-to-ubuntu-13-10-saucy-salamander/ После обновления система получает патч с сердечным кровом с 13.10.

Для всех других устаревших версий Ubuntu это означает, что в основном необходима новая установка.

Убедитесь, что патч был применен

По сути, беги openssl version -a и убедитесь, что дата сборки - 7 апреля 2014 года или позже, но смотрите больше здесь.

перезагружать

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

RedHat 6.5 и CentOS 6.5

Они уязвимы. В сообщении RedHat RHSA-2014-0376 говорится, что доступны исправленные библиотеки, и любой пострадавший должен выполнить обновление при первой же возможности.

На момент написания этой статьи у CentOS еще не было фиксированной версии, но публикация Каранбира Сингха в CentOS-announce говорит, что они выпустили обновленную версию openssl (openssl-1.0.1e-16.el6_5.4.0.1 обратите внимание на последние четыре цифры, которые важны), для которых отключена эксплуатируемая команда TLS, и которую можно безопасно применять, поскольку она будет перезаписана фиксированной версией, когда она в конечном итоге будет выпущена.

Временно исправленная версия, похоже, еще не попала на все зеркала, но находится в главном хранилище по адресу http://mirror.centos.org/centos/6/updates/x86_64/Packages/ (и аналогично для i686).

Редактировать: как говорит Иэн, теперь, кажется, есть полностью исправленная версия для C6.5, и она, кажется, торопливо развернулась вокруг зеркал. Прямо yum update получил его для моих серверов; его openssl-1.0.1e-16.el6_5.7,

Версии RH6 и C6 до 6.5

Они не уязвимы. Согласно этой рекомендации от Red Hat,

Эта проблема не затрагивала версии openssl, поставляемые с Red Hat Enterprise Linux 5 и Red Hat Enterprise Linux 6.4 и более ранними версиями.

Публикация Каранбира Сингха в CentOS-анонсе в равной степени очевидна в отношении версий:

Ранее сегодня мы узнали о серьезной проблеме в openssl, поставляемой в CentOS-6.5.

Debian Wheezy

Debian выполнил DSA-2896-1, и исправленные библиотеки доступны здесь. Сценарий оболочки доступен здесь.

1. Патч

Репозиторий Apt-get был обновлен, поэтому теперь исправленные библиотеки доступны через apt-get update && apt-get upgrade

apt-get upgrade libssl1.0.0 openssl

В качестве альтернативы (не рекомендуется) пакеты могут быть обновлены вручную:

wget http://security.debian.org/pool/updates/main/o/openssl/libssl1.0.0-dbg_1.0.1e-2+deb7u5_amd64.deb
wget http://security.debian.org/pool/updates/main/o/openssl/openssl_1.0.1e-2+deb7u5_amd64.deb
wget http://security.debian.org/pool/updates/main/o/openssl/libssl1.0.0_1.0.1e-2+deb7u5_amd64.deb
wget http://security.debian.org/pool/updates/main/o/openssl/libssl-dev_1.0.1e-2+deb7u5_amd64.deb

dpkg -i openssl_1.0.1e-2+deb7u5_amd64.deb
dpkg -i libssl1.0.0_1.0.1e-2+deb7u5_amd64.deb
dpkg -i libssl1.0.0-dbg_1.0.1e-2+deb7u5_amd64.deb
dpkg -i libssl-dev_1.0.1e-2+deb7u5_amd64.deb

2. Перезагрузите сервер / сервисы

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

3. Проверьте версию OpenSSL

love@server:~$ openssl version
OpenSSL 1.0.1e 11 Feb 2013
love@server:~$ dpkg -l libssl1.0.0
||/ Name                    Version          Architecture     Description
+++-=======================-================-================-====================================================
ii  libssl1.0.0                 1.0.1e-2+deb7u6  amd64            SSL shared libraries

FreeBSD 10.0 или openssl из портов

Команда безопасности FreeBSD выпустила рекомендацию относительно CVE-2014-0160 (он же "Heartbleed") и: FreeBSD-SA-14: 06.openssl

1. Обновление FreeBSD

   • Обновление FreeBSD через бинарный патч

     Системы с RELEASE-версией FreeBSD на платформах i386 или amd64 могут быть обновлены с помощью утилиты freebsd-update(8):

     # freebsd-update fetch
     # freebsd-update install
     

   • Обновление FreeBSD из исходников

     1. Загрузите соответствующий патч из расположенного ниже расположения и проверьте отсоединенную подпись PGP, используя вашу утилиту PGP.

        # fetch http://security.FreeBSD.org/patches/SA-14:06/openssl-10.patch
        # fetch http://security.FreeBSD.org/patches/SA-14:06/openssl-10.patch.asc
        # gpg --verify openssl-10.patch.asc
        

     2. Выполните следующие команды как root:

        # cd /usr/src
        # patch < /path/to/patch
        

     3. Перекомпилируйте операционную систему

        используя buildworld и installworld, как описано в руководстве FreeBSD.

2. Обновите порт openssl с минимальной версией 1.0.1_10

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

4. Действуйте так, как будто ваша система была взломана, переиздайте все ваши ssl-ключи и / или сертификаты и потенциально утечку информации (см. Более общий ответ EEAA).

FreeBSD 9.x и FreeBSD 8.x

Эти системы по умолчанию не подвержены проблеме Heartbleed, так как полагаются на более старую версию библиотеки openssl 0.9.x, если вы не установили openssl из портов (см. Выше).

Если эти системы не уязвимы для проблемы Heartbleed, возможно, было бы разумно обновить вашу систему скорее раньше, чем позже, из-за другой локальной уязвимости (см. FreeBSD-SA-14: 06.openssl и раздел "FreeBSD 10.0" наверху):

Локальный злоумышленник может отслеживать процесс подписания и может восстановить ключ подписи. [CVE-2014-0076]

Примечание:

В оригинальном сообщении Heartbleed FreeBSD 8.4 и 9.1 перечислены как потенциально уязвимые. Это не так из-за отсутствия расширения Heartbeat (по умолчанию библиотека OpenBSL FreeBSD версии 0.9.x).

Я хотел бы отметить, что закрытые ключи - не единственные активы, которые следует считать скомпрометированными. Ошибка может привести к утечке любой памяти, работающей в том же адресном пространстве (т. Е. В том же процессе), что и OpenSSL. Поэтому, если вы запускаете серверный процесс, где уязвимая версия OpenSSL статически или динамически связана, любая часть информации, которую этот процесс когда-либо обрабатывал, включая пароли, номера кредитных карт и другие личные данные, должна рассматриваться как потенциально скомпрометированная.

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

Я собрал небольшую виртуальную машину, которая будет проверять произвольные хосты и порты с помощью тестового модуля FiloSottile. На предварительный взгляд код выглядит здоровым.

Выпуск готовой ВМ находится здесь. Это в формате VMX.

Слова предупреждения

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

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

Amazon Linux (дистрибутив Linux используется в Amazon EC2)

https://aws.amazon.com/amazon-linux-ami/security-bulletins/ALAS-2014-320/

Обзор проблемы: Обнаружена пропущенная проверка границ в том, как OpenSSL обрабатывает пакеты расширения пульса TLS. Этот недостаток можно использовать для обнаружения до 64 КБ памяти от подключенного клиента или сервера.

Затронутые версии: любой Amazon Linux AMI, на котором установлен openssl 1.0.1, любой Amazon Linux AMI 2013.03 или более поздней версии и любой Amazon Linux AMI, обновленный до 2013.03 или более поздней версии. OpenSSL по умолчанию устанавливается на Amazon Linux AMI.

Затронутые пакеты: openssl

Исправление проблемы: Запустите yum update openssl, чтобы обновить вашу систему. После установки нового пакета необходимо либо вручную перезапустить все службы, использующие openssl, либо перезагрузить ваш экземпляр. Хотя новый пакет все еще называется openssl-1.0.1e, он содержит исправление для CVE-2014-0160.

Новые пакеты: i686:

openssl-1.0.1e-37.66.amzn1.i686

openssl-static-1.0.1e-37.66.amzn1.i686

openssl-perl-1.0.1e-37.66.amzn1.i686

openssl-devel-1.0.1e-37.66.amzn1.i686

openssl-debuginfo-1.0.1e-37.66.amzn1.i686

x86_64:

openssl-devel-1.0.1e-37.66.amzn1.x86_64

openssl-1.0.1e-37.66.amzn1.x86_64

openssl-debuginfo-1.0.1e-37.66.amzn1.x86_64

openssl-perl-1.0.1e-37.66.amzn1.x86_64

openssl-static-1.0.1e-37.66.amzn1.x86_64