Heartbleed: Що це таке і які варіанти його пом’якшення?


204

Це канонічне запитання про розуміння та усунення проблеми безпеки Heartbleed.

Що саме таке CVE-2014-0160 AKA "Heartbleed"? У чому причина, які ОС та версії OpenSSL вразливі, які симптоми, чи існують методи виявлення успішного використання?

Як я можу перевірити, чи впливає на мою систему? Як можна зменшити цю вразливість? Чи повинен я бути стурбований тим, що мої ключі чи інші приватні дані були порушені? Які ще побічні ефекти слід турбувати?


14
Пом'якшення дії Heartbleed передбачає більше, ніж просто нові клавіші . (Посилання на мою відповідь на інформаційну безпеку StackExchange)
scuzzy-delta

Я чую вас, але я думаю, що EEAA досить всебічно висвітлював це нижче.
MadHatter

Я погоджуюся: це чудова відповідь, але heartbleed.com докладає великих зусиль, щоб зазначити, що існують міркування, що виходять за рамки лише нових ключових пар - наприклад, примушування змін пароля та відключення сесії.
скупі-дельта

1
@ scuzzy-delta - хороший момент. Я відповів на відповідь CW зараз, тому сміливо редагуйте / покращуйте її за допомогою цієї інформації.
EEAA

3
Найкращий приклад того, що це - (не дивно) XKCD: xkcd.com/1354
Wayne Werner

Відповіді:


118

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

Що саме таке CVE-2014-0160 aka "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. Див. Складність сердечного доступу / протокол .

Чи був зловмисно вставлений код помилки?

Я не буду міркувати про те, чи справді це була помилка чи, можливо, трохи коду, який прослизнув від імені поганого актора. Однак особа, яка розробила код для OpenSSL, заявляє, що це було ненавмисно. Дивіться, людина, яка представила серйозний недолік безпеки "Heartbleed", заперечує, що він вставив її навмисно .

Які ОС та версії OpenSSL вразливі?

Як було сказано вище, будь-яка операційна система, яка використовує, або додаток, який пов'язаний між OpenSSL 1.0.1 та 1.0.1f.

Які симптоми, чи є якісь методи виявлення успішного подвигу?

Це страшна частина. Наскільки нам відомо, не існує відомого способу виявити, чи була використана ця вразливість чи ні. Теоретично можливо, що незабаром будуть опубліковані підписи IDS, які зможуть виявити цей подвиг, але станом на цей текст вони недоступні.

Є дані, що Heartbleed активно експлуатувались в дикій природі ще в листопаді 2013 року. Дивіться EFF Wild in Heart: Чи розвідувальні агенції використовували Heartbleed у листопаді 2013 року? І повідомляє Bloomberg, що АНБ озброїло цей вибух незабаром після введення вразливості. Ознайомтеся з NSA, що роками експлуатує помилку, що боїться серця . Однак американська розвідувальна спільнота заперечує претензії Bloomberg. Див. СК НА ЗАПИС .

Як я можу перевірити, чи впливає на мою систему?

Якщо ви підтримуєте OpenSSL у своїй системі, ви можете просто видавати openssl version:

$ openssl version
OpenSSL 1.0.1g 7 Apr 2014

Якщо розподіл підтримує OpenSSL, то ви , ймовірно , не може визначити версію OpenSSL з - за спини Patching з допомогою opensslкоманди або інформацію про пакет (наприклад, apt-get, dpkg, yumабо rpm). У процесі зворотного виправлення, який використовується у більшості (усіх?) Дистрибутивах, використовується лише базовий номер версії (наприклад, "1.0.1e"); і не включає ефективну версію безпеки (наприклад, "1.0.1g").

Суперкористувач відкритий питання, щоб визначити ефективну версію безпеки для OpenSSL та інших пакетів, коли пакети проводяться з виправленням. На жаль, корисних відповідей немає (крім перевірки веб-сайту дистрибутива). Див. Розділ " Визначення ефективної версії безпеки", коли ви стикаєтесь з Backpatching ?.

Як правило: якщо ви коли-небудь встановлювали одну з постраждалих версій і коли-небудь запускали програми чи сервіси, пов’язані з підтримкою OpenSSL для підтримки TLS, то ви вразливі.

Де можна знайти програму для тестування на вразливість?

Протягом кількох годин після оголошення Heartbleed кілька людей в Інтернеті оприлюднили загальнодоступні веб-додатки, які нібито можуть бути використані для перевірки сервера на наявність цієї вразливості. Станом на це написання я не переглядав жодного, тому більше не публікую їх заявки. Їх можна знайти відносно легко за допомогою бажаної пошукової системи.

Як зменшується ця вразливість?

Оновіть до невразливої ​​версії та скиньте або повторно захистіть вразливі дані. Як зазначається на сайті Heartbleed , відповідні кроки реагування в цілому:

  1. Виправити вразливі системи.
  2. Відновити нові приватні ключі.
  3. Надішліть нову КСВ у свій КА.
  4. Отримайте та встановіть новий підписаний сертифікат.
  5. Недійсні ключі та файли cookie сесії
  6. Скидання паролів та загальних секретів
  7. Скасувати старі сертифікати.

Більш детальний аналіз та відповідь див. У розділі Що повинен робити оператор веб-сайту щодо OpenSSL Heartbleed? на біржі стека безпеки.

Чи повинен я бути стурбований тим, що мої ключі чи інші приватні дані були порушені? Які ще побічні ефекти слід турбувати?

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

Незабаром після виявлення вразливості Cloudfare запропонував виклик, щоб перевірити, чи можна відновити приватний ключ сервера на практиці. Виклик незалежно виграли Федір Індутний та Ілька Маттіла. Дивіться виклик Heartbleed .

Де я можу знайти більше інформації?

Дамп посилання, для тих, хто шукає більше деталей:


Досить детальну шкалу подій розкриття можна знайти на шкалі розкриття Heartbleed: хто знав, що і коли .


Якщо ви програміст і цікавитесь різними прийомами програмування, як виявлення нападу Heartbleed через msg_cbзворотний виклик OpenSSL , перегляньте розділ рекомендацій щодо безпеки 2014047 OpenSSL .


42
+1 для SHUT. Вниз. ВАШ. СЕРВЕРИ. * - Якщо ви зробите будь-що, де SSL дійсно важливий, вимкніть його, поки ви не вирішите проблему. Крім того, не забудьте встановити нові сертифікати (з новими ключами ) після того, як ви закріпіть ваші сервери - повторне використання старих ключів (можливо, було порушено) перемагає цілі виправлення вразливості ...
voretaq7

29
ТАКОЖ - перезавантажте будь-які сервіси, що посилаються на бібліотеки OpenSSL. Оновлення OpenSSL без перезавантаження демонів так само добре, як і зовсім не оновлення.
EEAA

14
Дійсно - після будь-якого основного виправлення (наприклад, OpenSSL) я вважаю хорошим правилом просто перезавантажити машину, щоб переконатися, що ви нічого не пропустите.
voretaq7

5
Один з тестерів був відкритим: github.com/FiloSottile/Heartbleed
Riking

3
@EEAA, "відключення ваших серверів" не означає, що вам доведеться тягнути живлення. Це означає, що вимкнути (або перенастроїти, щоб відключити ssl / tls) apache, або будь-яку службу, яка займається обслуговуванням.
psusi


36

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.1 г), до 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 / Після оновлення система отримує виправлений сердечний патч з 13.10.

Для всіх інших застарілих версій ubuntu це означає, що в основному необхідна нова установка.

Переконайтеся, що патч застосовано

По суті, запустіть openssl version -aі переконайтеся, що дата складання - 7 квітня 2014 року або пізнішої версії, але докладніші відомості тут .

Перезавантажте

Найкращий спосіб переконатися, що всі служби залежно від OpenSSL перезапускаються - це перезавантажити .


Я не можу говорити за інші версії, але, здається, патч доступний для точного (12.04). Хоча я не можу сказати напевно, що це виправляє вразливість, вона була принаймні складена після відповідного комітету ( Mon Apr 7 20:31:55 UTC 2014).
Кальріон

@Calrion: Патч для OpenSSL або упаковка Debian для OpenSSL? OpenSSL вже виправлено та випущено новий реліз.
Натан Осман

що буде з існуючими з’єднаннями під час оновлення openssl? їх скинуть?
pdeva

2
Це залежить від того, який веб-сервер ви використовуєте та як оновлюєте. Незважаючи на це, я б не турбувався про відмову від існуючих з'єднань, оскільки вони використовують вразливу версію.
Натан Осман


14

RedHat 6.5 і CentOS 6.5

Вони вразливі. Erratum RHSA-2014-0376 RedHat каже, що наявні виправлені бібліотеки, і кожен, хто постраждав, повинен оновити при першій же можливості.

На момент написання програми CentOS ще не мав фіксованої версії, але після публікації Karanbir Singh до CentOS-saop було сказано, що вони створили оновлену версію opensl ( 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 updateотримав це для моїх серверів; це 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-spon не менш чітке щодо версії:

Раніше сьогоднішнього дня нам було відомо про серйозну проблему в Opensl, що постачається в CentOS-6.5


Чи не liste.centos.org/pipermail/centos-announce/2014-April/… випуск виправлення?
user619714

13

Debian Wheezy

Debian використовує DSA-2896-1 і тут доступні бібліотеки з виправленими файлами . Скрипт оболонки доступний тут .

1. Патч

Репозиторій Apt-get було оновлено, тому тепер виправлені бібліотеки доступні через apt-get update && apt-get upgrade

apt-get upgrade libssl1.0.0 openssl

Альтернативно (не рекомендується) пакети можна оновити вручну:

wget http://security.debian.org/pool/updates/main/o/openssl/libssl1.0.0-dbg_1.0.1e-2+deb7u5_amd64.deb
wget http://security.debian.org/pool/updates/main/o/openssl/openssl_1.0.1e-2+deb7u5_amd64.deb
wget http://security.debian.org/pool/updates/main/o/openssl/libssl1.0.0_1.0.1e-2+deb7u5_amd64.deb
wget http://security.debian.org/pool/updates/main/o/openssl/libssl-dev_1.0.1e-2+deb7u5_amd64.deb

dpkg -i openssl_1.0.1e-2+deb7u5_amd64.deb
dpkg -i libssl1.0.0_1.0.1e-2+deb7u5_amd64.deb
dpkg -i libssl1.0.0-dbg_1.0.1e-2+deb7u5_amd64.deb
dpkg -i libssl-dev_1.0.1e-2+deb7u5_amd64.deb

2. Перезавантажте сервер / послуги

Для кращого захисту перезавантажте весь сервер або якщо сервер не може бути в автономному режимі, тоді перезапустіть потрібні сервіси.

3. Перевірте версію OpenSSL

love@server:~$ openssl version
OpenSSL 1.0.1e 11 Feb 2013
love@server:~$ dpkg -l libssl1.0.0
||/ Name                    Version          Architecture     Description
+++-=======================-================-================-====================================================
ii  libssl1.0.0                 1.0.1e-2+deb7u6  amd64            SSL shared libraries

1
Якщо ви отримуєте оновлення з того wheezy/securityчасу, вам буде добре apt-get update && apt-get upgrade. Або використовувати інтерактивний менеджер пакетів тільки оновити пакети openssl, libssl1.0.0, libssl1.0.0-dbgі libssl-dev(як встановлено у вашій системі).
CVn

використання apt-get не вирішує проблему для мене - все ще показує OpenSSL 1.0.1e 11 лютого 2013
user568829

Дякую @ michael-kjorling, він не був доступний, коли я це робив, але це найбільш безпечний і правильний спосіб оновлення.
jacksoncage

2
@ user568829 після застосування версії патча openssl все ще відображатиметься, OpenSSL 1.0.1e 11 Feb 2013оскільки патч називається 1.0.1e-2. Ви можете перевірити, dpkg -l opensslі вона повинна показувати версію1.0.1e-2+deb7u6
jacksoncage

2
Я б запропонував перезапустити хост після оновлення OpenSSL не тому, що це вкрай необхідно, а для спокою, що принаймні все, що динамічно завантажує бібліотеки OpenSSL, використовує нову версію. (Статистично пов'язане - це інша справа.) З цього приводу я розумію, що деякі сервери не можуть бути легко перезавантажені у всіх ситуаціях, коли перезапуск послуги може бути прийнятним.
CVn

9

Я хотів би зазначити, що приватні ключі - не єдиний актив, який слід вважати компрометованим. Помилка може витікати будь-яку пам'ять, що працює в тому ж адресному просторі (тобто той же процес), що і OpenSSL. Тому, якщо ви запускаєте серверний процес, де вразлива версія OpenSSL є стаціонарно або динамічно пов'язана, будь-яку інформацію, якою цей процес коли-небудь обробляв , включаючи паролі, номери кредитних карток та інші особисті дані, слід вважати потенційно порушеними.


9

FreeBSD 10.0 або openssl з портів

Команда з безпеки FreeBSD випустила рекомендації щодо CVE-2014-0160 (він же "Heartbleed") та: FreeBSD-SA-14: 06.openssl

  1. Оновлення FreeBSD

    • Оновлення FreeBSD через бінарний патч

      Системи, що працюють на RELEASE версії FreeBSD на платформах i386 або amd64, можна оновити за допомогою утиліти freebsd-update (8):

      # freebsd-update fetch
      # freebsd-update install
      
    • Оновлення FreeBSD з джерел

      1. Завантажте відповідний патч з місця нижче та перевірте відокремлений підпис PGP за допомогою утиліти PGP.

        # fetch http://security.FreeBSD.org/patches/SA-14:06/openssl-10.patch
        # fetch http://security.FreeBSD.org/patches/SA-14:06/openssl-10.patch.asc
        # gpg --verify openssl-10.patch.asc
        
      2. Виконайте такі команди як корінь:

        # cd /usr/src
        # patch < /path/to/patch
        
      3. Перекомпілюйте операційну систему

        з використанням buildworld та installworld, як описано в посібнику FreeBSD .

  2. Оновлення OpenSSL порт з мінімальної версії 1.0.1_10

  3. Перезавантажте всі демони за допомогою бібліотеки або перезавантажте систему

  4. Дійте так, ніби ваша система зламана , переоформліть усі свої ключі ssl та / або сертифікати та потенційно просочившись інформацію (див. Загальну відповідь EEAA ).

FreeBSD 9.x та FreeBSD 8.x

Ця система не є вразливою до проблеми Heartbleed за замовчуванням, оскільки покладається на старішу версію 0.9.x бібліотеки openssl , якщо ви не встановили openssl з портів (див. Вгорі).

Якщо ці системи не є вразливими до проблеми Heartbleed , можливо, було б розумно оновити вашу систему швидше, ніж пізніше через іншу локальну вразливість (див. FreeBSD-SA-14: 06.openssl та розділ "FreeBSD 10.0" наверху ):

Місцевий зловмисник може перервати процес підписання і може відновити ключ підпису з нього. [CVE-2014-0076]

Примітка :

Оригінальний довідник Heartbleed зазначає, що FreeBSD 8.4 та 9.1 є потенційно вразливими. Це неправда через відсутність розширення Heartbeat (за замовчуванням бібліотека OpenBSD openssl є версією 0.9.x).


3

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

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

Випуск завершеного VM знаходиться тут . Він у форматі VMX.

Слова попередження

Цей скрипт та VM покажуть лише поточний стан ваших систем. Цілком можливо, що в певний момент минулого, що ваші системи опинилися в уразливому стані, і їх можна було зловживати.

Щось тут з’являється, безумовно, є першочерговим завданням для виправлення, але це не позбавляє вас від застосування оновлень та зміни всіх ваших ключів.


Щойно я отримав електронний лист від Snapt, їх це. БОЛО (Будь в огляді) !
Яків

2

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, будь-який Amazon Linux AMI 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
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.