Как исправить ошибку Heartbleed (CVE-2014-0160) в 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/+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
...

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

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

Каковы будут последствия?

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

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

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

1. Перевести все затронутые серверы в автономный режим. Пока они работают, возможна утечка важных данных.

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

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

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

4. Теперь, когда у вас есть новые бескомпромиссные ключи, вы можете вернуть свой сервер в оперативный режим .

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

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

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

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

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

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

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

Ссылки

• Ошибка Heartbleed (одной из двух команд, которые независимо обнаружили ошибку)
• Как именно так происходит сердцебиение OpenSSL TLS (Heartbleed) работает?
• Означает ли Heartbleed новые сертификаты для каждого сервера SSL?
• Heartbleed: Что это такое и какие есть варианты смягчения последствий?

Если ваши репозитории 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 this сообщение в блоге .

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 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/

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

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