Это Канонический вопрос о понимании и устранении проблемы безопасности Heartbleed.
Что такое CVE-2014-0160 AKA Heartbleed? В чем причина, какие ОС и версии OpenSSL уязвимы, каковы симптомы, есть ли какие-либо методы для обнаружения успешного эксплойта?
Как я могу проверить, не затронута ли моя система? Как можно уменьшить эту уязвимость? Следует ли мне беспокоиться о том, что мои ключи или другие личные данные были скомпрометированы? Какие еще побочные эффекты меня должны беспокоить?
Первый, прежде чем волноваться, убедитесь, что вы понимаете, действительно ли эта уязвимость применима к вам. Если у вас есть сервер, но у вас никогда не было приложений, использующих TLS, то это не самая важная вещь, которую вам нужно исправлять. Если, с другой стороны, вы когда-либо имел Приложения с поддержкой TLS, тогда вас ждет угощение. Читай дальше:
Что такое CVE-2014-0160, также известная как Heartbleed?
Это ужасный беспорядок, вот что это такое. Короче говоря, в версиях OpenSSL с 1.0.1 по 1.0.1f была обнаружена уязвимость, с помощью которой злоумышленник может читать определенные части системной памяти. Те части, которые содержат конфиденциальные данные, такие как закрытые ключи, предварительные ключи, пароли и ценные корпоративные данные, среди прочего.
Ошибка была независимо обнаружена Нилом Мехтой из Google Security (21 марта 2014 г.) и финской фирмой по тестированию ИТ-безопасности Codenomicon (2 апреля 2014 г.).
В чем причина?
Что ж, ошибочный код в OpenSSL. Вот коммит, который привел к уязвимости, и Вот коммит, исправивший уязвимость. Ошибка появилась в декабре 2011 года и была исправлена сегодня, 7 апреля 2014 года.
Ошибка также может рассматриваться как симптом более серьезной проблемы. Две связанные проблемы: (1) какой процесс используется, чтобы гарантировать, что ошибочный код не вводится в базу кода, и (2) почему протоколы и расширения настолько сложны и трудны для тестирования. Пункт (1) - это проблема управления и процесса в OpenSSL и многих других проектах. Многие разработчики просто сопротивляются таким методам, как проверка кода, анализ и сканирование. Пункт (2) обсуждается в рабочей группе TLS IETF. Видеть Heartbleed / сложность протокола.
Был ли злонамеренно вставлен ошибочный код?
Я не буду рассуждать о том, действительно ли это была ошибка или, возможно, от имени злоумышленника был добавлен фрагмент кода. Однако человек, разработавший код для OpenSSL, утверждает, что это было случайно. Видеть Человек, обнаруживший серьезную брешь в системе безопасности Heartbleed, отрицает, что ввел ее намеренно.
Какие ОС и версии OpenSSL уязвимы?
Как упоминалось выше, любая используемая операционная система или приложение, связанное с OpenSSL 1.0.1–1.0.1f.
Каковы симптомы, есть ли какие-либо методы обнаружения успешного эксплойта?
Это самое страшное. Насколько нам известно, нет известного способа определить, была ли использована эта уязвимость. Теоретически возможно, что вскоре будут выпущены сигнатуры IDS, которые могут обнаружить этот эксплойт, но на момент написания этой статьи они недоступны.
Есть свидетельства того, что Heartbleed активно эксплуатировалась в дикой природе еще в ноябре 2013 года. См. EFF. Дикие сердцем: использовали ли разведывательные агентства Heartbleed в ноябре 2013 года? И Bloomberg сообщает, что АНБ использовало эксплойт в качестве оружия вскоре после появления уязвимости. Видеть АНБ обещало использовать Heartbleed Bug для разведки в течение многих лет. Однако разведывательное сообщество США опровергает утверждения 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 и других пакетов при обратном обновлении пакетов. К сожалению, полезных ответов нет (кроме проверки на сайте дистрибутива). Видеть Определите эффективную версию безопасности, когда столкнулись с обратным патчем?
Практическое правило: если вы когда-либо устанавливали одну из уязвимых версий и когда-либо запускали программы или службы, связанные с OpenSSL для поддержки TLS, то вы уязвимы.
Где найти программу для проверки уязвимости?
Через несколько часов после объявления Heartbleed несколько человек в Интернете опубликовали общедоступные веб-приложения, которые предположительно можно было использовать для проверки сервера на наличие этой уязвимости. На момент написания этой статьи я не просматривал ни одного из них, поэтому я не буду публиковать их приложения. Их можно относительно легко найти с помощью предпочитаемой вами поисковой системы.
Как уменьшить эту уязвимость?
Выполните обновление до неуязвимой версии и сбросьте или повторно защитите уязвимые данные. Как отмечено на Heartbleed сайта, соответствующие меры реагирования в целом следующие:
Для более подробного анализа и ответа см. Что должен делать оператор веб-сайта с эксплойтом Heartbleed OpenSSL? на бирже Security Stack Exchange.
Следует ли мне беспокоиться о том, что мои ключи или другие личные данные были скомпрометированы? Какие еще побочные эффекты меня должны беспокоить?
Абсолютно. Системным администраторам необходимо предполагать что их серверы, которые использовали уязвимые версии OpenSSL, действительно скомпрометированы и реагируют соответственно.
Вскоре после того, как уязвимость была раскрыта, Cloudfare предложила проверить, можно ли восстановить закрытый ключ сервера на практике. Задачу независимо выиграли Федор Индутный и Илкка Маттила. Видеть Вызов Heartbleed.
Где я могу найти дополнительную информацию?
Дамп ссылок, для тех, кто ищет подробности:
Достаточно подробный график событий раскрытия информации можно найти на Хронология раскрытия информации Heartbleed: кто знал, что и когда.
Если вы программист и интересуетесь различными трюками программирования, такими как обнаружение атаки Heartbleed через OpenSSL msg_cb
обратный вызов, затем см. OpenSSL Сообщение по безопасности 2014047.
Простое объяснение ошибки от XKCD:
Ubuntu выпустила USN-2165-1, в котором указано, что обновленные пакеты теперь доступны в архивах. Выполните следующие две команды, чтобы получить исправление.
sudo apt-get update
sudo apt-get upgrade
Я загрузил пакет 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) вместо того, чтобы просто использовать исправленные версии в архивах.
Это LTS-версия, серверная версия все еще поддерживается и получает обновления безопасности. Но эта уязвимость не повлияла на пакет openssl стандартной установки ubuntu 10.04, так как версия ниже 1.0.1.
Срок службы настольной версии подошел к концу, и ее необходимо обновить / переустановить.
У Ubuntu 13.04 был очень короткий цикл поддержки, чего вы не могли ожидать. Срок его службы уже истек, и он больше не получает обновлений безопасности. Его давно надо было модернизировать. Если кто-то все еще использует его, обновите его сейчас, либо с нуля, либо его можно без разрушения обновить до 13.10, выполнив эту простую процедуру: http://www.tecmint.com/upgrade-ubuntu-13-04-raring-ringtail-to-ubuntu-13-10-saucy-salamander/ После обновления система получает патч heartbleed от 13.10.
Для всех других устаревших версий ubuntu это означает, что в основном необходима новая установка.
По сути, запустите openssl version -a
и убедитесь, что дата сборки - 7 апреля 2014 г. или позже, но см. Вот.
Лучший способ убедиться, что все службы, зависящие от OpenSSL, перезапущены, - это перезагрузка.
Они уязвимы. Ошибка RedHat RHSA-2014-0376 говорит, что доступны исправленные библиотеки, и всем, кого это касается, следует выполнить обновление при первой возможности.
На момент написания у CentOS еще не было фиксированной версии, но Сообщение Карабира Сингха в CentOS-анонс говорит, что они выпустили обновленную версию 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
.
Они не уязвимы. В соответствии с этот совет от Red Hat,
Эта проблема не коснулась версий openssl, поставляемых с Red Hat Enterprise Linux 5 и Red Hat Enterprise Linux 6.4 и ранее.
Сообщение Карабира Сингха в CentOS-анонс одинаково ясно и о версиях:
Сегодня в тот же день мы узнали о серьезной проблеме в openssl, поставляемой в CentOS-6.5.
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
Хочу отметить, что закрытые ключи - не единственные активы, которые следует рассматривать как скомпрометированные. Ошибка может вытекать любой память, работающая в том же адресном пространстве (то есть в том же процессе), что и OpenSSL. Поэтому, если вы запускаете серверный процесс, в котором уязвимая версия OpenSSL статически или динамически связана, любая информация, которую когда-либо обрабатывал этот процесс, включая пароли, номера кредитных карт и другие личные данные, следует рассматривать как потенциально скомпрометированные.
В Команда безопасности FreeBSD выпустил уведомление относительно CVE-2014-0160 (также известного как Heartbleed) и: FreeBSD-SA-14: 06.openssl
Обновление FreeBSD
Обновление FreeBSD с помощью бинарного патча
Системы под управлением ВЫПУСКНАЯ версия FreeBSD на i386 или amd64 платформы можно обновить с помощью утилиты freebsd-update (8):
# freebsd-update fetch
# freebsd-update install
Обновление FreeBSD из исходников
Загрузите соответствующий патч из расположенного ниже места и проверьте отключенную подпись 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
Выполните следующие команды от имени пользователя root:
# cd /usr/src
# patch < /path/to/patch
Перекомпилируйте операционную систему
с помощью buildworld и installworld как описано в Справочник FreeBSD.
Обновите openssl порт с минимальной версией 1.0.1_10
Перезапустите все демоны, использующие библиотеку, или перезагрузите систему
Действуйте так, как если бы ваша система была взломана, повторно выпустите все ваши ssl-ключи и / или сертификаты и потенциально утекшую информацию (см. EEAA более общий ответ).
Эти системы не уязвим к Heartbleed проблема по умолчанию, поскольку полагается на более старую версию 0.9.x openssl библиотека, если только вы установили openssl из портов (см. наверху).
Если эти системы не уязвимы для Heartbleed проблема, может быть разумно обновить вашу систему раньше, чем позже из-за другого местный уязвимость (см. FreeBSD-SA-14: 06.openssl и раздел «FreeBSD 10.0» наверху):
Локальный злоумышленник может отследить процесс подписи и восстановить из него ключ подписи. [CVE-2014-0076]
Заметка:
Оригинал Heartbleed Консультативный список FreeBSD 8.4 и 9.1 как потенциально уязвимый. Это неверно из-за отсутствия Расширение сердцебиения (по умолчанию библиотека FreeBSD openssl имеет версию 0.9.x).
Я обнаружил, что практически невозможно определить версии SSL, используемые на некоторых устройствах, с которыми я работаю. Хотя технически это не смягчение последствий, возможность идентифицировать уязвимые в настоящее время хосты была в верхней части моего списка.
Я собрал небольшую виртуальную машину, которая будет выполнять проверку произвольных хостов и портов, используя Тестовый модуль FiloSottile. На первый взгляд код выглядит неплохо.
Выпуск готовой ВМ Вот. Это в формате VMX.
Слова предупреждения
Этот сценарий и ВМ будут только показать текущий статус ваших систем. Вполне возможно, что в какой-то момент в прошлом ваши системы находились в уязвимом состоянии и могли подвергнуться злоупотреблениям.
Что-то, что здесь обнаруживается, безусловно, является приоритетом для исправления, но это не избавьте вас от необходимости применять обновления и менять все ваши ключи.
Amazon Linux (дистрибутив Linux, используемый в Amazon EC2)
https://aws.amazon.com/amazon-linux-ami/security-bulletins/ALAS-2014-320/
Обзор проблемы: Проверка отсутствующих границ была обнаружена в способе обработки OpenSSL пакетов расширения пульса TLS. Этот недостаток может быть использован для выявления до 64 КБ памяти от подключенного клиента или сервера.
Затронутые версии: Любой AMI Amazon Linux, на котором установлен openssl 1.0.1, то есть любой AMI Amazon Linux 2013.03 или более поздней версии, а также любой AMI Amazon Linux, обновленный до 2013.03 или более поздней версии. OpenSSL по умолчанию установлен в AMI Amazon Linux.
Затронутые пакеты: 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