Как исправить ошибку Heartbleed (CVE-2014-0160) в OpenSSL?

На сегодняшний день в ошибка в OpenSSL было обнаружено, что это влияет на версии 1.0.1 через 1.0.1f (включительно) и 1.0.2-beta.

Начиная с Ubuntu 12.04, мы все уязвимы для этой ошибки. Чтобы исправить эту уязвимость, затронутые пользователи должны обновиться до OpenSSL 1.0.1g.

Как каждый затронутый пользователь может применить это обновление сейчас?

Обновления для системы безопасности доступны для 12.04, 12.10, 13.10 и 14.04 видеть Уведомление о безопасности Ubuntu USN-2165-1.

Поэтому сначала вам нужно применить доступные обновления для системы безопасности, например, выполнив

sudo apt-get updatesudo apt-get upgrade

из командной строки.

Не забудьте перезапуск службы (HTTP, SMTP и т.д.), Которые используют уязвимую версию OpenSSL, в противном случае вы все еще уязвимы. Смотрите также Сердечное кровотечение: Что это такое и какие есть варианты его смягчения? на Serverfault.com .

Следующая команда показывает (после обновления) все службы, которые необходимо перезапустить:

sudo find /proc -maxdepth 2 -name maps -exec grep -HE '/libssl\.so.* \(deleted\)' {} \; | cut -d/ -f3 | sort -u | xargs --no-run-if-empty ps uwwp

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

Ошибка известна как Кровоточащее сердце.

Уязвим ли я?

Как правило, это влияет на вас, если вы запускаете какой-то сервер, для которого в какой-то момент сгенерировали ключ SSL. Большинство конечных пользователей не затронуты (напрямую); по крайней мере, Firefox и Chrome не используют OpenSSL. SSH не затрагивается. На распространение пакетов Ubuntu это не влияет (оно зависит от подписей GPG).

Вы уязвимы, если запускаете любой сервер, использующий OpenSSL версий 1.0–1.0.1f (за исключением, конечно, версий, которые были исправлены с момента обнаружения ошибки). Затронутые версии Ubuntu - это предварительные версии с 11.10 oneiric по 14.04 trusted. Это ошибка реализации, а не недостаток протокола, поэтому затронуты только программы, использующие библиотеку OpenSSL. Если у вас есть программа, связанная со старой версией OpenSSL 0.9.x, это не повлияет на нее. Затрагиваются только программы, использующие библиотеку OpenSSL для реализации протокола SSL; программы, использующие OpenSSL для других целей, не затрагиваются.

Если вы запустили уязвимый сервер, подключенный к Интернету, считайте его скомпрометированным, если только в ваших журналах не указано отсутствие подключения с момента объявления 2014-04-07. (Это предполагает, что уязвимость не была использована до ее объявления.) Если ваш сервер был открыт только внутренне, необходимость изменения ключей будет зависеть от того, какие другие меры безопасности приняты.

Каково это воздействие?

Ошибка позволяет любой клиент который может подключиться к вашему SSL-серверу, чтобы получить с сервера около 64 КБ памяти. Клиенту не нужно каким-либо образом проходить аутентификацию. Повторяя атаку, клиент может сбрасывать различные части памяти в последовательных попытках.

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

Как мне восстановить данные на сервере?

  1. Отключите все затронутые серверы. Пока они работают, они потенциально могут привести к утечке важных данных.

  2. Обновите libssl1.0.0 пакет, и убедитесь, что все затронутые серверы перезапущены.
    Вы можете проверить, все ли затронутые процессы все еще запущены с помощью `grep "libssl.(исключено)' /proc//карты`

  3. Генерировать новые ключи. Это необходимо, поскольку ошибка могла позволить злоумышленнику получить старый закрытый ключ. Выполните ту же процедуру, которую вы использовали изначально.

    • Если вы используете сертификаты, подписанные центром сертификации, отправьте свои новые открытые ключи в свой центр сертификации. Когда вы получите новый сертификат, установите его на свой сервер.
    • Если вы используете самозаверяющие сертификаты, установите их на свой сервер.
    • В любом случае, уберите старые ключи и сертификаты с дороги (но не удаляйте их, просто убедитесь, что они больше не используются).
  4. Теперь, когда у вас есть новые бескомпромиссные ключи, вы можете верните свой сервер в рабочее состояние.

  5. Отменять старые сертификаты.

  6. Оценка ущерба: любые данные, которые находились в памяти процесса, обслуживающего SSL-соединения, потенциально могут быть утечены. Это может включать пароли пользователей и другие конфиденциальные данные. Вам нужно оценить, какими могли быть эти данные.

    • Если вы используете службу, которая позволяет проводить аутентификацию по паролю, то пароли пользователей, подключившихся незадолго до того, как было объявлено об уязвимости, следует считать скомпрометированными. (Немного раньше, потому что пароль, возможно, некоторое время оставался неиспользованным в памяти.) Проверьте свои журналы и измените пароли любого затронутого пользователя.
    • Также аннулируйте все сеансовые файлы cookie, так как они могли быть скомпрометированы.
    • Клиентские сертификаты не скомпрометированы.
    • Любые данные, которыми обменивались незадолго до появления уязвимости, могли остаться в памяти сервера и поэтому могли попасть к злоумышленнику.
    • Если кто-то записал старое SSL-соединение и получил ключи вашего сервера, теперь он может расшифровать их расшифровку. (Если только ПФС было обеспечено — если вы не знаете, то этого не было.)

Как мне восстановить данные на клиенте?

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

  • Клиентская программа использовала ошибочную версию библиотеки OpenSSL для реализации протокола SSL.
  • Клиент подключился к вредоносному серверу. (Так, например, если вы подключились к поставщику электронной почты, это не вызывает беспокойства.) Это должно было произойти после того, как владельцу сервера стало известно об уязвимости, то есть предположительно после 2014-04-07.
  • Клиентский процесс имел конфиденциальные данные в памяти, которые не были переданы серверу. (Так что, если вы просто побежали wget чтобы загрузить файл, не было никаких данных для утечки.)

Если вы сделали это между 2014-04-07 вечером по Гринвичу и обновлением вашей библиотеки OpenSSL, считайте, что любые данные, которые находились в памяти клиентского процесса, были скомпрометированы.

Рекомендации

Чтобы узнать, какая версия OpenSSL установлена в Ubuntu, запустите:

dpkg -l | grep openssl

Если вы видите следующие выходные данные версии, патч для CVE-2014-0160 должен быть включен.

ii  openssl      1.0.1-4ubuntu5.12      Secure Socket Layer (SSL)...

Глядя на https://launchpad.net/ubuntu /+источник/openssl/1.0.1-4ubuntu5.12, он показывает , какие ошибки исправлены:

... SECURITY UPDATE: memory disclosure in TLS heartbeat extension    - debian/patches/CVE-2014-0160.patch: use correct lengths in      ssl/d1_both.c, ssl/t1_lib.c.    - CVE-2014-0160 -- Marc Deslauriers <email address hidden>   Mon, 07 Apr 2014 15:45:14 -0400...

Если ваш apt-получить репозитории не содержит никаких предварительно скомпилированных 1.0.1g OpenSSL версии, поэтому просто скачайте исходные тексты с официального сайта и скомпилируйте их.

Ниже находится единственная командная строка для компиляции и установки последней версии openssl.

curl https://www.openssl.org/source/openssl-1.0.1g.tar.gz | tar xz && cd openssl-1.0.1g && sudo ./config && sudo make && sudo make install

Замените старый двоичный файл openssl новым с помощью символической ссылки.

sudo ln -sf /usr/local/ssl/bin/openssl `which openssl`

Вы все хороши!

# openssl version should returnopenssl versionOpenSSL 1.0.1g 7 Apr 2014

См. это запись в блоге.

nb: Как указано в сообщении в блоге, это обходное решение не исправит "сервер Nginx и Apache, которые необходимо перекомпилировать с исходными кодами OpenSSL 1.0.1g".

Для тех, кто не хочет выполнять обновление пакета на уровне сервера. Сегодня я прочитал кучу этих руководств и apt-get upgrade openssl === apt-get upgrade при этом будут применены все исправления безопасности, требуемые вашим компьютером. Замечательно, если только вы явно не опираетесь где-то на старую версию пакета.

Это минимальное действие, необходимое для Ubuntu 12.04 LTS под управлением Apache 2:

  • Идти к этот адрес и докажите, что у вас есть уязвимость. Вы должны использовать ПРЯМОЙ ВНЕШНИЙ АДРЕС ВАШЕГО ВЕБ-СЕРВЕРА. Если вы используете балансировщик нагрузки (например, ELB), возможно, вы не связываетесь напрямую со своим веб-сервером.

  • Выполните следующие действия 1, чтобы обновить пакеты и перезагрузить компьютер. Да, я видел, что во всех руководствах говорится, что у вас должна быть временная метка позже 4 апреля 2014 года, но мне кажется, что это не так.

    apt-get update && apt-get install openssl libssl1.0.0 && /etc/init.d/перезапуск apache2

  • Убедитесь, что у вас установлены соответствующие версии пакетов, и еще раз проверьте свой веб-сервер на наличие уязвимости.

Ключевые пакеты следующие, я определил эту информацию с помощью приведенной ниже команды, а затем отредактировал cruft (вам не нужно так много знать о состоянии моих машин).

$ dpkg -l | grep sslii  libssl-dev                       1.0.1-4ubuntu5.12          SSL development libraries, header files and documentationii  libssl1.0.0                      1.0.1-4ubuntu5.12          SSL shared librariesii  openssl                          1.0.1-4ubuntu5.12          Secure Socket Layer (SSL)* binary and related cryptographic tools

1.0.1-4ubuntu5.12 не должно содержать уязвимости. Убедитесь, что это так, снова перейдя на веб-сайт ниже и протестировав свой веб-сервер.

http://filippo.io/Heartbleed/

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

Вы должны убедиться, что у вас нет пакетов на удержании, таких как libssl.

:~$ sudo apt-get upgrade -VReading package lists... DoneBuilding dependency treeReading state information... DoneThe following packages have been kept back:  libssl-dev (1.0.1-4ubuntu5.10 => 1.0.1-4ubuntu5.12)  libssl1.0.0 (1.0.1-4ubuntu5.10 => 1.0.1-4ubuntu5.12)  linux-image-virtual (3.2.0.31.34 => 3.2.0.60.71)  linux-virtual (3.2.0.31.34 => 3.2.0.60.71)0 upgraded, 0 newly installed, 0 to remove and 4 not upgraded.

Чтобы обновить эти apt-mark unhold libssl1.0.0 (например). Затем обновите: apt-get upgrade -V. Затем перезапустите затронутые службы.

@Mat Я не знаю, что тестирует этот сайт, но, возможно, он обнаруживает, что вы используете старый ключ. Поскольку ключ, возможно, просочился, вам необходимо его восстановить.

Вы действительно не хотите обновлять OpenSSL до новых версий оптом, это невероятная боль. Гораздо проще просто установить обновленный пакет, который исправляет проблему: USN-2165-1: OpenSSL vulnerabilities | Ubuntu security notices | Ubuntu

Есть ли у вас затронутая версия openssl?

У меня есть исправленная версия 1.0.1-4ubuntu5.12, и я перезапустил службу apache
, но http://filippo.io/Heartbleed / тестирование на моем сайте по-прежнему говорит, что я уязвим, есть идеи, почему?

вы перезапустили свои службы после обновления?