Это канонический вопрос о понимании и устранении проблемы безопасности Heartbleed.
Что такое CVE-2014-0160 АКА "Heartbleed"? В чем причина, какие ОС и версии OpenSSL уязвимы, каковы симптомы, существуют ли какие-либо методы для обнаружения успешного эксплойта?
Как я могу проверить, не повреждена ли моя система? Как можно устранить эту уязвимость? Должен ли я быть обеспокоен тем, что мои ключи или другие личные данные были скомпрометированы? Какие еще побочные эффекты мне следует беспокоить?
security
openssl
heartbleed
Иаков
источник
источник
Ответы:
Во-первых , прежде чем волноваться, убедитесь, что вы понимаете, действительно ли эта уязвимость применима к вам. Если у вас есть сервер, но на самом деле никогда не было приложений, использующих TLS, то это не является приоритетной задачей для вас. Если, с другой стороны, у вас когда-либо были приложения с поддержкой TLS, тогда вас ждет угощение. Читать дальше:
Это большой беспорядок, вот что это такое. Короче говоря, в 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 1.0.1 до 1.0.1f.
Это страшная часть. Насколько нам известно, не существует известного способа определить, была ли эта уязвимость использована. Теоретически возможно, что в ближайшее время будут выпущены сигнатуры IDS, которые могут обнаружить этот эксплойт, но на момент написания они недоступны.
Существуют свидетельства того, что Heartbleed активно эксплуатировался в условиях дикой природы уже в ноябре 2013 года. См. EFF Wild in the Heart: были ли разведывательные агентства, использующие Heartbleed в ноябре 2013 года? И Bloomberg сообщает, что АНБ применило эксплойт вскоре после того, как была обнаружена уязвимость. Посмотрите, что АНБ сказал, что эксплуатирует ошибку Heartbleed для разведки в течение многих лет . Однако разведывательное сообщество США отрицает претензии Bloomberg. Смотрите IC на записи .
Если вы поддерживаете OpenSSL в своей системе, вы можете просто выполнить
openssl version
:Если распределение поддерживает OpenSSL, то вы , вероятно , не может определить версию OpenSSL из - за спины Patching с помощью
openssl
команды или информацию о пакете (например,apt-get
,dpkg
,yum
илиrpm
). Процесс обратного исправления, используемый большинством (всеми?) Дистрибутивами, использует только базовый номер версии (например, «1.0.1e»); и не включает эффективную версию безопасности (например, «1.0.1g»).У Супер пользователя есть открытый вопрос, чтобы определить эффективную версию безопасности для OpenSSL и других пакетов, когда пакеты возвращаются. К сожалению, нет полезных ответов (кроме как проверить сайт дистрибутива). См. Определить эффективную версию безопасности, когда сталкиваются с Backpatching ?
Практическое правило: если вы когда-либо устанавливали одну из уязвимых версий и когда-либо запускали программы или службы, связанные с OpenSSL для поддержки TLS, то вы уязвимы.
В течение нескольких часов после объявления Heartbleed несколько человек в Интернете опубликовали общедоступные веб-приложения, которые предположительно можно было использовать для проверки сервера на наличие этой уязвимости. На момент написания этой статьи я не рассматривал ни одного из них, поэтому я не буду больше публиковать их заявки. Их можно относительно легко найти с помощью предпочитаемой вами поисковой системы.
Обновите версию до незащищенной и сбросьте или повторно защитите уязвимые данные. Как отмечено на сайте Heartbleed , соответствующие шаги ответа в широком смысле:
Более подробный анализ и ответ см. В разделе Что должен делать оператор веб-сайта в отношении эксплойта Heartbleed OpenSSL? на бирже стека безопасности.
Абсолютно. Системные администраторы должны предположить, что их серверы, которые использовали уязвимые версии OpenSSL, действительно скомпрометированы и реагируют соответствующим образом.
Вскоре после того, как уязвимость была обнаружена, Cloudfare предложила проверить, можно ли на практике восстановить личный ключ сервера. В соревнованиях независимо друг от друга победили Федор Индутный и Илкка Маттила. См. «Вызов из сердца» .
Ссылка дамп, для тех, кто ищет более подробную информацию:
Довольно подробный график событий раскрытия можно найти на графике раскрытия Heartbleed: кто знал, что и когда .
Если вы программист и интересуетесь различными хитростями программирования, такими как обнаружение атаки Heartbleed с помощью
msg_cb
обратного вызова OpenSSL , см. Рекомендацию по безопасности OpenSSL 2014047 .источник
Простое объяснение ошибки XKCD:
источник
Ubuntu 12.04, 12.10 и 13.10
Ubuntu выпустила USN-2165-1 , в котором говорится, что обновленные пакеты теперь доступны в архивах. Выполните следующие две команды, чтобы получить исправление.
Ubuntu 14.04
Я загрузил пакет Debian, содержащий новую версию (1.0.1g), в PPA, который я настроил для этой цели. Эти три команды добавят мой PPA в вашу систему, обновят список доступных пакетов и обновят все:
Примечание: 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, перезапущены, - это перезагрузить компьютер .
источник
Mon Apr 7 20:31:55 UTC 2014
).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 ,
Публикация Каранбира Сингха в CentOS-анонсе в равной степени очевидна в отношении версий:
источник
Debian Wheezy
Debian выполнил DSA-2896-1, и исправленные библиотеки доступны здесь . Сценарий оболочки доступен здесь .
1. Патч
Репозиторий Apt-get был обновлен, поэтому теперь исправленные библиотеки доступны через
apt-get update && apt-get upgrade
В качестве альтернативы (не рекомендуется) пакеты могут быть обновлены вручную:
2. Перезагрузите сервер / сервисы
Для лучшей защиты перезапустите весь сервер или, если сервер не может быть отключен, перезапустите необходимые службы.
3. Проверьте версию OpenSSL
источник
wheezy/security
то с вами все будет хорошоapt-get update && apt-get upgrade
. Или использовать интерактивный менеджер пакетов только обновить пакетыopenssl
,libssl1.0.0
,libssl1.0.0-dbg
иlibssl-dev
(как установлено в вашей системе).OpenSSL 1.0.1e 11 Feb 2013
как патч называется 1.0.1e-2. Вы можете проверить,dpkg -l openssl
и он должен показать версию1.0.1e-2+deb7u6
Я хотел бы отметить, что закрытые ключи - не единственные активы, которые следует считать скомпрометированными. Ошибка может привести к утечке любой памяти, работающей в том же адресном пространстве (т. Е. В том же процессе), что и OpenSSL. Поэтому, если вы запускаете серверный процесс, в котором уязвимая версия OpenSSL статически или динамически связана, любая часть информации, которую этот процесс когда-либо обрабатывал , включая пароли, номера кредитных карт и другие личные данные, должна считаться потенциально скомпрометированной.
источник
FreeBSD 10.0 или openssl из портов
Команда безопасности FreeBSD выпустила рекомендацию относительно CVE-2014-0160 (он же «Heartbleed») и: FreeBSD-SA-14: 06.openssl
Обновление FreeBSD
Обновление FreeBSD через бинарный патч
Системы с RELEASE-версией FreeBSD на платформах i386 или amd64 могут быть обновлены с помощью утилиты freebsd-update (8):
Обновление FreeBSD из исходников
Загрузите соответствующий патч из расположенного ниже расположения и проверьте отсоединенную подпись PGP, используя вашу утилиту PGP.
Выполните следующие команды как root:
Перекомпилируйте операционную систему
используя компиляция системы и installworld , как описано в Руководстве FreeBSD .
Обновите порт openssl с минимальной версией 1.0.1_10
Перезапустите все демоны, используя библиотеку, или перезагрузите систему
Действуйте так, как будто ваша система была взломана, переиздайте все ваши ssl-ключи и / или сертификаты и потенциально утечку информации (см. Более общий ответ EEAA ).
FreeBSD 9.x и FreeBSD 8.x
Эти системы являются не уязвимы к Heartbleed вопроса по умолчанию, как и полагается на старой версии 0.9.x из OpenSSL библиотеки, если вы не установили OpenSSL из портов (см наверх).
Если эти системы не уязвимы для проблемы Heartbleed , возможно, было бы разумно обновить вашу систему скорее раньше, чем позже, из-за другой локальной уязвимости (см. FreeBSD-SA-14: 06.openssl и раздел «FreeBSD 10.0» вверху ):
Примечание :
В оригинальном сообщении Heartbleed FreeBSD 8.4 и 9.1 перечислены как потенциально уязвимые. Это не так из-за отсутствия расширения Heartbeat (по умолчанию библиотека OpenBSL FreeBSD версии 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 КБ памяти от подключенного клиента или сервера.
Затронутые версии: любой 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:
x86_64:
источник