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 / После обновления система получает патч heartbleed от 13.10.

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

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

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

Перезагрузка

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

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

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

Релиз завершенной ВМ находится здесь . Это в формате VMX.

Предупреждающие слова

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

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 получило его для моих серверов; это openssl-1.0.1e-16.el6_5.7 .

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

Они не уязвимы. Согласно это сообщение от Red Hat ,

Эта проблема не затрагивала версии openssl, поставляемые с Red s openssl-1.0.1e-16.el6_5.7 .

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

Они не уязвимы. Согласно это сообщение от Red Hat ,

Эта проблема не затрагивала версии openssl, поставляемые с Red s 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-announce столь же ясно касается управления версиями:

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

Сначала , прежде чем волноваться, убедитесь, что вы понимаете, действительно ли не эта уязвимость действительно относится к вам. Если у вас есть сервер, но у вас никогда не было приложений, использующих 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 или об / мин ). Процесс обратного исправления, используемый большинством (всеми?) Дистрибутивами, использует только базовый номер версии (например, «1.0.1e»); и не включает эффективную версию безопасности (например, «1.0.1g»).

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

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

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

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

Как можно уменьшить эту уязвимость?

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

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

Для более подробного анализа и ответа см. Что следует делать оператору веб-сайта с Эксплойт Heartbleed OpenSSL? в Security Stack Exchange.

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

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

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

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

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

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

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