Критическая уязвимость в OpenSSL 1.0.1 и 1.0.2-beta


    Несколько часов назад сотрудники The OpenSSL Project выпустили бюллетень безопасности, в котором сообщается о критической уязвимости CVE-2014-0160 в популярной криптографической библиотеке OpenSSL.

    Уязвимость связана с отсутствием необходимой проверки границ в одной из процедур расширения Heartbeat (RFC6520) для протокола TLS/DTLS. Из-за этой маленькой ошибки одного программиста кто угодно получает прямой доступ к оперативной памяти компьютеров, чьи коммуникации «защищены» уязвимой версией OpenSSL. В том числе, злоумышленник получает доступ к секретным ключам, именам и паролям пользователей и всему контенту, который должен передаваться в зашифрованном виде. При этом не остается никаких следов проникновения в систему.

    Некто, знавший об уязвимости, мог прослушивать «зашифрованный» трафик почти во всем интернете с марта 2012 года, когда вышла версия OpenSSL 1.0.1. В то время была продемонстрирована успешная атака на TLS (BEAST), и многие перешли на защищенную версию TLS 1.2, появление которой совпало с выходом OpenSSL 1.0.1.

    Уязвимая версия OpenSSL используется в популярных веб-серверах Nginx и Apache, на почтовых серверах, IM-серверах, VPN, а также во множестве других программ. Ущерб от этого бага исключительно велик.

    Некоторые дистрибутивы операционных систем с уязвимой версией OpenSSL:
    • Debian Wheezy (стабильная), OpenSSL 1.0.1e-2+deb7u4)
    • Ubuntu 12.04.4 LTS, OpenSSL 1.0.1-4ubuntu5.11)
    • CentOS 6.5, OpenSSL 1.0.1e-15)
    • Fedora 18, OpenSSL 1.0.1e-4
    • OpenBSD 5.3 (OpenSSL 1.0.1c) и 5.4 (OpenSSL 1.0.1c)
    • FreeBSD 8.4 (OpenSSL 1.0.1e) и 9.1 (OpenSSL 1.0.1c)
    • NetBSD 5.0.2 (OpenSSL 1.0.1e)
    • OpenSUSE 12.2 (OpenSSL 1.0.1c)

    Дистрибутивы с более ранними версиями OpenSSL: Debian Squeeze (oldstable), OpenSSL 0.9.8o-4squeeze14, SUSE Linux Enterprise Server.

    Баг присутствует во всех версиях веток OpenSSL 1.0.1 и 1.0.2-beta, включая 1.0.1f и 1.0.2-beta1. Исправленная версия — 1.0.1g, которую всем пострадавшим необходимо установить немедленно, после чего сгенерировать новые ключи и сертификаты и предпринять прочие меры безопасности. Пользователей следует предупредить о возможной утечке их паролей. В случае невозможности немедленного апдейта на исправленную версию следует перекомпилировать OpenSSL с флагом -DOPENSSL_NO_HEARTBEATS.

    Уязвимость обнаружили специалисты по информационной безопасности из компании Codenomicon, а также, независимо от них, Нил Мехта (Neel Mehta) из подразделения Google Security. Именно последний сообщил разработчикам The OpenSSL Project, что нужно срочно исправить код. Ребята из компании Codenomicon подготовили подробное описание бага и даже открыли для него отдельный сайт Heartbleed.com с изображением кровоточащего сердца.
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама
    Комментарии 260
    • +24
      С таким багом можно целые государства на колени ставить!
      • +28
        Простите, что врываюсь в ваш (верхний) комментарий.
        Это серьезное говно. Будите всех своих IT-знакомых, обновляйте серверы!
        filippo.io/Heartbleed/ — Проверка вашего сервера на уязвимость
        rehmann.co/projects/heartbeat/ — еще одна (немного туповата)

        Надо помнить, что люди, использующие Debian или Ubuntu могут быть менее подвержены этому багу, т.к. для многих приложений по умолчанию используется GnuTLS, а не OpenSSL. В других же дистрибутивах, как правило, используется OpenSSL.

        Отзывайте свои SSL-сертификаты, генерируйте новые.
        • 0
          Простите, а сертификаты-то зачем менять?
          • +8
            Они скомпрометированы.
            • –4
              Потенциально скомпрометированы, верно?
              • +10
                Учитывая низкую сложность эксплуатации — то, скорее всего скомпрометированы :)
                • –2
                  Низкая сложность эксплуатации имеет значение теперь, когда уязвимость раскрыли. Те же немногие, кто знал о баге до этого, не ломали всех подряд. Небольшие проекты и сайты без финансовых транзакций, думаю, могут сильно не нервничать. Тем не менее, сменить сертификаты, пожалуй, стоит. Большие же игроки, вроде Гугла, итак уже взяли в практику регулярную их замену.

                  Интересна ситуация с крупными CA. Кто из них решится на отзыв и замену корневых и промежуточных сертов, признав тем самым их уязвимость? С другой стороны, это неплохой шанс попиариться, предложив клиентам бесплатную замену сертификатов, подписанных этими, потенциально скомпрометированными.
                  • +4
                    Отзывать корневой/промежуточный имеет смысл только если он непосредственно участвует в огранизации SSL, а не просто подписывает конечные сертификаты, храня приват оффлайн или в hsm.
                    Простейшая проверка глазами — посмотреть на CN промежуточного CA. Если там домен — то с этим CA лучше дел не иметь, независимо от этого CVE :-)
                    • +1
                      К тому же ключи корневых CA обычна хранятся в HSM и не имеют контактов с внешним миром. Утечь же таким образом ключу intermediate CA — тоже проблематично, т. к. он не экспонируется в TLS соединение. Т. е. за S/MIME, code signing и т. п. ключи можно не волноваться.

                      Интересно, могли пострадать ключи серверов типа openvpn, ipsec туннелей? Требует ли использование hearbeat установления канала (который не будет установлен при «левом» клиенте)?
                      • +1
                        Не требует. Посылать heartbeat запросы можно прямо в ответ на запрос соединения, еще до обмена.
                      • 0
                        Да, я почему-то подумал, что CA сертификаты тоже могут быть скомпрометированы.
            • +16
              filippo.io/Heartbleed/ — соберут неплохую базу уязвимых серверов :)
              • +2
                расчет идет из того что проверяющие — будут таки закрывать дыры ;)
                • +2
                  github.com/FiloSottile/Heartbleed/ — исходники этого сервиса
                  github.com/titanous/heartbleeder/ — еще одна тестилка
                  • +3
                    PoC на Python!
                    s3.jspenguin.org/ssltest.py
                    Можно, например, почту читать, если использовать его на mail.yandex.ru. Я не шучу.
                    • 0
                      Еще одна онлайн-чекалка: possible.lv/tools/hb/
                      • +2
                        Мда, 16к вместо 64х, какой же это PoC, это вполне себе рабочий эксплойт.
                        • +1
                          А 16к, похоже, максимум для пакета — режется уже позже, в другом месте. Причём без исправления пакета — просто режется, остаётся неправильная длина.

                          В ssl3.h SSL3_RT_MAX_PLAIN_LENGTH / SSL3_RT_MAX_EXTRA = 16384 по умолчанию.

                          В .py последние 2 байта в hb как раз за длину отвечают.
                          • 0
                            Да, вы правы, это даже в rfc прописано:

                            The total length of a HeartbeatMessage MUST NOT exceed 2^14 or max_fragment_length when negotiated as defined in [RFC6066].

                            И уж эту часть спецификации openssl выполняет без ошибок :-)

                            Т.е. 'read up to 64k' имеет место быть, но никак не 'reveal up to 64k' (если, конечно, на атакуемом сервере не сработает запрос с выставленным compression).
                        • +1
                          Да уж яндекс разочаровал такой тормозной реакцией :(
                          Со времени публикации уязвимости прошло уже полдня, а прикрыли буквально только полчаса назад, и весь мир читал нашу почту всё это время.
                          Тоже с помощью вашей утилиты сдампилось чьё-то письмо.

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

                          Позор одним словом.
                          • +5
                            Ага. Я им позвонил и написал на две почты.
                            Банки вообще не особо осознают опасность. Висел на телефоне по 20 минут, пока они там «соединяли» меня.
                            Альфа быстро закрыла после моего звонка, остальные — нет.
                            • +14
                              Они что там ещё и думают слушать вас или нет?!

                              Да 7 апреля можно объявить официальным праздником всех скаммеров, фишеров и прочих кардеров. Сейчас может прокатиться такая волна финансовых угонов, что у банкстеров в ушах зазвенит от дальнейших разборов полётов.

                              Вот уж дожили, 21-ый век, мелкий баг в сторонней либе ставит на колени всю мировую финансовую систему :)
                              • НЛО прилетело и опубликовало эту надпись здесь
                            • 0
                              А расскажите, как вы себе представляете «не тормознутую» реакцию в это случае?
                              • –7
                                Я так понимаю вы шутите?
                                cron + apt-get. Не, не слышал.
                                • +9
                                  До первого неудачного обновления, требующего ручного вмешательства, например, в конфиги.
                                  • +2
                                    Во-первых, можно прописать установку ТОЛЬКО секьюрных апдейтов (в случае убунту — security.ubuntu.com/)

                                    Во-вторых, я лучше соглашусь, чтобы мой почтовый сервер упал на сутки, чем слил все письма моей организации и её клиентов за прошедшие полдня.

                                    Если админы не могут удержать в руках крупнейший почтовик страны, то нечего их оправдывать, на мыло таких админов, даром они кушают яндексовские плюшки с печеньками.
                                    • +4
                                      Во-вторых, я лучше соглашусь, чтобы мой почтовый сервер упал на сутки, чем слил все письма моей организации и её клиентов за прошедшие полдня.
                                      Это вопрос к модели угроз. Если стоимость простоя умноженная на вероятность простоя выше, чем стоимость утечки умноженной на её вероятность, то, очевидно, какое решение будет приниматься в рациональном случае.

                                      Если ваша «защита» стоит дороже, чем защищаемые сведения — то зачем она нужна? Это не касаясь тех вариантов, когда есть внешний регламентирующий документ.
                                      • +4
                                        Я что-то в вашем последнем абзаце смысл не уловил. Причём тут «защита» (почему в кавычках?) стоит дороже?

                                        Речь о том, что яндекс предоставляет корпоративную почту и за сегодняшний день она потенциально утекла из-за нерасторопности админов этой организации, которые полдня не могли накатить апдейты, вот и всё. Что тут ещё говорить?

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

                                        Ладно, фиг с ним с яндексом, тут вон банки-то до сих пор не проапдейтились, о чём я вобще говорю, полнейшая безалаберность.
                                        • +4
                                          Яндекс-лобби сливает карму. Вот они грязные методы борьбы :)
                                          • 0
                                            Не считайте меня адвокатом дьявола.

                                            Допустим, Яндекс предоставляет корпоративную почту. По стандарту он не обязан её шифровать при передаче куда-либо (если, например, хост-получатель не поддерживает SMTPS и STARTTLS, то шифроваться ничего не будет и письмо пойдет по интернету plain text'ом). Надеюсь, что это не стало для вас открытием.

                                            Соответственно, в договоре/SLA не может быть пункта, что они обязуются обеспечивать конфиденциальность почты клиента, если их юристы не любители ездить в лес в багажнике, конечно.

                                            Медленное же обновление ключей и сертификатов на фронте — даёт некоторый риск утечки данных, но потери (в том числе, репутационные) могли посчитать меньшими, нежели от простоя в полдня.

                                            Банкам же иногда просто наплевать на клиентов-физлиц, иногда они просто не успевают (в силу медлительности и серьезной бюрократии внутри). Ибо и среди админов там любители подставлять себя долго не задерживаются и вполне могут оказаться за факап на счетчике (в реалиях РФ) или должны огромную сумму по суду (в реалиях запада).
                                            • 0
                                              Их SCM, deployment и т. д. — на их совести и меня не очень волнуют. Если захотят — порадуют нас постом о том, как у них всё прекрасно и быстро раскатывается на тысячи серверов ,)
                        • –3
                          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
                          эта проблема не решена
                          • +1
                            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
                            • +2
                              >>Дистрибутивы с более ранними версиями OpenSSL: Debian Squeeze (oldstable), OpenSSL 0.9.8o-4squeeze14, SUSE Linux Enterprise Server.

                              Меня смутила эта строка. Так как она идет за перечислением дистрибутивов с уязвимыми версиями библиотеки, я воспринял что это продолжение списка. В моем случае используется Debian Squeeze и как видно в выводе — версия таки 0.9.8o, потому и вопрошаю на тему наличия проблемы и ее решения.
                              • –2
                                Найдите автора исправления с ветки OpenSSL 1.0.0 на ветку OpenSSL 1.0.1 и отрежьте ему яйца.
                                • +3
                                  Может, он уже не один раз озолотился:)
                            • 0
                              Отзывайте свои SSL-сертификаты, генерируйте новые.

                              Правильно ли я понимаю, что:
                              1. Отозвать можно только сертификаты для https. Сертификаты для ssh, pop3s, openvpn, etc. отозвать нельзя (а учитывая что в большинстве случаев они самоподписанные в отзыве/смене вообще никакого смысла нет).
                              2. Отзыв/замена https сертификатов везде платная (вроде бы даже у startssl).
                              • +1
                                Отозвать можно любой x509 сертификат. Почему нет смысла отзывать, если сертификат самоподписной?
                                • 0
                                  Правда, при использовании самоподписанных сертификатов обычно не генерят crl и не прописывают его в сертификат. И нет никакой проблемы в имперсонализации под атакуемого (имея старый сертификат и ключ) при MitM.
                                  • +1
                                    Да, я уже успел выключить panic mode и немного включить мозг.

                                    Сертификаты для pop3s действительно это обычные сертификаты на домен, так что теоретически сервер может использовать один сертификат и для https и для pop3s/imaps, и его можно отозвать. Правда, лично я не уверен, что клиенты pop3/imap проверяют CRL… хотя только что глянул в доку fetchmail — вроде бы проверка есть если используется достаточно свежий openssl.

                                    Самоподписанные отзывать имеет смысл только если вы можете проконтролировать что все ваши клиенты используют и корректно обновят кешированные fingerprint-ы самоподписанных ключей — что обычно нереально.

                                    В случае ssh всё аналогично самоподписанному сертификату — перегенерить ключи сервера и все клиенты должны обновить ~/.ssh/known_hosts.

                                    Для openvpn (в режиме shared key, например) нужно менять этот shared key.
                                    • +1
                                      Для openvpn (в режиме shared key, например) нужно менять этот shared key.

                                      Не, shared key это не x509, так что уязвимости нет.
                                      • 0
                                        Из памяти shared key можно украсть не хуже, чем private key. Вопрос с openvpn на самом деле в другом — если openvpn работает в режиме pre-shared shared key, то он не использует ни на каком уровне ssl и не подвержен этой уязвимости?
                                        • 0
                                          Да, именно так.
                                          • 0
                                            Тогда на ssh эта дыра тоже вроде бы не должна распространяться.
                                • +1
                                  1. Если у вас pop3s, imaps, smtps и/или настроен starttls, то при уязвимой версии openssl ваши ключи потенциально утекли и их надо менять, вне зависимости от того, самоподписанный сертификат или нет. Дальнейший трафик потенциальный plain text.

                                  2. Отзыв сертификата бывает как платным, так и бесплатным, даже в рамках одного CA. Смотрите policy своего CA, их faq etc
                                  • НЛО прилетело и опубликовало эту надпись здесь
                                    • +1
                                      Платный отзыв сертификата — это фишка StartCom и одна из причин дешевизны.
                                  • +1
                                    ubuntu 12.04 LTS
                                    тоже все в порядке, обновления пришли ночью, launchpad.net/ubuntu/+source/openssl/1.0.1-4ubuntu5.12
                                    • 0
                                      Обновил, но проверка через представленный выше сервис говорит что все равно IS VULNERABLE
                                      Что то еще забыл сделать? Перезапустил nginx разумеется.
                                        • 0
                                          Самое интересное, что sid получил исправленную версию позже, чем wheezy-security.
                                          • +1
                                            Не совсем так. Обновление вышло одновременно, но wheezy-security пушится по ускоренной схеме и потому раньше добралась до конечных пользователей.
                                  • 0
                                    Только что получил обновление в Ubuntu 14.04 с исправлением, теперь я в безопасности.
                                    • +33
                                      Держите нас в курсе.
                                      • +16
                                        По-моему достаточно важно, что команда популярного дистрибутива так оперативно закрыла уязвимость. Возможно, уже и в 12.04 обновление отправили.
                                    • –2
                                      Проблема же на серверной стороне, как я понял. Или у вас там web-сервер с https?
                                      • +3
                                        Подскажите, возможна ли эксплуатация уязвимости неаутентифицированным клиентом в схеме с аутентификацией клиентов (например, по клиентским сертификатам)?
                                        • +2
                                          Возможна. Можно соединиться и просить посылать heartbeat ответы не посылая запросов на, собственно, авторизацию.
                                          • +1
                                            Это означает, что системы, использующие авторизацию по клиентским сертификатам, тоже уязвимы. Например, openvpn, ipsec (если он базируется на openssl TLS).
                                    • +2
                                      • 0
                                        Точно?

                                        $ 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   | experimental
                                        • +1
                                          Точно. Вот же у вас в wheezy-security пофикшеная версия. В чём вопрос?
                                          • +2
                                            Вообще-то wheezy отдает уже deb7u6
                                            aptitude show openssl | grep Version
                                              Version: 1.0.1e-2+deb7u6
                                            aptitude show libssl1.0.0 | grep Version
                                              Version: 1.0.1e-2+deb7u6
                                            

                                            • 0
                                              По правде сказать, меня волновал только sid, но к полудню и там появился свежий билд из апстрима (1.0.1g-1).
                                        • НЛО прилетело и опубликовало эту надпись здесь
                                          • +3
                                            Использует через libcrypto.
                                            ldd `which ssh` |grep libcrypto libcrypto.so.1.0.0 => /usr/lib/libcrypto.so.1.0.0 (0x0000deadbeef0000)
                                            • 0
                                              В wheezy обновление openssh уже прилетело.
                                              • +4
                                                Ошибка в реализации протокола TLS. У OpenSSH совсем-совсем другой протокол и к нему эта ошибка отношения не имеет.
                                            • +2
                                              Непонятно как эксплуатировать.

                                              Поясните git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=4b7a4ba29cafa432fc4266fe6e59e60bc1c96332
                                            • +5
                                              Из-за этой маленькой ошибки одного программиста кто угодно получает прямой доступ к оперативной памяти компьютеров, чьи коммуникации «защищены» уязвимой версией OpenSSL. В том числе, злоумышленник получает доступ к секретным ключам, именам и паролям пользователей и всему контенту, который должен передаваться в зашифрованном виде.
                                              А в advisory по ссылке: can be used to reveal up to 64k of memory. Причем скорее всего где-нибудь сразу за границей буфера.
                                              • 0
                                                Хотя видимо это перевод части heartbleed.com.
                                                • +2
                                                  Ага, там ребята вроде грамотные.
                                                  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.
                                                  • +1
                                                    Даже если уязвимость позволяет запрашивать произвольные участки памяти, то максимум, что можно получить — это дамп памяти процесса, который обслуживает данное соединение. И видимо только запрашивать, а не писать в неё. Я бы не называл это «прямой доступ к оперативной памяти компьютеров», но видимо цель сайта — нагнать страху.
                                                    • +9
                                                      Как самый минимум — он позволяет стащить все приватные ключи и создавать сайты, которые будут выглядеть как легитимные — с зелёным замочком, правильным fingerprint'ом и прочими аттрибутами.
                                                      • 0
                                                        Только в том случае, если последний присутствует в памяти процесса, что в общем-то не обязательно после установки соединения.
                                                        • +2
                                                          Ну как пример, в Yahoo можно дампить пароли пользователей:

                                                          pbs.twimg.com/media/Bksw9k_CAAAy8ln.png:large
                                                          • –1
                                                            Безусловно это в определенной степени минус асинхронных серверов, где обработка всех запросов происходит в одном процессе. Они более уязвимы к подобного рода ошибкам.

                                                            Yahoo наверняка используют свой асинхронный Traffic Server.
                                                            • 0
                                                              У вас один и тот же процесс (форк) Апача может обрабатывать со временем запросы разных пользователей. При этом в памяти, остаться «старый» мусор. Она же (память) нулями не забивается.
                                                              • 0
                                                                Это да, но от этого можно защититься относительно легко, и в тех случаях, где повышенные требования безопасности, имеет смысл включать PAX_MEMORY_SANITIZE.
                                                                • +1
                                                                  Ну вот кстати хз, PAX_MEMORY_SANITIZE помогает «зачищать» свободную память, но не молниеносно, но тут надо потестить. К тому же импакт на перфоманс 3%. Не много, конечно. В целом же я согласен — PAX сила)
                                                                  • 0
                                                                    Он же в виде сторонних патчей живёт, а не master?
                                                                    • 0
                                                                      Да, это отдельный проект.

                                                                      Ванильное ядро вообще мало кто использует. У меня на сервере Hardened Gentoo и там PaX (а также много других security-related вкусностей) из коробки.
                                                                      • +2
                                                                        Вы не проверяли, с PAX_MEMORY_SANITIZE обсуждаемая уязвимость работает? А то я, непроверяя сразу все обновил :)
                                                                        • НЛО прилетело и опубликовало эту надпись здесь
                                                                          • 0
                                                                            В общем да, поэтому я выше и указал, что сервера, в которых в одном процессе обрабатывается много всего, наиболее восприимчивы к подобного рода уязвимостям.

                                                                            Я не исследовал вопрос, и пока для меня остается загадкой, каким образом столько важной информации оказывается в пределах 64-килобайт от буфера, в который считывается heartbeat запрос. В зависимости от этого, можно было бы предположить, что какая-нибудь техника потенциально могла бы защитить от уязвимости, если и не полностью, то хотя бы уменьшить шансы получить в ответ что-то ценное.
                                                                            • 0
                                                                              Это как раз очевидно — классика 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

                                                                              //дублирую комент, потому что развелось что-то одинаковых тем ((
                                                                              • +3
                                                                                это не use-after-free. Это в первом пользователе — забыли занулить важные данные, просто освободили память, а во втором — читали из только что выделенной памяти, в которой может быть любой мусор. В данном случае, этот мусор — то, что не было подчищено перед free.

                                                                                use-after-free — это

                                                                                free(a)
                                                                                read(a)

                                                                                то есть, читаем (или пишем) область, которую вроде как уже освободили
                                                                                • 0
                                                                                  Ну в общем да, Вы правы. Расслабился я и поторопился с суждениями 8) Но суть ответа «почему там интересные данные» показана.
                                                                                  • 0
                                                                                    Просто указатель новый, а не старый, но маллок все равно менеджится в эту же область памяти, которую недавно юзали и просто не занулили. Потому там и данные других реквестов.
                                                                  • 0
                                                                    Они походу вообще спят еще — до сих пор открыто, логины-пароли почти в каждом пакете есть…
                                                              • –15
                                                                alizar же
                                                        • +2
                                                          Насколько понял, squeeze и lenny в безопасности? В squeeze 0.9.8 а ленни и куда меньше.
                                                          • +9
                                                            lenny же снят с поддержки, нет? То есть оно «не в безопасности» никаким образом.
                                                            • –11
                                                              Снятие с поддержки не мешает Lenny быть на порядки безопаснее всех «поддерживаемых» дистрибутивов, которые были компрометированы на 100%.
                                                              • 0
                                                                P.S. Имелся в виду именно данный конкретный баг, а не общая ситуация, разумеется :)
                                                                • +9
                                                                  С учётом числа закрытых CVE, данный конкретный баг уже не интересен. Если у человека до сих пор ленни задницей в интернеты смотрит, то я бы остерёгся на такой системе что-либо держать.
                                                                  • –7
                                                                    Ну со времен ленни такой крупнячок впервые =) я не говорю, что стоит сидеть на старых дистрах без поддержки, я лишь говорю о том, что на фоне данного бага меркнет даже устаревший на несколько лет и неподдерживаемый дистрибутив, ибо баг-то remote, а не очередной CVE на фикс локальной эскалации возможной лишь в високосный год на Марсе.
                                                          • +1
                                                            Странно, что написали про бздю 9.1. Там идет 0.9.8х. Хотя может 9.2 позже? 10ка идет с 1.0.1е
                                                            • 0
                                                              Зашибись, фикс на фре ломает все порты. Пробую новый svn.
                                                            • +1
                                                              В CentOS 5.x — 0.9.8e — можно курить в сторонке )
                                                              • +1
                                                                Это да, там даже update не подтягивает «нужную» версию.
                                                                А вот CentOS 6.5 даже в updates выдает 1.0.1e-16.el6_5.7
                                                                • +2
                                                                  Так посмотрите 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
                                                                  • 0
                                                                    Увы и ах:
                                                                    CentOS 6.5:
                                                                    * Tue Jan 07 2014 Tomáš Mráz <tmraz@redhat.com> 1.0.1e-16.4
                                                                    — fix CVE-2013-4353 — Invalid TLS handshake crash

                                                                    CentOS 5.10:
                                                                    * Tue Feb 26 2013 Tomas Mraz <tmraz@redhat.com> 0.9.8e-26.1
                                                                    — fix for CVE-2013-0169 — SSL/TLS CBC timing attack (#907589)
                                                                    • 0
                                                                      У меня на 6.5 обновилось до 1.0.1e-16.el6_5.7, где есть бэкпорт фикса. Вы же показываете кусок ченджлога старой сборки 1.0.1e-16.el6_5.4.
                                                              • +22
                                                                :(
                                                                • +5
                                                                  Поправили уже. passport.yandex.ru тоже.
                                                                • +2
                                                                  Блин!!!
                                                                  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.......\/.|
                                                                  }

                                                                  Как теперь быть? :-(
                                                                  • 0
                                                                    Зато mail.google.com впорядке.
                                                                    • 0
                                                                      rehmann.co/projects/heartbeat/ все же пока показывает:
                                                                      • +5
                                                                        Эта штука просто heartbeat проверяет, а не уязвимость
                                                                    • 0
                                                                      Как Вы смотрели? У меня все ок.

                                                                      >All good, google.ru seems not affected!
                                                                      • 0
                                                                        Проверил еще раз. Видимо, уже пофиксили, или это — глюк самого проверяльщика.
                                                                    • –2
                                                                      Эхх…
                                                                      image
                                                                      • +1
                                                                        All good, store.steampowered.com seems not affected!
                                                                        steamcommunity.com IS VULNERABLE.
                                                                        store.origin.com IS VULNERABLE.
                                                                        • +1
                                                                          signin.ea.com seems not affected — а логин светится же вроде только там

                                                                          А вот что касается стима — да, кроме
                                                                          partner.steamgames.com seems not affected
                                                                          partner.steampowered.com seems not affected
                                                                        • +38
                                                                          Как это понимать? :) image
                                                                          • +5
                                                                            При попытке войти на HTTPS-версию выдается сертификат *.cloudfront.net — т.е. уязвим CloudFront
                                                                          • 0
                                                                            Обновил в Убунте openssl до 1.0.1-4ubuntu5.12.

                                                                            Проверяльшик всё равно говорит «IS VULNERABLE».

                                                                            • +1
                                                                              libssl ещё надо было обновить
                                                                              • 0
                                                                                Обновил openssl и libssl1.0.0. Тест все равно говорит о уязвимости.
                                                                                Ubuntu, Apache2.

                                                                                Индейца перезапустил.
                                                                                Куда еще посмотреть?
                                                                                • 0
                                                                                  А что выдаёт openssl version -a?
                                                                                  • 0
                                                                                    # 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"
                                                                                    • 0
                                                                                      Тут всё нормально. Может в Апач что-то вкомпилено? Я nginx использую.
                                                                                    • 0
                                                                                      Вы веб-сервер перезапустили?
                                                                                      ldd $(which apache) | grep -e libssl -e libcrypt
                                                                                      У меня в Debian, например, почти все используют libssl 1.0.0, а вот OpenVPN 0.9.8, об этом тоже забывать нельзя.
                                                                                      • 0
                                                                                        Выше вроде написал, что перезапустил.

                                                                                        # 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

                                                                                        Т.е. фактически у меня одна библиотека. Другой просто нет.
                                                                                        • 0
                                                                                          А сделайте dpkg -S /lib/x86_64-linux-gnu/libcrypt.so.1
                                                                                          и ldd $(which apache2) | grep -e tls
                                                                                          • 0
                                                                                            # 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
                                                                                            • 0
                                                                                              Я apache почти ни разу не использовал, но, если не ошибаюсь, там ssl модулем? Какой-нибудь mod_ssl? Попробуйте его найти и на нем ldd использовать.
                                                                                              • 0
                                                                                                # 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)
                                                                                                • +4
                                                                                                  Нашел виновника:
                                                                                                  # apt-get remove mod-spdy-beta

                                                                                                  И все стало хорошо!
                                                                                                  • 0
                                                                                                    Это неправильный метод.

                                                                                                    Пересобрать openssl недостаточно. Надо еще пересобрать nginx с указанием исходников нового openssl, указав опцию --with-openssl, тогда все будет хорошо.
                                                                                                    • 0
                                                                                                      При чем тут исходники? Я где-то писал о них?
                                                                                                      Более того, я о nginx ни слова не написал!
                                                                                                      Проблема в конкретном модуле Апача. Возможно он содержит свою реализацию SSL.
                                                                                                      • 0
                                                                                                        SPDY модуль собран (не вами) со старой версией OpenSSL, и надо его пересобрать, указав ему на новые исходники OpenSSL.
                                                                                                        Именно так я сделал для nginx, для апача все должно быть аналогично.
                                                                                                        • 0
                                                                                                          Мне проще отказаться от SPDY в Апаче. Не те у нас нагрузки, чтоб думать об этом.
                                                                                                          • +4
                                                                                                            Разве nginx линкует openssl статически? Если нет — то зачем его пересобирать?
                                                                                                            • –3
                                                                                                              Nginx содержит модуль spdy, который зависит от OpenSSL. Выше человек «решил» проблему, просто отключив spdy, а правильнее — пересобрать его. Ваш К.О.
                                                                                                              • +4
                                                                                                                Зависимость от модуля не означает статической линковки. 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
                                                                                                                
                                                                                                                • +1
                                                                                                                  Тип линковки с OpenSSL не зависит от включени/выключения spdy. Более того, модуль spdy может быть собран и работать вообще без OpenSSL. Также как и spdy модуля может не быть вовсе, а будет уязвима конфигурация с https. Иными словами, SPDY к проблеме использования OpenSSL полностью иррелевантен.

                                                                                                                  Чаще всего nginx линкуется с системной OpenSSL и в этом случае достаточно обновить системную библиотеку, а затем перезапустить или выполнить обновление исполняемого файла nginx на лету.

                                                                                                                  Статически nginx слинкован с OpenSSL (при помощи опции --with-openssl=/path/to/sources или флагов компиляции) в основном у горе энтузиастов, которые собирают его из исходников.

                                                                                                                  See also: nginx.com/blog/nginx-and-the-heartbleed-vulnerability/
                                                                                                                  • 0
                                                                                                                    Потому и удивляюсь, что у меня везде динамически слинкован с libssl.

                                                                                                                    Статически может быть оправдано в embedded окружении, да и то это баш на баш — меньше затрат на загрузку и динамическую линковку, больше — по .text секции основного процесса.
                                                                                      • 0
                                                                                        Такая же фигня. Обновил на убунту-сервере оба пакета, рестартнул nginx и apache, а filippo.io/Heartbleed/ все равно показывает уязвимость.
                                                                                        «Зелененькие» у меня только сервера со старенькой Debian Squeeze и неподключенным репозиторием с бэкпортами из Wheezy. Соответственно версия там 0.9.8
                                                                                    • 0
                                                                                      После обновления пакета надо сервис обязательно рестартить.
                                                                                    • –10
                                                                                      Когда уже этот OpenSSL выкинут и забросят?
                                                                                      Там присутствует столько скрытых уязвимостей, что мама не горюй. И никогда это не поправят (те кто смотрел исходники поймут о чём я)
                                                                                      • +16
                                                                                        Отправьте pull request, сделайте мир чуточку лучше.
                                                                                        • +3
                                                                                          Посмотрите исходники, потом говорите о pull request.
                                                                                          Это не исправляется, это лишь переписывается полностью.
                                                                                          • +8
                                                                                            Не будьте голословны — напишите статью с примерами.
                                                                                            • +11
                                                                                              OpenSSL действительно написан достаточно плохо, тут я SowingSadness поддерживаю. О нем давно плохо говорят. Моя любимая статья на эту тему: OpenSSL is written by monkeys
                                                                                              • +18
                                                                                                Ненависть к openssl видна уже по невалидному сертификату при заходе на сайт.
                                                                                                • 0
                                                                                                  Есть даже Твиттер-аккаунт OpenSSL Fact, где в течение года каждый день писали по одной ужасной строчке из исходного кода OpenSSL.
                                                                                                  • –1
                                                                                                    Всего 365 ужасных строк? Разве это такой плохой код? (И разве это был такой плохой год?)
                                                                                                    • 0
                                                                                                      Т.е. в вашем проекте ужасных строк гораздо больше, чем 365?
                                                                                                      • +2
                                                                                                        Там файлами по 2000 строк можно писать.

                                                                                                        Вы попробуйте поработать с OpenSSL как с чёрным ящиком.
                                                                                                        Даже нормальной справки по его аргументам нет, каждое действие превращается в набор магических аргументов, при чём в различных случаях они ведут себя по разному.
                                                                                                        Например "-in" в некоторых случаях принимает сертификат лишь в der виде, а в некоторых как в pem так и в der виде.
                                                                                                        В одних случаях прямое указание "-inform PEM/DER" работает, в других нет.
                                                                                                        • +2
                                                                                                          Ещё из прекрасного: extension subjectAltNames в openssl req -new доступен только через config-файл.
                                                                                                • 0
                                                                                                  А что известно про качество GnuTLS?