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

152

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

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

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

Lucio
источник
У вас есть уязвимая версия openssl?
Брайам
У меня есть исправленная версия 1.0.1-4ubuntu5.12, и я перезапустил службу apache, но тестирование filippo.io/Heartbleed на моем сайте все еще говорит, что я уязвим. Есть идеи, почему?
1
@ Не знаю, что тестирует этот сайт, но, возможно, он обнаружит, что вы используете старый ключ. Поскольку ключ, возможно, просочился, вам необходимо восстановить его.
Жиль
1
Вы действительно не хотите обновлять OpenSSL для оптовых продаж новых версий, это невероятная боль. Гораздо проще просто установить обновленный пакет, который исправляет проблему: ubuntu.com/usn/usn-2165-1
sarnold
Вы перезапустили свои услуги после обновления?
Аксель

Ответы:

141

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

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

sudo apt-get update
sudo apt-get upgrade

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

Не забудьте перезапустить службы (HTTP, SMTP и т. Д.), Которые используют уязвимую версию OpenSSL, в противном случае вы по-прежнему уязвимы. См. Также Heartbleed: что это такое и какие варианты можно смягчить? на 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-ключи , а затем оценить, возможно, произошла утечка ваших ключей, и в этом случае злоумышленники могли получить конфиденциальную информацию с ваших серверов.

Флориан Диш
источник
23
Не уверен, что это работает на Ubuntu 12.04.4 LTS. После полного обновления openssl versionдает OpenSSL 1.0.1 14 Mar 2012. Это не исправленная версия, верно? Или я не правильно понял?
Пол Кантрелл
7
Что делать с Ubuntu 13.04? Нет доступных обновленных openssl :-(
Frodik
20
На Ubuntu 12.04 даже исправленный OpenSSL отображает версию 1.0.1 14 Mar 2012. Прочтите ответ Crimi, чтобы узнать, входит ли в вашу установку исправление.
дан
7
Спасибо, @ дан! Резюмируя ответ @ crimi здесь: если вы бежите, dpkg -l | grep ' openssl 'и вы получите, 1.0.1-4ubuntu5.12то вы можете идти.
Пол Кантрелл
20
Исправления и перезапуска недостаточно. Вам необходимо регенерировать ключи и оценить, были ли утечены ваши ключи, а также другие конфиденциальные материалы. См. Например, означает ли Heartbleed новые сертификаты для каждого SSL-сервера?
Жиль
71

Ошибка известна как Heartbleed .

Я уязвим?

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

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

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

Какое влияние?

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

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

Как я могу восстановить на сервере?

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

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

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

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

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

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

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

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

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

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

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

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

жилль
источник
4
Я не верю, что "Только сторона сервера SSL / TLS-соединений затронута" верно. openssl.org/news/secadv_20140407.txt говорит, что может раскрыть секреты от клиента или сервера. ubuntu.com/usn/usn-2165-1 согласен. Вероятность использования клиентских сертификатов при подключении к вредоносному серверу невелика, но такая возможность существует.
armb
@armb Вы делаете хорошую мысль. Даже не имеет значения, используются ли клиентские сертификаты, утечка данных не связана с использованием сертификатов. Я заручился помощью профессионалов .
Жиль
Клиентские сертификаты - это тот случай, когда вы можете потерять приватные ключи, но да, пароли, куки авторизации и т. Д. Могут все равно утечь Однако при использовании клиента на основе OpenSSL, такого как curl или wget, при подключении к вредоносному серверу у вас не будет секретов для других сайтов в памяти, поэтому в этом случае я думаю, что единственная утечка будет, если вы передадите секреты клиента в ожидании передачи их на законный сайт, и Heartbleed утекла их во время рукопожатия, прежде чем проверка сертификата обнаружит, что вы не подключены к нужному сайту.
Арм
1
@Gilles Вас могут заинтересовать ответы на вопрос « Какие клиенты оказались уязвимыми для Heartbleed»? , Мне удалось получить «интересную» память на nginx (режим прокси), wget, ссылках и других.
Лекенштейн
1
@ MuhamedHuseinbašić Пакет opensslсодержит инструменты командной строки. Он не используется приложениями, которые используют библиотеку OpenSSL для реализации протокола SSL (например, Apache). Но вы должны просто применить обновления безопасности дистрибутива.
Жиль
40

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

dpkg -l | grep openssl

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

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

Глядя на https://launchpad.net/ubuntu/+source/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
...
Крими
источник
2
Я обновил и получил версию 5.12, но этот инструмент все еще говорит мне, что я уязвим filippo.io/Heartbleed Мысли?
Toxaq
3
Я проверил наши обновленные серверы на этой стороне, и он сказал мне, что это не влияет. Вы перезагрузили свою систему или, по крайней мере, уверены, что все необходимые процессы были перезапущены?
Crimi
3
После обновления OPENSSL все, что мне нужно было сделать, это перезапустить службу apache, но изящная не помогла . Я должен был пойти и перезапустить с помощьюsudo service apache2 restart
Том Херт
1
Я только что нашел причину своей уязвимости: у меня установлен mod-spdy-beta. После удаления и перезапуска apache все тесты теперь зеленого цвета.
Андреас Рот
3
Обновление opensslне исправляет приложения, такие как Apache, Nginx или postfix. Вы должны обновить libssl1.0.0и перезапустить их, как описано в других сообщениях.
TNJ
17

Если в ваших репозиториях apt-get нет предварительно скомпилированной версии 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 return
openssl version
OpenSSL 1.0.1g 7 Apr 2014

Сравни это сообщение в блоге .

NB: Как указано в сообщении в блоге, этот обходной путь не исправит «Nginx и сервер Apache, которые должны быть перекомпилированы с исходными кодами openSSL 1.0.1g».

Квентин Руссо
источник
2
Как обычно, Ubuntu не предоставляет новую версию апстрима, но исправила версии для всех поддерживаемых выпусков, чтобы сохранить изменения как минимум.
Флориан Диш,
1
Примечание. Обязательно перезапустите сервер после обновления OpenSSL. Apache и Nginx подобрали новую библиотеку, и уязвимость была закрыта.
дАнгелов
6
Хех, теперь, когда я потратил время, чтобы прочитать подробности этой публикации, я стал еще более ошеломлен - загрузка тарбола из какого-то случайного места из Интернета, распаковка и выполнение его частей от имени root - просто безрассудное поведение. Было бы немного лучше, если бы сигнатуры были загружены и проверены, но проверка правильности подписей, подписанных с помощью правильного ключа, сама по себе является сложным вопросом. Распределения уже направлены на обеспечение безопасного происхождения тарбаллов и патчей. Благодарю.
Сарнольд
2
может быть хорошей идеей скомпилировать из исходного кода СЕЙЧАС, а затем установить более новый из apt, таким образом, это более безопасно, чем без ожиданий на старых версиях ubuntu. В любом случае, только мои два цента
nwgat
2
@sarnold openssl.org не кажется случайным местом для загрузки исходного кода для openssl. Canonical должен сделать это ненужным, но openssl.org должен быть авторитетным апстримом для работы.
Руставоре
12

Для тех, кто не хочет выполнять обновление пакета для всего сервера. Сегодня я прочитал кучу этих руководств, и 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 restart

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

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

$ dpkg -l | grep ssl

ii  libssl-dev                       1.0.1-4ubuntu5.12          SSL development libraries, header files and documentation
ii  libssl1.0.0                      1.0.1-4ubuntu5.12          SSL shared libraries
ii  openssl                          1.0.1-4ubuntu5.12          Secure Socket Layer (SSL)* binary and related cryptographic tools

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

http://filippo.io/Heartbleed/

Адриан
источник
2
Использование внешнего сайта для доказательства уязвимости на сервере кажется мне неправильным подходом.
Rinzwind
Сценарии тестирования внешних уязвимостей становятся все более распространенным явлением в наши дни. Он делает именно то, что делает внутренний скрипт, соединение только начинается с внешнего веб-сервера. На таких сайтах, как WhiteHatSecurity.com, вы можете найти пример программы, которая инициирует все подключения удаленно. Бывают случаи, когда это не сработает, например, тестирование уязвимости сети, но для тестирования обращенного вперед веб-сервера (которым обычно будет SSL-сервер) это почти идеально.
Адриан
Зачем устанавливать пакет, если он обновляется?
Брайам
1
apt-get install openssl libssl1.0.0сделал это для меня. Запуск openssl version -aсейчас показывает:built on: Mon Apr 7 20:33:29 UTC 2014
Topher
«Сценарии тестирования внешних уязвимостей становятся все более и более распространенными в наши дни», что открывает возможность того, что этот внешний сайт злоупотребляет моей системой: все, что им нужно, - это знать, что он не работает, и взломать мою систему, прежде чем я ее исправлю. Нет, это не правильный путь. (и да, я размещаю свои собственные сайты с apache и openssl).
Rinzwind
11

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

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

:~$ sudo apt-get upgrade -V
Reading package lists... Done
Building dependency tree
Reading state information... Done
The 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. Затем перезапустите затронутые службы.

Домино
источник