Heartbleed: как надежно и портативно проверить версию OpenSSL?

Я искал надежный и портативный способ проверки версии OpenSSL в GNU/Linux и других системах, чтобы пользователи могли легко определить, следует ли им обновить свой SSL из-за ошибки Heartbleed.

Я думал, что это будет легко, но я быстро столкнулся с проблемой на Ubuntu 12.04 LTS с последней версией OpenSSL 1.0.1g:

 версия openssl -a 

Я ожидал увидеть полную версию, но вместо этого я получил это:

 OpenSSL 1.0.1 14 марта 2012 г.
Построен: вт июн 4 07:26:06 UTC 2013
Платформа: [...] 

К моему неприятному удивлению, письмо с версией не показывается. Нет f, нет g там, просто "1.0.1" и все. Перечисленные даты также не помогают обнаружить (не) уязвимую версию.

Разница между 1.0.1 (af) и 1.0.1g имеет решающее значение.

Вопросы:

  • Какой надежный способ проверить версию, желательно перекрестный дистрибутив?
  • Почему буква версии не отображается в первую очередь? Я не смог проверить это ни на чем другом, кроме Ubuntu 12.04 LTS.

Другие также сообщают об этом поведении. Несколько примеров:

Некоторые (специфичные для дистрибутива) предложения, появляющиеся в:

  • Ubuntu и Debian: apt-cache policy openssl а также apt-cache policy libssl1.0.0, Сравните номера версий с пакетами здесь: http://www.ubuntu.com/usn/usn-2165-1/
  • Fedora 20: yum info openssl (спасибо @znmeb в твиттере) и yum info openssl-libs

Проверка, является ли более старая версия OpenSSL все еще резидентной:

Оказывается, что обновления пакета OpenSSL в Ubuntu и Debian не всегда достаточно. Вам также следует обновить пакет libssl1.0.0 и проверить openssl version -a указывает built on: Mon Apr 7 20:33:29 UTC 2014 ,

8 ответов

Решение

Судя по дате, отображаемой вашей версией OpenSSL, кажется, что вы видите полную версию, отображаемую там.

Open SSL 1.0.1 был выпущен 14 марта 2012 года. 1.0.1a был выпущен 19 апреля 2012 года.

Итак, я собираюсь пойти дальше и утверждать, что openssl version -a это правильный перекрестный дистрибутив для отображения полной версии OpenSSL, установленной в системе. Похоже, что он работает для всех дистрибутивов Linux, к которым у меня есть доступ, и это метод, предложенный также в документации OpenSSL help.ubuntu.com. Ubuntu LTS 12.04 поставляется с vanilla OpenSSL v1.0.1, которая является версией, которая выглядит как сокращенная версия, из-за отсутствия следующей за ней буквы.

Сказав это, кажется, что есть серьезная ошибка в Ubuntu (или как они упаковывают OpenSSL), в этом openssl version -a продолжает возвращать исходную версию 1.0.1 с 14 марта 2012 г. независимо от того, был ли обновлен OpenSSL до какой-либо из более новых версий. И, как с большинством вещей, когда идет дождь, он льет.

Ubuntu - не единственный крупный дистрибутив, в котором есть привычка пересылать обновления в OpenSSL (или другие пакеты), скорее, чем полагаться на обновления и нумерацию версий, которые все признают. В случае OpenSSL, где буквенные номера версий представляют только исправления ошибок и обновления безопасности, это кажется почти непонятным, но мне сообщили, что это может быть из -за проверенного FIPS плагина основных дистрибутивов Linux, поставляемого в комплекте с OpenSSL. Из-за требований, связанных с повторной проверкой, которые инициируются из-за любых изменений, даже изменений, которые закрывают дыры в безопасности, он заблокирован по версии.

Например, в Debian исправленная версия отображает номер версии 1.0.1e-2+deb7u5 вместо основной версии 1.0.1g,

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

Если вы хотите что-то действительно кроссплатформенное, проверьте наличие самой уязвимости, а не полагайтесь на номера версий.

Возможно, у вас есть код, сообщающий номер версии, который, как известно, уязвим, но реальный код не уязвим. И наоборот - тихо уязвимый код - может быть еще хуже!

Многие поставщики, которые объединяют продукты с открытым исходным кодом, такие как OpenSSL и OpenSSH, будут выборочно модифицировать срочные исправления к более старой версии кода, чтобы поддерживать стабильность и предсказуемость API. Это особенно актуально для платформ "долгосрочного выпуска" и устройств.

Но поставщики, которые делают это молча (без добавления собственного строкового суффикса версии), рискуют вызвать ложные срабатывания в сканерах уязвимостей (и вводят пользователей в заблуждение). Таким образом, чтобы сделать это прозрачным и проверяемым, некоторые поставщики добавляют свои собственные строки к основной версии пакета. И Debian (OpenSSL), и FreeBSD (в OpenSSH, через VersionAddendum директива sshd_config) иногда это делают.

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

Так это может выглядеть так:

$ cat /etc/lsb-release 
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=12.04
DISTRIB_CODENAME=precise
DISTRIB_DESCRIPTION="Ubuntu 12.04.4 LTS"

$ openssl version
OpenSSL 1.0.1 14 Mar 2012

... хотя это было исправлено:

$ dpkg -l openssl | grep openssl
ii  openssl  1.0.1-4ubuntu5.12  [truncated]

$ ls -la `which openssl`
-rwxr-xr-x 1 root root 513208 Apr  7 12:37 /usr/bin/openssl

$ md5sum /usr/bin/openssl
ea2a858ab594905beb8088c7c2b84748  /usr/bin/openssl

С такими вещами в игре вам будет лучше, если вы не будете доверять номеру версии.

К сожалению, я не уверен, что есть кроссплатформенный способ сделать это. Как я обсуждаю в блоге, версия OpenSSL отображается в Ubuntu 12.04 REMAINS 1.0.1 после обновления до фиксированной версии.

ТОЛЬКО для Ubuntu 12.04 вы можете узнать, были ли вы обновлены, если все из приведенного ниже верно:

  1. dpkg -s openssl | grep Version показывает версию 1.0.1-4ubuntu5.12 или более позднюю.
  2. dpkg -s libssl1.0.0 | grep Version показывает версию 1.0.1-4ubuntu5.12 или более позднюю.
  3. openssl version -a показывает дату постройки 7 апреля 2014 года или позже.

Спасибо @danny за дополнительную информацию.

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

ldd `which ssh` | awk '/\// { print $3 }' | grep crypto | xargs strings  | grep OpenSSL

производит

OpenSSLDie
DSA_OpenSSL
...
MD4 part of OpenSSL 1.0.1f 6 Jan 2014 
MD5 part of OpenSSL 1.0.1f 6 Jan 2014
... 
etc

например, на Gentoo до появления

[ebuild     U  ] dev-libs/openssl-1.0.1f [1.0.1c] USE="bindist (sse2) tls-heartbeat%* zlib -gmp -kerberos -rfc3779 -static-libs {-test} -vanilla" 4,404 kB

приведенная выше команда приводит к

...
OpenSSL 1.0.1c 10 May 2012

после

...
OpenSSL 1.0.1f 6 Jan 2014

Ой, до сих пор нет g.

Проверяет ли какой-либо из этих сценариев все службы или только HTTPS? AFAIK, PostgreSQL уязвим, но это только слух, пока не всплывет атака в дикой природе.

Существует сценарий metasploit, доступный для использования.

https://github.com/rapid7/metasploit-framework/commit/dd69a9e5dd321915e07d8e3dc8fe60d3c54f551a

Вы можете напечатать это (протестировано с GnuWin32 OpenSSL бинарная версия 1.0.1.6, от 2014-01-14), или просто использовать скрипт в комментарии ниже этого. Это точнее и проще!

s_client -connect a23-75-248-141.deploy.static.akamaitechnologies.com:443 -debug -state

После подключения введите B, и вы увидите на уязвимом хосте, и вы не будете отключены:

B

HEARTBEATING
write to 0x801c17160 [0x801cbc003] (66 bytes => 66 (0x42))
0000 - 18 03 03 00 3d 8f 6f 3c-52 11 83 20 9c a2 c0 49   ....=.o 5 (0x5))
0000 - 18 03 03 00 3d                                    ....=
read from 0x801c17160 [0x801cb7008] (61 bytes => 61 (0x3D))
0000 - 05 4d f5 c0 db 96 d1 f5-c7 07 e5 17 1f 3b 48 34   .M...........;H4
0010 - 6e 11 9d ba 10 0c 3a 34-eb 7b a5 7c c4 b6 c0 c0   n.....:4.{.|....
0020 - b0 75 0e fe b7 fa 9e 04-e9 4e 4a 7d 51 d3 11 1f   .u.......NJ}Q...
0030 - e2 23 16 77 cb a6 e1 8e-77 84 2b f8 7f            .#.w....w.+..
read R BLOCK

Вы получите ответ сердцебиения, похожий на этот.

На пропатченном хосте вы увидите ответ, аналогичный приведенному ниже, и вы будете отключены:

Введите B

HEARTBEATING
write to 0x801818160 [0x8019d5803] (101 bytes => 101 (0x65))
0000 - 18 03 03 00 60 9c a3 1e-fc 3b 3f 1f 0e 3a fe 4c   ....`....;?..:.L
0010 - a9 33 08 cc 3d 43 54 75-44 7d 2c 7b f3 47 b9 56   .3..=CTuD},{.G.V
0020 - 89 37 c1 43 1c 80 7b 87-66 ff cb 55 5f 8d 1a 95   .7.C..{.f..U_...
0030 - 1b 4c 65 14 21 a1 95 ac-7a 70 79 fc cc a0 cf 51   .Le.!...zpy....Q
0040 - 0f 7e c5 56 14 c8 37 c1-40 0b b8 cb 43 96 8a e6   .~.V..7.@...C...
0050 - 21 42 64 58 62 15 fb 51-82 e6 7f ef 21 1b 6f 87   !BdXb..Q....!.o.
0060 - b9 c2 04 c8 47                                    ....G

Источник:

Есть также эти инструменты:

Вам лучше обновиться до последней версии OpenSSL OpenSSL 1.0.1j.

http://blog.vincosolution.com/2014/10/upgrade-openssl-1-0-1j-debianubuntu.html

Для Ubuntu вы можете использовать:

aptitude show libssl1.0.0 | grep Version

И сравните с http://www.ubuntu.com/usn/usn-2165-1/. После перезагрузки (!!!) вы можете проверить с помощью http://possible.lv/tools/hb,

Я нашел этот скрипт в devcentral:

openssl s_client -connect example.com:443 -tlsextdebug 2>&1| grep 'server extension "heartbeat" (id=15)' || echo safe

замещать example.com с именем или IP-адресом сервера, который вы хотите проверить.

Вернусь "safe" если ваш сервер в порядке или "server extension "heartbeat" (id=15)" если не.

Это зависит не от номера версии, а от перечисления расширения сервера, вызывающего проблему, поэтому оно должно быть защищено от shenanigans версии библиотеки.

Машина, на которой вы работаете openssl s_client on должен использовать OpenSSL 1.0.1 или новее, чтобы это работало.

Другие вопросы по тегам