Comments 260
С таким багом можно целые государства на колени ставить!
Простите, что врываюсь в ваш (верхний) комментарий.
Это серьезное говно. Будите всех своих IT-знакомых, обновляйте серверы!
filippo.io/Heartbleed/ — Проверка вашего сервера на уязвимость
rehmann.co/projects/heartbeat/ — еще одна (немного туповата)
Надо помнить, что люди, использующие Debian или Ubuntu могут быть менее подвержены этому багу, т.к. для многих приложений по умолчанию используется GnuTLS, а не OpenSSL. В других же дистрибутивах, как правило, используется OpenSSL.
Отзывайте свои SSL-сертификаты, генерируйте новые.
Это серьезное говно. Будите всех своих IT-знакомых, обновляйте серверы!
filippo.io/Heartbleed/ — Проверка вашего сервера на уязвимость
rehmann.co/projects/heartbeat/ — еще одна (немного туповата)
Надо помнить, что люди, использующие Debian или Ubuntu могут быть менее подвержены этому багу, т.к. для многих приложений по умолчанию используется GnuTLS, а не OpenSSL. В других же дистрибутивах, как правило, используется OpenSSL.
Отзывайте свои SSL-сертификаты, генерируйте новые.
Простите, а сертификаты-то зачем менять?
Они скомпрометированы.
Потенциально скомпрометированы, верно?
Учитывая низкую сложность эксплуатации — то, скорее всего скомпрометированы :)
Низкая сложность эксплуатации имеет значение теперь, когда уязвимость раскрыли. Те же немногие, кто знал о баге до этого, не ломали всех подряд. Небольшие проекты и сайты без финансовых транзакций, думаю, могут сильно не нервничать. Тем не менее, сменить сертификаты, пожалуй, стоит. Большие же игроки, вроде Гугла, итак уже взяли в практику регулярную их замену.
Интересна ситуация с крупными CA. Кто из них решится на отзыв и замену корневых и промежуточных сертов, признав тем самым их уязвимость? С другой стороны, это неплохой шанс попиариться, предложив клиентам бесплатную замену сертификатов, подписанных этими, потенциально скомпрометированными.
Интересна ситуация с крупными CA. Кто из них решится на отзыв и замену корневых и промежуточных сертов, признав тем самым их уязвимость? С другой стороны, это неплохой шанс попиариться, предложив клиентам бесплатную замену сертификатов, подписанных этими, потенциально скомпрометированными.
UFO just landed and posted this here
К тому же ключи корневых CA обычна хранятся в HSM и не имеют контактов с внешним миром. Утечь же таким образом ключу intermediate CA — тоже проблематично, т. к. он не экспонируется в TLS соединение. Т. е. за S/MIME, code signing и т. п. ключи можно не волноваться.
Интересно, могли пострадать ключи серверов типа openvpn, ipsec туннелей? Требует ли использование hearbeat установления канала (который не будет установлен при «левом» клиенте)?
Интересно, могли пострадать ключи серверов типа openvpn, ipsec туннелей? Требует ли использование hearbeat установления канала (который не будет установлен при «левом» клиенте)?
Да, я почему-то подумал, что CA сертификаты тоже могут быть скомпрометированы.
filippo.io/Heartbleed/ — соберут неплохую базу уязвимых серверов :)
расчет идет из того что проверяющие — будут таки закрывать дыры ;)
github.com/FiloSottile/Heartbleed/ — исходники этого сервиса
github.com/titanous/heartbleeder/ — еще одна тестилка
github.com/titanous/heartbleeder/ — еще одна тестилка
PoC на Python!
s3.jspenguin.org/ssltest.py
Можно, например, почту читать, если использовать его на mail.yandex.ru. Я не шучу.
s3.jspenguin.org/ssltest.py
Можно, например, почту читать, если использовать его на mail.yandex.ru. Я не шучу.
Еще одна онлайн-чекалка: possible.lv/tools/hb/
UFO just landed and posted this here
Да уж яндекс разочаровал такой тормозной реакцией :(
Со времени публикации уязвимости прошло уже полдня, а прикрыли буквально только полчаса назад, и весь мир читал нашу почту всё это время.
Тоже с помощью вашей утилиты сдампилось чьё-то письмо.
Я уж думал в таких серьёзных организациях как Яндекс, служба безопасности дежурит круглосуточно. Да хрен с ней с СБ, но я не пойму, на яндексе что отключен авто-апдейт секьюрных обновлений?
Позор одним словом.
Со времени публикации уязвимости прошло уже полдня, а прикрыли буквально только полчаса назад, и весь мир читал нашу почту всё это время.
Тоже с помощью вашей утилиты сдампилось чьё-то письмо.
Я уж думал в таких серьёзных организациях как Яндекс, служба безопасности дежурит круглосуточно. Да хрен с ней с СБ, но я не пойму, на яндексе что отключен авто-апдейт секьюрных обновлений?
Позор одним словом.
Ага. Я им позвонил и написал на две почты.
Банки вообще не особо осознают опасность. Висел на телефоне по 20 минут, пока они там «соединяли» меня.
Альфа быстро закрыла после моего звонка, остальные — нет.
Банки вообще не особо осознают опасность. Висел на телефоне по 20 минут, пока они там «соединяли» меня.
Альфа быстро закрыла после моего звонка, остальные — нет.
Они что там ещё и думают слушать вас или нет?!
Да 7 апреля можно объявить официальным праздником всех скаммеров, фишеров и прочих кардеров. Сейчас может прокатиться такая волна финансовых угонов, что у банкстеров в ушах зазвенит от дальнейших разборов полётов.
Вот уж дожили, 21-ый век, мелкий баг в сторонней либе ставит на колени всю мировую финансовую систему :)
Да 7 апреля можно объявить официальным праздником всех скаммеров, фишеров и прочих кардеров. Сейчас может прокатиться такая волна финансовых угонов, что у банкстеров в ушах зазвенит от дальнейших разборов полётов.
Вот уж дожили, 21-ый век, мелкий баг в сторонней либе ставит на колени всю мировую финансовую систему :)
А расскажите, как вы себе представляете «не тормознутую» реакцию в это случае?
Я так понимаю вы шутите?
cron + apt-get. Не, не слышал.
cron + apt-get. Не, не слышал.
До первого неудачного обновления, требующего ручного вмешательства, например, в конфиги.
Во-первых, можно прописать установку ТОЛЬКО секьюрных апдейтов (в случае убунту — security.ubuntu.com/)
Во-вторых, я лучше соглашусь, чтобы мой почтовый сервер упал на сутки, чем слил все письма моей организации и её клиентов за прошедшие полдня.
Если админы не могут удержать в руках крупнейший почтовик страны, то нечего их оправдывать, на мыло таких админов, даром они кушают яндексовские плюшки с печеньками.
Во-вторых, я лучше соглашусь, чтобы мой почтовый сервер упал на сутки, чем слил все письма моей организации и её клиентов за прошедшие полдня.
Если админы не могут удержать в руках крупнейший почтовик страны, то нечего их оправдывать, на мыло таких админов, даром они кушают яндексовские плюшки с печеньками.
Во-вторых, я лучше соглашусь, чтобы мой почтовый сервер упал на сутки, чем слил все письма моей организации и её клиентов за прошедшие полдня.Это вопрос к модели угроз. Если стоимость простоя умноженная на вероятность простоя выше, чем стоимость утечки умноженной на её вероятность, то, очевидно, какое решение будет приниматься в рациональном случае.
Если ваша «защита» стоит дороже, чем защищаемые сведения — то зачем она нужна? Это не касаясь тех вариантов, когда есть внешний регламентирующий документ.
Я что-то в вашем последнем абзаце смысл не уловил. Причём тут «защита» (почему в кавычках?) стоит дороже?
Речь о том, что яндекс предоставляет корпоративную почту и за сегодняшний день она потенциально утекла из-за нерасторопности админов этой организации, которые полдня не могли накатить апдейты, вот и всё. Что тут ещё говорить?
Что там мне выше писали про проблемы, требующие ручного вмешательства. Так накатите обнову на один сервак, если всё в поряде, ставьте на остальные, там же всё за балансером полюбому.
Ладно, фиг с ним с яндексом, тут вон банки-то до сих пор не проапдейтились, о чём я вобще говорю, полнейшая безалаберность.
Речь о том, что яндекс предоставляет корпоративную почту и за сегодняшний день она потенциально утекла из-за нерасторопности админов этой организации, которые полдня не могли накатить апдейты, вот и всё. Что тут ещё говорить?
Что там мне выше писали про проблемы, требующие ручного вмешательства. Так накатите обнову на один сервак, если всё в поряде, ставьте на остальные, там же всё за балансером полюбому.
Ладно, фиг с ним с яндексом, тут вон банки-то до сих пор не проапдейтились, о чём я вобще говорю, полнейшая безалаберность.
Яндекс-лобби сливает карму. Вот они грязные методы борьбы :)
Не считайте меня адвокатом дьявола.
Допустим, Яндекс предоставляет корпоративную почту. По стандарту он не обязан её шифровать при передаче куда-либо (если, например, хост-получатель не поддерживает SMTPS и STARTTLS, то шифроваться ничего не будет и письмо пойдет по интернету plain text'ом). Надеюсь, что это не стало для вас открытием.
Соответственно, в договоре/SLA не может быть пункта, что они обязуются обеспечивать конфиденциальность почты клиента, если их юристы не любители ездить в лес в багажнике, конечно.
Медленное же обновление ключей и сертификатов на фронте — даёт некоторый риск утечки данных, но потери (в том числе, репутационные) могли посчитать меньшими, нежели от простоя в полдня.
Банкам же иногда просто наплевать на клиентов-физлиц, иногда они просто не успевают (в силу медлительности и серьезной бюрократии внутри). Ибо и среди админов там любители подставлять себя долго не задерживаются и вполне могут оказаться за факап на счетчике (в реалиях РФ) или должны огромную сумму по суду (в реалиях запада).
Допустим, Яндекс предоставляет корпоративную почту. По стандарту он не обязан её шифровать при передаче куда-либо (если, например, хост-получатель не поддерживает SMTPS и STARTTLS, то шифроваться ничего не будет и письмо пойдет по интернету plain text'ом). Надеюсь, что это не стало для вас открытием.
Соответственно, в договоре/SLA не может быть пункта, что они обязуются обеспечивать конфиденциальность почты клиента, если их юристы не любители ездить в лес в багажнике, конечно.
Медленное же обновление ключей и сертификатов на фронте — даёт некоторый риск утечки данных, но потери (в том числе, репутационные) могли посчитать меньшими, нежели от простоя в полдня.
Банкам же иногда просто наплевать на клиентов-физлиц, иногда они просто не успевают (в силу медлительности и серьезной бюрократии внутри). Ибо и среди админов там любители подставлять себя долго не задерживаются и вполне могут оказаться за факап на счетчике (в реалиях РФ) или должны огромную сумму по суду (в реалиях запада).
filippo.io/Heartbleed/#zerkala.ru
я проверил указанными сервисами и он отобразил уязвимость, как ее закрыть?
в пакетах последний openssl version -a
OpenSSL 0.9.8o 01 Jun 2010
built on: Mon Feb 11 20:54:08 UTC 2013
platform: debian-amd64
options: bn(64,64) md2(int) rc4(ptr,char) des(idx,cisc,16,int) blowfish(ptr2)
compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -O3 -Wa,--noexecstack -g -Wall -DMD32_REG_T=int -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM
OPENSSLDIR: "/usr/lib/ssl"
как я понял отсюда
launchpad.net/debian/+source/openssl/0.9.8o-4squeeze14
эта проблема не решена
я проверил указанными сервисами и он отобразил уязвимость, как ее закрыть?
в пакетах последний openssl version -a
OpenSSL 0.9.8o 01 Jun 2010
built on: Mon Feb 11 20:54:08 UTC 2013
platform: debian-amd64
options: bn(64,64) md2(int) rc4(ptr,char) des(idx,cisc,16,int) blowfish(ptr2)
compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -O3 -Wa,--noexecstack -g -Wall -DMD32_REG_T=int -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM
OPENSSLDIR: "/usr/lib/ssl"
как я понял отсюда
launchpad.net/debian/+source/openssl/0.9.8o-4squeeze14
эта проблема не решена
What versions of the OpenSSL are affected?
Status of different versions:
OpenSSL 1.0.1 through 1.0.1f (inclusive) are vulnerable
OpenSSL 1.0.1g is NOT vulnerable
OpenSSL 1.0.0 branch is NOT vulnerable
OpenSSL 0.9.8 branch is NOT vulnerable
>>Дистрибутивы с более ранними версиями OpenSSL: Debian Squeeze (oldstable), OpenSSL 0.9.8o-4squeeze14, SUSE Linux Enterprise Server.
Меня смутила эта строка. Так как она идет за перечислением дистрибутивов с уязвимыми версиями библиотеки, я воспринял что это продолжение списка. В моем случае используется Debian Squeeze и как видно в выводе — версия таки 0.9.8o, потому и вопрошаю на тему наличия проблемы и ее решения.
Меня смутила эта строка. Так как она идет за перечислением дистрибутивов с уязвимыми версиями библиотеки, я воспринял что это продолжение списка. В моем случае используется Debian Squeeze и как видно в выводе — версия таки 0.9.8o, потому и вопрошаю на тему наличия проблемы и ее решения.
Найдите автора исправления с ветки OpenSSL 1.0.0 на ветку OpenSSL 1.0.1 и отрежьте ему яйца.
Отзывайте свои SSL-сертификаты, генерируйте новые.
Правильно ли я понимаю, что:
- Отозвать можно только сертификаты для https. Сертификаты для ssh, pop3s, openvpn, etc. отозвать нельзя (а учитывая что в большинстве случаев они самоподписанные в отзыве/смене вообще никакого смысла нет).
- Отзыв/замена https сертификатов везде платная (вроде бы даже у startssl).
Отозвать можно любой x509 сертификат. Почему нет смысла отзывать, если сертификат самоподписной?
Правда, при использовании самоподписанных сертификатов обычно не генерят crl и не прописывают его в сертификат. И нет никакой проблемы в имперсонализации под атакуемого (имея старый сертификат и ключ) при MitM.
Да, я уже успел выключить panic mode и немного включить мозг.
Сертификаты для pop3s действительно это обычные сертификаты на домен, так что теоретически сервер может использовать один сертификат и для https и для pop3s/imaps, и его можно отозвать. Правда, лично я не уверен, что клиенты pop3/imap проверяют CRL… хотя только что глянул в доку fetchmail — вроде бы проверка есть если используется достаточно свежий openssl.
Самоподписанные отзывать имеет смысл только если вы можете проконтролировать что все ваши клиенты используют и корректно обновят кешированные fingerprint-ы самоподписанных ключей — что обычно нереально.
В случае ssh всё аналогично самоподписанному сертификату — перегенерить ключи сервера и все клиенты должны обновить ~/.ssh/known_hosts.
Для openvpn (в режиме shared key, например) нужно менять этот shared key.
Сертификаты для pop3s действительно это обычные сертификаты на домен, так что теоретически сервер может использовать один сертификат и для https и для pop3s/imaps, и его можно отозвать. Правда, лично я не уверен, что клиенты pop3/imap проверяют CRL… хотя только что глянул в доку fetchmail — вроде бы проверка есть если используется достаточно свежий openssl.
Самоподписанные отзывать имеет смысл только если вы можете проконтролировать что все ваши клиенты используют и корректно обновят кешированные fingerprint-ы самоподписанных ключей — что обычно нереально.
В случае ssh всё аналогично самоподписанному сертификату — перегенерить ключи сервера и все клиенты должны обновить ~/.ssh/known_hosts.
Для openvpn (в режиме shared key, например) нужно менять этот shared key.
Для openvpn (в режиме shared key, например) нужно менять этот shared key.
Не, shared key это не x509, так что уязвимости нет.
1. Если у вас pop3s, imaps, smtps и/или настроен starttls, то при уязвимой версии openssl ваши ключи потенциально утекли и их надо менять, вне зависимости от того, самоподписанный сертификат или нет. Дальнейший трафик потенциальный plain text.
2. Отзыв сертификата бывает как платным, так и бесплатным, даже в рамках одного CA. Смотрите policy своего CA, их faq etc
2. Отзыв сертификата бывает как платным, так и бесплатным, даже в рамках одного CA. Смотрите policy своего CA, их faq etc
Если издающий центр генерирует CRL и в конечных сертификатах прописан CDP, то отозвать конечный сертификат можно. Смысл не только в отзыве. сколько в перегенерации пары ключей, так как закрытый ключ мог быть скомпрометирован.
Я полагаю, что для малых сайтов вероятность того, что кто-то из тех, кто знал об этой уязвимости до широкого освещения, взломал ресурс и скомпрометировал закрытый ключ, очень мала.
Важно сейчас обновиться, когда все узнали об этой уязвимости.
Я полагаю, что для малых сайтов вероятность того, что кто-то из тех, кто знал об этой уязвимости до широкого освещения, взломал ресурс и скомпрометировал закрытый ключ, очень мала.
Важно сейчас обновиться, когда все узнали об этой уязвимости.
Платный отзыв сертификата — это фишка StartCom и одна из причин дешевизны.
ubuntu 12.04 LTS
тоже все в порядке, обновления пришли ночью, launchpad.net/ubuntu/+source/openssl/1.0.1-4ubuntu5.12
тоже все в порядке, обновления пришли ночью, launchpad.net/ubuntu/+source/openssl/1.0.1-4ubuntu5.12
Обновил, но проверка через представленный выше сервис говорит что все равно IS VULNERABLE
Что то еще забыл сделать? Перезапустил nginx разумеется.
Что то еще забыл сделать? Перезапустил nginx разумеется.
Самое интересное, что sid получил исправленную версию позже, чем wheezy-security.
Только что получил обновление в Ubuntu 14.04 с исправлением, теперь я в безопасности.
Держите нас в курсе.
По-моему достаточно важно, что команда популярного дистрибутива так оперативно закрыла уязвимость. Возможно, уже и в 12.04 обновление отправили.
Только что проверил — в 13.10 предлагают грейд до 1.0.1e.
Посмотрите список изменений, скорее всего бекпортировали исправления.
Да, вы правы —
changelogs.ubuntu.com/changelogs/pool/main/o/openssl/openssl_1.0.1e-3ubuntu1.2/changelog
CVE-2014-0076 + CVE-2014-0160
changelogs.ubuntu.com/changelogs/pool/main/o/openssl/openssl_1.0.1e-3ubuntu1.2/changelog
CVE-2014-0076 + CVE-2014-0160
Проблема же на серверной стороне, как я понял. Или у вас там web-сервер с https?
В Debian Wheezy пофиксили в 1.0.1e-2+deb7u5.
Точно?
$ date -R
Tue, 08 Apr 2014 08:05:08 +0400
$ rmadison libssl1.0.0 | cut -d'|' -f1-3
libssl1.0.0 | 1.0.1e-2+deb7u4 | wheezy
libssl1.0.0 | 1.0.1e-2+deb7u5 | wheezy-security
libssl1.0.0 | 1.0.1f-1 | jessie
libssl1.0.0 | 1.0.1f-1 | sid
libssl1.0.0 | 1.0.2~beta1-1 | experimentalUFO just landed and posted this here
Непонятно как эксплуатировать.
Поясните git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=4b7a4ba29cafa432fc4266fe6e59e60bc1c96332
Поясните git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=4b7a4ba29cafa432fc4266fe6e59e60bc1c96332
Из-за этой маленькой ошибки одного программиста кто угодно получает прямой доступ к оперативной памяти компьютеров, чьи коммуникации «защищены» уязвимой версией OpenSSL. В том числе, злоумышленник получает доступ к секретным ключам, именам и паролям пользователей и всему контенту, который должен передаваться в зашифрованном виде.А в advisory по ссылке: can be used to reveal up to 64k of memory. Причем скорее всего где-нибудь сразу за границей буфера.
Хотя видимо это перевод части heartbleed.com.
Ага, там ребята вроде грамотные.
There is no total of 64 kilobytes limitation to the attack, that limit applies only to a single heartbeat. Attacker can either keep reconnecting or during an active TLS connection keep requesting arbitrary number of 64 kilobyte chunks of memory content until enough secrets are revealed.
Даже если уязвимость позволяет запрашивать произвольные участки памяти, то максимум, что можно получить — это дамп памяти процесса, который обслуживает данное соединение. И видимо только запрашивать, а не писать в неё. Я бы не называл это «прямой доступ к оперативной памяти компьютеров», но видимо цель сайта — нагнать страху.
Как самый минимум — он позволяет стащить все приватные ключи и создавать сайты, которые будут выглядеть как легитимные — с зелёным замочком, правильным fingerprint'ом и прочими аттрибутами.
Только в том случае, если последний присутствует в памяти процесса, что в общем-то не обязательно после установки соединения.
Ну как пример, в Yahoo можно дампить пароли пользователей:
pbs.twimg.com/media/Bksw9k_CAAAy8ln.png:large
pbs.twimg.com/media/Bksw9k_CAAAy8ln.png:large
Безусловно это в определенной степени минус асинхронных серверов, где обработка всех запросов происходит в одном процессе. Они более уязвимы к подобного рода ошибкам.
Yahoo наверняка используют свой асинхронный Traffic Server.
Yahoo наверняка используют свой асинхронный Traffic Server.
У вас один и тот же процесс (форк) Апача может обрабатывать со временем запросы разных пользователей. При этом в памяти, остаться «старый» мусор. Она же (память) нулями не забивается.
Это да, но от этого можно защититься относительно легко, и в тех случаях, где повышенные требования безопасности, имеет смысл включать PAX_MEMORY_SANITIZE.
Ну вот кстати хз, PAX_MEMORY_SANITIZE помогает «зачищать» свободную память, но не молниеносно, но тут надо потестить. К тому же импакт на перфоманс 3%. Не много, конечно. В целом же я согласен — PAX сила)
Он же в виде сторонних патчей живёт, а не master?
Да, это отдельный проект.
Ванильное ядро вообще мало кто использует. У меня на сервере Hardened Gentoo и там PaX (а также много других security-related вкусностей) из коробки.
Ванильное ядро вообще мало кто использует. У меня на сервере Hardened Gentoo и там PaX (а также много других security-related вкусностей) из коробки.
Вы не проверяли, с PAX_MEMORY_SANITIZE обсуждаемая уязвимость работает? А то я, непроверяя сразу все обновил :)
UFO just landed and posted this here
В общем да, поэтому я выше и указал, что сервера, в которых в одном процессе обрабатывается много всего, наиболее восприимчивы к подобного рода уязвимостям.
Я не исследовал вопрос, и пока для меня остается загадкой, каким образом столько важной информации оказывается в пределах 64-килобайт от буфера, в который считывается heartbeat запрос. В зависимости от этого, можно было бы предположить, что какая-нибудь техника потенциально могла бы защитить от уязвимости, если и не полностью, то хотя бы уменьшить шансы получить в ответ что-то ценное.
Я не исследовал вопрос, и пока для меня остается загадкой, каким образом столько важной информации оказывается в пределах 64-килобайт от буфера, в который считывается heartbeat запрос. В зависимости от этого, можно было бы предположить, что какая-нибудь техника потенциально могла бы защитить от уязвимости, если и не полностью, то хотя бы уменьшить шансы получить в ответ что-то ценное.
Это как раз очевидно — классика Use-After-Free:
//юзер 1 пришел
a = malloc(size)
write(a,SECRET_FROM_USER_1);
free(a)
//… юзер 1 ушел. пришел второй запрос в тот же процесс, но уже от второго юзера.
b= malloc(size)
read(b,size)
А теперь Вы спрашиваете почему в b будет SECRET_FROM_USER_1
//дублирую комент, потому что развелось что-то одинаковых тем ((
//юзер 1 пришел
a = malloc(size)
write(a,SECRET_FROM_USER_1);
free(a)
//… юзер 1 ушел. пришел второй запрос в тот же процесс, но уже от второго юзера.
b= malloc(size)
read(b,size)
А теперь Вы спрашиваете почему в b будет SECRET_FROM_USER_1
//дублирую комент, потому что развелось что-то одинаковых тем ((
это не use-after-free. Это в первом пользователе — забыли занулить важные данные, просто освободили память, а во втором — читали из только что выделенной памяти, в которой может быть любой мусор. В данном случае, этот мусор — то, что не было подчищено перед free.
use-after-free — это
free(a)
read(a)
то есть, читаем (или пишем) область, которую вроде как уже освободили
use-after-free — это
free(a)
read(a)
то есть, читаем (или пишем) область, которую вроде как уже освободили
Они походу вообще спят еще — до сих пор открыто, логины-пароли почти в каждом пакете есть…
alizar же
Насколько понял, squeeze и lenny в безопасности? В squeeze 0.9.8 а ленни и куда меньше.
lenny же снят с поддержки, нет? То есть оно «не в безопасности» никаким образом.
Снятие с поддержки не мешает Lenny быть на порядки безопаснее всех «поддерживаемых» дистрибутивов, которые были компрометированы на 100%.
P.S. Имелся в виду именно данный конкретный баг, а не общая ситуация, разумеется :)
С учётом числа закрытых CVE, данный конкретный баг уже не интересен. Если у человека до сих пор ленни задницей в интернеты смотрит, то я бы остерёгся на такой системе что-либо держать.
Ну со времен ленни такой крупнячок впервые =) я не говорю, что стоит сидеть на старых дистрах без поддержки, я лишь говорю о том, что на фоне данного бага меркнет даже устаревший на несколько лет и неподдерживаемый дистрибутив, ибо баг-то remote, а не очередной CVE на фикс локальной эскалации возможной лишь в високосный год на Марсе.
Странно, что написали про бздю 9.1. Там идет 0.9.8х. Хотя может 9.2 позже? 10ка идет с 1.0.1е
В CentOS 5.x — 0.9.8e — можно курить в сторонке )
Это да, там даже update не подтягивает «нужную» версию.
А вот CentOS 6.5 даже в updates выдает 1.0.1e-16.el6_5.7
А вот CentOS 6.5 даже в updates выдает 1.0.1e-16.el6_5.7
Так посмотрите changelog:
rpm -q --changelog openssl
* Mon Apr 07 2014 Tomáš Mráz <tmraz@redhat.com> 1.0.1e-16.7
— fix CVE-2014-0160 — information disclosure in TLS heartbeat extension
rpm -q --changelog openssl
* Mon Apr 07 2014 Tomáš Mráz <tmraz@redhat.com> 1.0.1e-16.7
— fix CVE-2014-0160 — information disclosure in TLS heartbeat extension
:(
Блин!!!
google.ru IS VULNERABLE.
Here is some data we pulled from the server memory:
(we put YELLOW SUBMARINE there, and it should not have come back)
([]uint8) {
00000000 02 00 79 68 65 61 72 74 62 6c 65 65 64 2e 66 69 |..yheartbleed.fi|
00000010 6c 69 70 70 6f 2e 69 6f 68 65 61 72 74 62 6c 65 |lippo.ioheartble|
00000020 65 64 2e 66 69 6c 69 70 70 6f 2e 69 6f cf 83 68 |ed.filippo.io..h|
00000030 17 89 f9 98 0f fc 87 4c 91 f0 e3 95 d3 01 99 87 |.......L........|
00000040 7f e8 de e4 c1 c1 27 b0 f4 a3 37 ce c9 62 80 76 |......'...7..b.v|
00000050 93 aa df 17 a6 3a 93 a2 c9 c3 4e cc ed e0 a1 cf |.....:....N.....|
00000060 73 b2 2b 9c b3 d6 5c d5 ec 24 e2 4a 41 8b 3d bd |s.+...\..$.JA.=.|
00000070 b2 18 d3 32 7f 86 dc cf 11 63 27 8f 90 48 f7 73 |...2.....c'..H.s|
00000080 54 32 00 a8 8e dc b6 1a ff 5c 2f 0c |T2.......\/.|
}
Как теперь быть? :-(
google.ru IS VULNERABLE.
Here is some data we pulled from the server memory:
(we put YELLOW SUBMARINE there, and it should not have come back)
([]uint8) {
00000000 02 00 79 68 65 61 72 74 62 6c 65 65 64 2e 66 69 |..yheartbleed.fi|
00000010 6c 69 70 70 6f 2e 69 6f 68 65 61 72 74 62 6c 65 |lippo.ioheartble|
00000020 65 64 2e 66 69 6c 69 70 70 6f 2e 69 6f cf 83 68 |ed.filippo.io..h|
00000030 17 89 f9 98 0f fc 87 4c 91 f0 e3 95 d3 01 99 87 |.......L........|
00000040 7f e8 de e4 c1 c1 27 b0 f4 a3 37 ce c9 62 80 76 |......'...7..b.v|
00000050 93 aa df 17 a6 3a 93 a2 c9 c3 4e cc ed e0 a1 cf |.....:....N.....|
00000060 73 b2 2b 9c b3 d6 5c d5 ec 24 e2 4a 41 8b 3d bd |s.+...\..$.JA.=.|
00000070 b2 18 d3 32 7f 86 dc cf 11 63 27 8f 90 48 f7 73 |...2.....c'..H.s|
00000080 54 32 00 a8 8e dc b6 1a ff 5c 2f 0c |T2.......\/.|
}
Как теперь быть? :-(
Эхх…
All good, store.steampowered.com seems not affected!
steamcommunity.com IS VULNERABLE.
store.origin.com IS VULNERABLE.
steamcommunity.com IS VULNERABLE.
store.origin.com IS VULNERABLE.
Как это понимать? :) 
Обновил в Убунте openssl до 1.0.1-4ubuntu5.12.
Проверяльшик всё равно говорит «IS VULNERABLE».
Проверяльшик всё равно говорит «IS VULNERABLE».
libssl ещё надо было обновить
Обновил openssl и libssl1.0.0. Тест все равно говорит о уязвимости.
Ubuntu, Apache2.
Индейца перезапустил.
Куда еще посмотреть?
Ubuntu, Apache2.
Индейца перезапустил.
Куда еще посмотреть?
А что выдаёт openssl version -a?
# openssl version -a
OpenSSL 1.0.1 14 Mar 2012
built on: Mon Apr 7 20:33:29 UTC 2014
platform: debian-amd64
options: bn(64,64) rc4(16x,int) des(idx,cisc,16,int) blowfish(idx)
compiler: cc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions -Wl,-z,relro -Wa,--noexecstack -Wall -DOPENSSL_NO_TLS1_2_CLIENT -DOPENSSL_MAX_TLS1_2_CIPHER_LENGTH=50 -DMD32_REG_T=int -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
OPENSSLDIR: "/usr/lib/ssl"
OpenSSL 1.0.1 14 Mar 2012
built on: Mon Apr 7 20:33:29 UTC 2014
platform: debian-amd64
options: bn(64,64) rc4(16x,int) des(idx,cisc,16,int) blowfish(idx)
compiler: cc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions -Wl,-z,relro -Wa,--noexecstack -Wall -DOPENSSL_NO_TLS1_2_CLIENT -DOPENSSL_MAX_TLS1_2_CIPHER_LENGTH=50 -DMD32_REG_T=int -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
OPENSSLDIR: "/usr/lib/ssl"
Тут всё нормально. Может в Апач что-то вкомпилено? Я nginx использую.
Самое веселое то, что если тыкать постоянно проверку, то рано или поздно выдает, что все ок. Потом снова fail.
Подтверждаю. Там выше был другой проверяльщик. Надо бы его попробовать.
Тот постоянно говорит fail. Даже на те, где первый тест говорит ок.
А вот это вообще 5: picpost.pp.ua/big/369fd468969781b4b219f38212ec7de8.jpeg
There are load (?) issues causing FALSE POSITIVES.
Please read the FAQ
filippo.io/Heartbleed/faq.html#loadissue
Meanwhile you can use the command line tool that is completely unaffected.
github.com/FiloSottile/Heartbleed
Вы веб-сервер перезапустили?
ldd $(which apache) | grep -e libssl -e libcrypt
У меня в Debian, например, почти все используют libssl 1.0.0, а вот OpenVPN 0.9.8, об этом тоже забывать нельзя.
ldd $(which apache) | grep -e libssl -e libcrypt
У меня в Debian, например, почти все используют libssl 1.0.0, а вот OpenVPN 0.9.8, об этом тоже забывать нельзя.
Выше вроде написал, что перезапустил.
# ldd $(which apache2) | grep -e libssl -e libcrypt
libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x00007f81f5353000)
# dpkg -l | grep libssl
ii libssl1.0.0 1.0.1-4ubuntu5.12 SSL shared libraries
Т.е. фактически у меня одна библиотека. Другой просто нет.
# ldd $(which apache2) | grep -e libssl -e libcrypt
libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x00007f81f5353000)
# dpkg -l | grep libssl
ii libssl1.0.0 1.0.1-4ubuntu5.12 SSL shared libraries
Т.е. фактически у меня одна библиотека. Другой просто нет.
А сделайте dpkg -S /lib/x86_64-linux-gnu/libcrypt.so.1
и ldd $(which apache2) | grep -e tls
и ldd $(which apache2) | grep -e tls
# dpkg -S /lib/x86_64-linux-gnu/libcrypt.so.1
libc6: /lib/x86_64-linux-gnu/libcrypt.so.1
# ldd $(which apache2) | grep -e tls
libc6: /lib/x86_64-linux-gnu/libcrypt.so.1
# ldd $(which apache2) | grep -e tls
Я apache почти ни разу не использовал, но, если не ошибаюсь, там ssl модулем? Какой-нибудь mod_ssl? Попробуйте его найти и на нем ldd использовать.
# ldd /usr/lib/apache2/modules/mod_ssl_with_npn.so | grep -e tls
# ldd /usr/lib/apache2/modules/mod_ssl_with_npn.so | grep -e libssl -e libcrypt
libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x00007f6fb0f6b000)
# ldd /usr/lib/apache2/modules/mod_ssl_with_npn.so | grep -e libssl -e libcrypt
libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x00007f6fb0f6b000)
Нашел виновника:
# apt-get remove mod-spdy-beta
И все стало хорошо!
# apt-get remove mod-spdy-beta
И все стало хорошо!
Это неправильный метод.
Пересобрать openssl недостаточно. Надо еще пересобрать nginx с указанием исходников нового openssl, указав опцию --with-openssl, тогда все будет хорошо.
Пересобрать openssl недостаточно. Надо еще пересобрать nginx с указанием исходников нового openssl, указав опцию --with-openssl, тогда все будет хорошо.
При чем тут исходники? Я где-то писал о них?
Более того, я о nginx ни слова не написал!
Проблема в конкретном модуле Апача. Возможно он содержит свою реализацию SSL.
Более того, я о nginx ни слова не написал!
Проблема в конкретном модуле Апача. Возможно он содержит свою реализацию SSL.
SPDY модуль собран (не вами) со старой версией OpenSSL, и надо его пересобрать, указав ему на новые исходники OpenSSL.
Именно так я сделал для nginx, для апача все должно быть аналогично.
Именно так я сделал для nginx, для апача все должно быть аналогично.
Мне проще отказаться от SPDY в Апаче. Не те у нас нагрузки, чтоб думать об этом.
Разве nginx линкует openssl статически? Если нет — то зачем его пересобирать?
Nginx содержит модуль spdy, который зависит от OpenSSL. Выше человек «решил» проблему, просто отключив spdy, а правильнее — пересобрать его. Ваш К.О.
Зависимость от модуля не означает статической линковки. Nginx в нормальных сборках линкует libssl динамически (libssl.so — это openssl).
Проверяется элементарно:
Проверяется элементарно:
ldd `which nginx` |grep ssl
# libssl.so.10 => /usr/lib64/libssl.so.10 (0x00007fc2b37ac000)
yum whatprovides '/usr/lib64/libssl.so.10'
# openssl-1.0.1e-16.el6_5.7.x86_64 : A general purpose cryptography library with TLS implementation
# Repo : installed
# Matched from:
# Other : Provides-match: /usr/lib64/libssl.so.10
Тип линковки с OpenSSL не зависит от включени/выключения spdy. Более того, модуль spdy может быть собран и работать вообще без OpenSSL. Также как и spdy модуля может не быть вовсе, а будет уязвима конфигурация с https. Иными словами, SPDY к проблеме использования OpenSSL полностью иррелевантен.
Чаще всего nginx линкуется с системной OpenSSL и в этом случае достаточно обновить системную библиотеку, а затем перезапустить или выполнить обновление исполняемого файла nginx на лету.
Статически nginx слинкован с OpenSSL (при помощи опции
See also: nginx.com/blog/nginx-and-the-heartbleed-vulnerability/
Чаще всего nginx линкуется с системной OpenSSL и в этом случае достаточно обновить системную библиотеку, а затем перезапустить или выполнить обновление исполняемого файла nginx на лету.
Статически nginx слинкован с OpenSSL (при помощи опции
--with-openssl=/path/to/sources или флагов компиляции) в основном у горе энтузиастов, которые собирают его из исходников.See also: nginx.com/blog/nginx-and-the-heartbleed-vulnerability/
Такая же фигня. Обновил на убунту-сервере оба пакета, рестартнул nginx и apache, а filippo.io/Heartbleed/ все равно показывает уязвимость.
«Зелененькие» у меня только сервера со старенькой Debian Squeeze и неподключенным репозиторием с бэкпортами из Wheezy. Соответственно версия там 0.9.8
«Зелененькие» у меня только сервера со старенькой Debian Squeeze и неподключенным репозиторием с бэкпортами из Wheezy. Соответственно версия там 0.9.8
После обновления пакета надо сервис обязательно рестартить.
Когда уже этот OpenSSL выкинут и забросят?
Там присутствует столько скрытых уязвимостей, что мама не горюй. И никогда это не поправят (те кто смотрел исходники поймут о чём я)
Там присутствует столько скрытых уязвимостей, что мама не горюй. И никогда это не поправят (те кто смотрел исходники поймут о чём я)
Отправьте pull request, сделайте мир чуточку лучше.
Посмотрите исходники, потом говорите о pull request.
Это не исправляется, это лишь переписывается полностью.
Это не исправляется, это лишь переписывается полностью.
Не будьте голословны — напишите статью с примерами.
OpenSSL действительно написан достаточно плохо, тут я SowingSadness поддерживаю. О нем давно плохо говорят. Моя любимая статья на эту тему: OpenSSL is written by monkeys
Ненависть к openssl видна уже по невалидному сертификату при заходе на сайт.
Есть даже Твиттер-аккаунт OpenSSL Fact, где в течение года каждый день писали по одной ужасной строчке из исходного кода OpenSSL.
Всего 365 ужасных строк? Разве это такой плохой код? (И разве это был такой плохой год?)
Т.е. в вашем проекте ужасных строк гораздо больше, чем 365?
Там файлами по 2000 строк можно писать.
Вы попробуйте поработать с OpenSSL как с чёрным ящиком.
Даже нормальной справки по его аргументам нет, каждое действие превращается в набор магических аргументов, при чём в различных случаях они ведут себя по разному.
Например "-in" в некоторых случаях принимает сертификат лишь в der виде, а в некоторых как в pem так и в der виде.
В одних случаях прямое указание "-inform PEM/DER" работает, в других нет.
Вы попробуйте поработать с OpenSSL как с чёрным ящиком.
Даже нормальной справки по его аргументам нет, каждое действие превращается в набор магических аргументов, при чём в различных случаях они ведут себя по разному.
Например "-in" в некоторых случаях принимает сертификат лишь в der виде, а в некоторых как в pem так и в der виде.
В одних случаях прямое указание "-inform PEM/DER" работает, в других нет.
А что известно про качество GnuTLS?
Господа, а openssl 1.0.1.f-2 из Arch содержит эту уязвимость или нет? Я так понимаю на рабочих станциях тоже непременно надо openssl обновить. Речь же не только о серверах идет.
Содержит. Сегодня .g-1 пришел.
Причем, внимание, уязвимость двусторонняя: если вы подключитесь с уязвимой библиотекой к специальному серверу, эксплотирующему уязвимость, с вашего компьютера могут подампить память (браузера, например).
Спасибо, обновился. У меня репы manjaro подключены — там еще нету обновления. Подключил с kernel.org
Уже есть PoC.
Кто еще хочет посмеяться над сетевыми параноиками?
Утилька обламывает зубы, когда сталкивается с ГОСТовым сертификатом.
Тільки російське, тільки хардкор!
там нет ssl на этом домене
ssl там похоже есть, но хром его не открывает
ERR_SSL_VERSION_OR_CIPHER_MISMATCH
а коннект на 443 порт устанавливается
свой интернет придумали. классно.
ERR_SSL_VERSION_OR_CIPHER_MISMATCH
а коннект на 443 порт устанавливается
свой интернет придумали. классно.
Вам же выше уже сказали, что там используется шифрование ГОСТ. На что вы рассчитывали-то?
UFO just landed and posted this here
Мой комментарий относился не к уязвимости, а к попытке dewil сходить на этот порт браузером («свой интернет придумали»). В абсолютном большинстве известных мне дистрибутивов Linux для этого нужно openssl пересобрать, в прочих ОС это ничуть не легче.
Ой, как все по поводу OpenSSL переживают. Я так просто, а то никто и не знает, что мы тоже этот проект проверяли: Немного про OpenSSL. Правда уже давно.
И вы, разумеется, свои наблюдения отправили в проект OpenSSL и завели багрепорты?
К своим комментариям то-же что ли начать FAQ в конце приписывать. :)
А тогда проще не писать, по Вашему FAQ Вы ни за что ответственности не несете и вообще может «и не баг нашли». А тут Вы как раз четко утверждаете — «решето», а когда задаются предметные вопросы ссылаетесь на FAQ с отказом от конкретики и ответственности. Не надо так :)
Господи, что-то Вы там себе навыдумывали… Ничего я не утверждаю… Ответственность какая-то… Брр…
Я прост мимо проходил. Ссылку оставил, вдруг кому-то интересно. Не более.
Я прост мимо проходил. Ссылку оставил, вдруг кому-то интересно. Не более.
Вот если бы Вы этот баг нашли из темы — вот это была бы крутая реклама, а старые и давние исследования… они тлен :)
Думаю, среди всего этого, найдётся парочка знатных epic-fail связанных с уязвимостью. Вот только у меня нет знаний о каждом из проектов, чтобы понять, является ли какая-то из ошибок уязвимостью и насколько серьезной. Ну а авторам, если они вдруг найдут серьезную ошибку благодаря PVS-Studio, тоже нет смысла кричать про это на весь свет. Исправят тихо и всё.
Вы серьезно?
А почему бы и нет? Сейчас в базе 1389 примеров кода, обнаруженных в 174 проектах. Плюс, часто указано, что помимо приведённого примера, такую ошибку можно встретить здесь, здесь и вот здесь. Итого, наберётся под 3 тысячи ошибок и потенциальных дефектов.
P.S. И после этого злые языки говорят, что мы мало для Open Source делаем. :)
P.S. И после этого злые языки говорят, что мы мало для Open Source делаем. :)
А что, Вы, простите, делаете? Детектируете такие вот «ошибки»?
Ошибки, обнаруженные в Open Source проектах разработчиками PVS-Studio с помощью статического анализа
Мы регулярно проверяем различные open-source проекты с помощью PVS-Studio. Результаты проверки мы отправляем разработчикам и, как правило, описываем в статье. Помимо этого, мы пополняем базу примеров ошибок. Именно она и представлена ниже на этой странице.
Ошибки разделены по номеру диагностического сообщения, с помощью которого они были найдены. В правом столбце приводится ссылка на соответствующие примеры ошибок.
Мы специально не стали делать возможность посмотреть все ошибки, найденные в конкретном проекте. Это даст неправильное впечатление о количестве ошибок в проекте и возможностях анализатора. Анализатор быстро развивается. Если он нашёл 10 ошибок в проекте год назад, вовсе не означает, что он найдет столько же ошибок и сейчас. Сравните для примера отчеты о проверке ReactOS: первый отчет, второй отчет (прошло полтора года).
Вы можете предложить нам для проверки другие open-source проекты. Типы проектов, которые умеет проверять PVS-Studio, приведены в описании инструмента.
Эта база может послужить уникальным материалом для размышлений о разработке стандартов кодирования, написания статей о правилах программирования и помочь в других исследованиях связанных с повышением надежности программного обеспечения. Желаем интересных исследований.
---------------------------------------
Вы не считаете это ошибкой? Тогда у меня для Вас плохие новости.
Кстати, сейчас этот код уже исправлен:
Мы регулярно проверяем различные open-source проекты с помощью PVS-Studio. Результаты проверки мы отправляем разработчикам и, как правило, описываем в статье. Помимо этого, мы пополняем базу примеров ошибок. Именно она и представлена ниже на этой странице.
Ошибки разделены по номеру диагностического сообщения, с помощью которого они были найдены. В правом столбце приводится ссылка на соответствующие примеры ошибок.
Мы специально не стали делать возможность посмотреть все ошибки, найденные в конкретном проекте. Это даст неправильное впечатление о количестве ошибок в проекте и возможностях анализатора. Анализатор быстро развивается. Если он нашёл 10 ошибок в проекте год назад, вовсе не означает, что он найдет столько же ошибок и сейчас. Сравните для примера отчеты о проверке ReactOS: первый отчет, второй отчет (прошло полтора года).
Вы можете предложить нам для проверки другие open-source проекты. Типы проектов, которые умеет проверять PVS-Studio, приведены в описании инструмента.
Эта база может послужить уникальным материалом для размышлений о разработке стандартов кодирования, написания статей о правилах программирования и помочь в других исследованиях связанных с повышением надежности программного обеспечения. Желаем интересных исследований.
---------------------------------------
#define EVP_PKT_SIGN 0x0010
int ssl3_get_cert_verify(SSL *s)
{
int type=0, i, j;
....
if ((peer != NULL) && (type | EVP_PKT_SIGN))
....
}
Вы не считаете это ошибкой? Тогда у меня для Вас плохие новости.
Кстати, сейчас этот код уже исправлен:
if ((peer != NULL) && (type & EVP_PKT_SIGN))
Стат. анализом такие ошибки найти практически не возможно, ну почти-почти… Так что ваш сканер не помог бы. Но больше рекламы и ПР не повредит, верно? 8))
«Один программист» редиска, конечно.
Но, там код-ревью и всё такое? За 2 года никто не проверил?
Но, там код-ревью и всё такое? За 2 года никто не проверил?
alfabank.ru IS VULNERABLE.
online.rsb.ru IS VULNERABLE.
connect.raiffeisen.ru IS VULNERABLE.
И это не единственные банки с уязвимостью…
Какое странное совпадение.
Все сайты Хроноса лежат.
opengl.org/cgi-sys/defaultwebpage.cgi
https://opengl.org/ — в Firefox «SSL received a record that exceeded the maximum permissible length».
А если открыть какую-нибудь страницу: khronos.org/opengles/sdk/docs/man/
Apache/2.2.27 (Unix) mod_ssl/2.2.27 OpenSSL/1.0.1e-fips mod_bwlimited/1.4 Server at khronos.org Port 80
Все сайты Хроноса лежат.
opengl.org/cgi-sys/defaultwebpage.cgi
https://opengl.org/ — в Firefox «SSL received a record that exceeded the maximum permissible length».
А если открыть какую-нибудь страницу: khronos.org/opengles/sdk/docs/man/
Apache/2.2.27 (Unix) mod_ssl/2.2.27 OpenSSL/1.0.1e-fips mod_bwlimited/1.4 Server at khronos.org Port 80
А кто может подсказать как собрать OpenSSL для Synology? Вряд ли они сами в ближайшее время соберутся.
а может быть чтобы они побыстрее собирались — идти на myds.synology.com/ и писать про эту проблему?
хотя… сам myds тоже уязвим…
хотя… сам myds тоже уязвим…
Объясните неспециалисту — этот баг касается только https веб-серверов? Если у меня сайт, не использующий https протокол — нужно ли мне обновляться прямо сейчас? В данный момент у нас активна рекламная и PR кампания, и отключать сайт ну очень уж не хотелось бы (прямые потери денег). Уязвимы ли еще какие-то службы помимо веб-сервера с https?
Все, что использует TLS. OpenVPN в x509 режиме, например.
Спасибо за комментарий. VPN у нас на сервере нет. Есть обычный LAMP + Postgres + MySQL + Python + Ruby + Nginx. Естественно, есть доступ по SSH, но выше вроде написали что SSH не затрагивает данная уязвимость. В общем, у нас обычный сервер для хостинга веб-сайтов. Нужно ли обновляться прямо сейчас?
Правильно понимаю, что для OpenVPN нужно проверять только опцию:
# For extra security beyond that provided
# by SSL/TLS, create an «HMAC firewall»
# to help block DoS attacks and UDP port flooding.
#
# Generate with:
# openvpn --genkey --secret ta.key
#
# The server and each client must have
# a copy of this key.
# The second parameter should be '0'
# on the server and '1' on the clients.
;tls-auth ta.key 0 # This file is secret
и если она отключена, то TLS не используется?
# For extra security beyond that provided
# by SSL/TLS, create an «HMAC firewall»
# to help block DoS attacks and UDP port flooding.
#
# Generate with:
# openvpn --genkey --secret ta.key
#
# The server and each client must have
# a copy of this key.
# The second parameter should be '0'
# on the server and '1' on the clients.
;tls-auth ta.key 0 # This file is secret
и если она отключена, то TLS не используется?
Ранее сохраненный траффик возможно будет расшифровать? Еще веселее. Кто-то уже напевает «вот, наконец, настал тот час...»
Здравствуйте, я представляю компанию Qrator Labs. В данный момент мы осуществляем фильтрацию трафика для Хабрахабра, и все запросы к Хабру проходят через наши точки фильтрации.
Сеть Qrator не поддерживает TLS Heartbeats, поэтому CVE-2014-0160 на неё не распространяется. На данный момент, исходя из вашей информации, мы можем предположить какую-то проблему с DNS-записями. Могу я попросить вас прислать мне в личном сообщении ваш внешний IP-адрес? Это необходимо нам для расследования причин.
Также, если есть возможность, сообщите, пожалуйста, воспроизводится ли уязвимость в данный момент. Заранее спасибо!
Сеть Qrator не поддерживает TLS Heartbeats, поэтому CVE-2014-0160 на неё не распространяется. На данный момент, исходя из вашей информации, мы можем предположить какую-то проблему с DNS-записями. Могу я попросить вас прислать мне в личном сообщении ваш внешний IP-адрес? Это необходимо нам для расследования причин.
Также, если есть возможность, сообщите, пожалуйста, воспроизводится ли уязвимость в данный момент. Заранее спасибо!
mail.ru затронут, лол
Утилита filippo.io/Heartbleed/ ругается даже на майкрософтовские VPN-сервера. Как так?
GLSA
Ну как так!? Дырка в OpenSSL — это Normal, а вот уязвимость в сраном mail-client/roundcube, app-office/texmacs или net-fs/openafs (ещё поискать систему надо, где оно использовалось бы) — High!
Ну как так!? Дырка в OpenSSL — это Normal, а вот уязвимость в сраном mail-client/roundcube, app-office/texmacs или net-fs/openafs (ещё поискать систему надо, где оно использовалось бы) — High!
Рискну предположить, что уровень уязвимости локален для пакета. Ведь ни один из программистов, сопровождающих mail-client/roundcube, не бросится заделывать дырку в OpenSSL?
Это берется из CVE. Там есть критерии, но если очень коротко, то нет RCE, значит medium.
RedHat поставил 'Important' 8)
У debian тоже important
$ aptitude show libssl1.0.0 | grep -e "Prio\|Ver"
Version: 1.0.1e-2+deb7u6
Priority: important
Priority != Severity
У CVE-2014-0160 CVSS 5 из 10 возможных.
У CVE-2014-0160 CVSS 5 из 10 возможных.
CVSS2 — унылость, но ред хат свою классификацию значимости патча основывает именно на нём, но насколько я понимаю со «своей оценкой CVSS»
В смысле apt — это можно сказать одна масть, отдельного поля для Severity там не предусмотрено.
У меня есть на некоторых серверах daily cron, который отсылает мне мылом статистику по возможным update сгруппированых по Priority — до сих пор не обманывал: все что я до сих пор видел important, было из этой вот оперы.
У меня есть на некоторых серверах daily cron, который отсылает мне мылом статистику по возможным update сгруппированых по Priority — до сих пор не обманывал: все что я до сих пор видел important, было из этой вот оперы.
Особо круто видеть тех, кто сидит на амазоне. Там SSL на лоад балансере, который уязвим. Другими словами ВСЕ сервисы, кто в облаке Амазона, должны ждать, пока Амазон не исправит ситуацию с ELB. Вот она игла зависимости 8)
Вот два треда на форумах AWS об этом:
Тред про классические серверы.
Тред про ELB балансер.
Вкратце, sudo yum clean all а затем sudo yum update openssl обновит до версии 1:1.0.1e-37.66, которая, несмотря на буковку е, включает в себя фикс бага CVE-2014-0160.
Тред про классические серверы.
Тред про ELB балансер.
Вкратце, sudo yum clean all а затем sudo yum update openssl обновит до версии 1:1.0.1e-37.66, которая, несмотря на буковку е, включает в себя фикс бага CVE-2014-0160.
Да, как «жертва» ситуации я в курсе этих тредов.
Про AMI — понятно и так.
А вот про ELB — игла зависимости.
Последний пост (на текущий момент) из треда про ELB:
И далее по ссылке:
Уже как бы много времени прошло)
Про AMI — понятно и так.
А вот про ELB — игла зависимости.
Последний пост (на текущий момент) из треда про ELB:
We are currently working to mitigate the impact of this issue and will provide further updates, please see: aws.amazon.com/security/security-bulletins/heartbleed-bug-concern/
И далее по ссылке:
April 7, 2014
AWS is aware of the HeartBleed Bug (CVE-2014-0160) in OpenSSL and investigating any impact or required remediation. We will post back when we have more detail.
Уже как бы много времени прошло)
Хотелось бы грязных технических деталей.
Где-нибудь уже есть, чтобы понятно было расписано, что представляет собой баг?
Где-нибудь уже есть, чтобы понятно было расписано, что представляет собой баг?
Так давно в Инете все есть: blog.existentialize.com/diagnosis-of-the-openssl-heartbleed-bug.html
Спасибо, почитаю на досуге)
Перевёл: habrahabr.ru/post/218691/
Ну и где усиральщики которые доказывают что опенсоус это круто и безопасно за счет открытых кодов? Я хочу харкнуть в лицо этим людям. Чо за отмазка «там стремный код»? Эта хрня в каждом продукте, а он дырявый как сыр. Давайте начнем сбор денег на отрывание рук тому кто эту закладку там сделал. Может тогда дыр станет меньше.
Никогда не видел настолько заминусованной страницы комментариев.
Вот как им верить? Только что сам через хартблид проверил — да, пишет то же, что и вам. Но комманд-лайновая чекалка:
(для дырявых серверов она длииинные портянки пишет, а тут только 2 байта). Ну и possible.lv/tools/hb/?domain=rbkmoney.ru пишет, что хартбит фича есть, но бага в ней на этом сервере нет.
В общем, как по мне — этот сервис хартблид — скажем так, иногда заблуждается. тут выше примеров немало.
xenon@dot:/tmp$ ./ssltest.py rbkmoney.ru -p 443
Connecting...
Sending Client Hello...
Waiting for Server Hello...
... received message: type = 22, ver = 0301, length = 58
... received message: type = 22, ver = 0301, length = 4874
... received message: type = 22, ver = 0301, length = 4
Sending heartbeat request...
... received message: type = 21, ver = 0302, length = 2
Received alert:
0000: 02 46 .F
Server rbkmoney.ru returned error, likely not vulnerable
(для дырявых серверов она длииинные портянки пишет, а тут только 2 байта). Ну и possible.lv/tools/hb/?domain=rbkmoney.ru пишет, что хартбит фича есть, но бага в ней на этом сервере нет.
В общем, как по мне — этот сервис хартблид — скажем так, иногда заблуждается. тут выше примеров немало.
Кроме линуксов ей подвержены VMware ESXi 5.5 и 5.5 U1, а также IBM Endpoint Manager 9.1.
С учетом того, что интернет-проверялки не залазят во внутреннюю сеть, утилиты для проверки — хоть и опенсорсные, но работают «автомагическим» образом (я вот, например, не очень уверен, что в ssltest.py означают хексовые значения для hello и hb и нет ли в них другого эксплойта и шеллкода или может просто ошибки, из-за которой они могут не заметить дырку или сделать ложное срабатывание), в общем, кое что можно просто и без магии:
Естественно, для -host и -port — свои значения (проверять, кстати, надо не только https но и всю почту smtp/pop3/imap через SSL (на специальных портах) и через STARTTLS (на обычных). К счастью openssl и это может:
Что тут важно понимать — не уязвимы два типа систем — те, что еще не имеют этой фичи (heartbeat TLS extension) и те, что уже пофиксили. Эти команды просто показывают список предоставляемых TLS extension. Если heartbeat не перечислен — 100% система не уязвима для этой атаки. Если перечислен — то может быть уязвима. В этом случае, если последнее обновление было… «не помню когда, но я однажды обновлял» — то обновляться надо — дырка есть.
echo | openssl s_client -tlsextdebug -host mail.google.com -port 443|grep "TLS server extension"
Естественно, для -host и -port — свои значения (проверять, кстати, надо не только https но и всю почту smtp/pop3/imap через SSL (на специальных портах) и через STARTTLS (на обычных). К счастью openssl и это может:
echo | openssl s_client -tlsextdebug -connect smtp.yandex.ru:25 -starttls smtp |grep "TLS server extension"
Что тут важно понимать — не уязвимы два типа систем — те, что еще не имеют этой фичи (heartbeat TLS extension) и те, что уже пофиксили. Эти команды просто показывают список предоставляемых TLS extension. Если heartbeat не перечислен — 100% система не уязвима для этой атаки. Если перечислен — то может быть уязвима. В этом случае, если последнее обновление было… «не помню когда, но я однажды обновлял» — то обновляться надо — дырка есть.
я вот, например, не очень уверен, что в ssltest.py означают хексовые значения для hello и hb и нет ли в них другого эксплойта и шеллкода или может просто ошибки, из-за которой они могут не заметить дырку или сделать ложное срабатывание
В первом находится TLS HELLO пакет, а во втором — TLS HEARTBEAT. Вообще да, зависит от шифрования, вполне может и не работать не нестандартных ciphers.
16 03 02 00 31 # TLS Header
01 00 00 2d # Handshake header
03 02 # ClientHello field: version number (TLS 1.1)
50 0b af bb b7 5a b8 3e f0 ab 9a e3 f3 9c 63 15 \
33 41 37 ac fd 6c 18 1a 24 60 dc 49 67 c2 fd 96 # ClientHello field: random
00 # ClientHello field: session id
00 04 # ClientHello field: cipher suite length
00 33 c0 11 # ClientHello field: cipher suite(s)
01 # ClientHello field: compression support, length
00 # ClientHello field: compression support, no compression (0)
00 00 # ClientHello field: extension length (0)
01 00 00 2d # Handshake header
03 02 # ClientHello field: version number (TLS 1.1)
50 0b af bb b7 5a b8 3e f0 ab 9a e3 f3 9c 63 15 \
33 41 37 ac fd 6c 18 1a 24 60 dc 49 67 c2 fd 96 # ClientHello field: random
00 # ClientHello field: session id
00 04 # ClientHello field: cipher suite length
00 33 c0 11 # ClientHello field: cipher suite(s)
01 # ClientHello field: compression support, length
00 # ClientHello field: compression support, no compression (0)
00 00 # ClientHello field: extension length (0)
Народ успокойте меня, если ssh авторизация идет по ключу в debian squeeze, то понятно, что надо openssl надо обновить, а RSA DSA ключи менять надо?
если ssh авторизация идет по ключу в debian squeeze, то понятно, что надо openssl надо обновить
А вот мне как раз не понятно. OpenSSL и OpenSSH — разные вещи, никак не связанные (в том числе и при авторизации по ключам), и если у вас не было на этом сервере сайтов с HTTPS или чего-то еще с включенной поддержкой SSL/TLS (Jabber-сервер, почтовый сервер с включенным шифрованием и т.д.), то вам вообще ничего делать не нужно
Sign up to leave a comment.
Критическая уязвимость в OpenSSL 1.0.1 и 1.0.2-beta