Я искал надежный и переносимый способ проверить версию OpenSSL в GNU / Linux и других системах, чтобы пользователи могли легко узнать, следует ли им обновить свой SSL из-за ошибки Heartbleed.
Я думал, что это будет легко, но быстро столкнулся с проблемой на Ubuntu 12.04 LTS с последней версией OpenSSL 1.0.1g:
openssl version -a
Я ожидал увидеть полную версию, но вместо этого получил следующее:
OpenSSL 1.0.1 14 Mar 2012 built on: Tue Jun 4 07:26:06 UTC 2013 platform: [...]
К моему неприятному удивлению, буквенное обозначение версии не отображается. Ни ф, ни г, просто "1.0.1" и все. Указанные даты также не помогают обнаружить (не) уязвимую версию.
Разница между 1.0.1 (a-f) и 1.0.1g имеет решающее значение.
Вопросы:
Другие также сообщают об этом поведении. Несколько примеров:
Некоторые (специфичные для дистрибутива) предложения:
apt-cache policy openssl
и apt-cache policy libssl1.0.0
. Сравните номера версий с пакетами здесь: http://www.ubuntu.com/usn/usn-2165-1/yum info openssl
(спасибо @znmeb в твиттере) и yum info openssl-libs
Проверка резидентности более старой версии OpenSSL:
lsof -n | grep ssl | grep DEL
. Видеть Heartbleed: как надежно и портативно проверить версию OpenSSL? почему это может не сработать для вас.Оказывается, обновления пакета OpenSSL в Ubuntu и Debian не всегда достаточно. Вы также должны обновить пакет libssl1.0.0 и, затем, проверить, если openssl version -a
указывает built on: Mon Apr 7 20:33:29 UTC 2014
.
Судя по дате, указанной в вашей версии 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 поставляется с ванильным 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, ОСТАЕТСЯ 1.0.1 после обновления до фиксированной версии.
ТОЛЬКО для Ubuntu 12.04 вы можете определить, были ли вы обновлены, если все нижеприведенное верно:
dpkg -s openssl | grep Version
показывает версию 1.0.1-4ubuntu5.12 или новее.dpkg -s libssl1.0.0 | grep Version
показывает версию 1.0.1-4ubuntu5.12 или новее.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
Ой, все еще нет г.
Любой из этих скриптов тестирует все службы или тестирует только HTTPS? Насколько мне известно, PostgreSQL уязвима, но это только слухи, пока не появится атака в дикой природе.
Eсть метасплоит скрипт доступен для использования.
https://github.com/rapid7/metasploit-framework/commit/dd69a9e5dd321915e07d8e3dc8fe60d3c54f551a
Вы можете ввести это (проверено с GnuWin32 Двоичная версия OpenSSL 1.0.1.6 от 14 января 2014 г.), или просто используйте скрипт в комментарии под этим. Так точнее и проще!
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
Источник:
Также есть эти инструменты:
Для Ubuntu вы можете использовать:
aptitude show libssl1.0.0 | grep Version
И сравните с http://www.ubuntu.com/usn/usn-2165-1/. После перезагрузки (!!!) можно проверить с помощью http://possible.lv/tools/hb
.
Вам лучше перейти на последнюю версию OpenSSL OpenSSL 1.0.1j.
http://blog.vincosolution.com/2014/10/upgrade-openssl-1-0-1j-debianubuntu.html
я нашел этот скрипт в 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)"
если не.
Это зависит не от номера версии, а от перечисления расширения сервера, которое вызывает проблему, поэтому оно должно быть невосприимчивым к махинациям с версией библиотеки.
Машина, на которой вы работаете openssl s_client
на должен использовать OpenSSL 1.0.1 или новее, чтобы это работало.