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


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

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

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


152
2018-04-07 22:17


происхождения


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


ответы:


Обновления безопасности доступны для 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-ключи, затем оцените, могли ли ваши ключи просочиться, и в этом случае злоумышленники могут получить конфиденциальную информацию с ваших серверов.


141
2018-04-07 22:46



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


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

Я уязвим?

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

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

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

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

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

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

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

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

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

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

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

  5. отзывать старые сертификаты.

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

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

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

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

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

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

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


71
2018-04-08 10:02



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


Чтобы узнать, какая версия 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
...

40
2018-04-08 06:40



Я обновил и получил версию 5.12, но этот инструмент все еще говорит мне, что я уязвим filippo.io/Heartbleed Мысли? - toxaq
Я тестировал наши обновленные серверы с этой стороны, и он сказал мне, что меня это не затрагивает. Перезагрузили ли вы систему или, по крайней мере, вы уверены, что все необходимые процессы были перезапущены? - crimi
После обновления OPENSSL все, что мне нужно было сделать, это перезапустить службу apache, но изящный не помог, Я должен был пойти и перезапустить, используя sudo service apache2 restart - Tom Hert
Я только что нашел причину своей уязвимости: у меня установлена ​​мода-spdy-бета. После удаления и перезапуска apache все тесты теперь зеленые. - Andreas Roth
обновление openssl не исправляет такие приложения, как Apache, Nginx или postfix. Вы должны обновить libssl1.0.0 и перезапустите их, как описано в других сообщениях. - tnj


Если ваш 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

Cf это Сообщение блога,

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


17
2018-04-08 02:18



Как обычно, Ubuntu не предоставляет новую версию восходящего потока, но исправлял версии для всех поддерживаемых релизов, чтобы сохранить изменения как минимум. - Florian Diesch
Примечание. После обновления OpenSSL убедитесь, что вы перезагрузили сервер. Apache и Nginx подняли новую библиотеку, и уязвимость была закрыта. - dAngelov
Хех, теперь, когда я трачу время, чтобы прочитать Детали из этой публикации я еще более ошеломляю - загрузка tarball из какого-то случайного места из Интернета, распаковка и выполнение его частей, поскольку root - это просто безрассудное поведение. Было бы немного лучше, если бы подписи tarball были загружены и проверены, но убедившись, что вы подтвердили, что подписи были подписаны с помощью правильного ключа, сам по себе является сложным вопросом. Распределения уже направлены на обеспечение безопасного происхождения архивов и патчей. Благодарю. - sarnold
это может быть хорошей идеей скомпилировать из источника NOW и установить более новую версию позже с apt, таким образом, вы будете более безопасны, чем без ожиданий в старых версиях ubuntu, так или иначе, только мои два цента - nwgat
@sarnold openssl.org не похоже на случайное место для загрузки источника для openssl. Canonical должен сделать это ненужным, но openssl.org должен быть авторитетным вверх по течению от работы. - Rustavore


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

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

  • Идти к этот адрес и доказать, что у вас есть уязвимость. Вы должны использовать ПРЯМОЙ ВНЕШНИЙ АДРЕС ВАШЕГО WEB-СЕРВЕРА. Если вы используете loadbalancer (например, 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/


12
2018-04-08 21:56



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


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

Вы должны проверить, чтобы у вас не было пакетов в ожидании, например 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, Затем перезапустите соответствующие службы.


11
2018-04-08 17:51