Я так понимаю, в OpenSSL исправили только утечку данных из памяти, а на запросы во время хэндшейка она всё ещё отвечает?

Фикс. Других проверок нет.

А что насчет старых версий Tor+Polipo+Vidalia работающих с браузером через torbutton, они уязвимы?

Любые версии должны быть уязвимы, если они использовали непатченную версию библиотеки OpenSSL v. 1.0.1, вышедшую в марте 2012.

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

blog.inliniac.net: Detecting OpenSSL Heartbleed with Suricata

Для inline-mode, достаточно заменить alert на drop что-бы закрыть вероятную дыру на будующее.

И файл с хэшами паролей. Или это чья-то шутка: кто-то закачал фэйковый /etc/passwd через heartbleed в память.

А у Akamai был пропатченный OpenSSL. И они там намекают на что-то странное. Мало того, что акамайщики ещё весной 2013 года использовали укрепляющие патчи, они узнали об уязвимости ещё 4 апреля в этом году и тайком пропатчили конкретно эту дырку.

Сайт для пиара (heartbleed.com) подняли 5-го. Кто нашёл багу тот и решал когда, что и кому рассказать.


Использовали с августа 2012, весной 2013 в течении 9 дней защита памяти с ключами была под вопросом из-за ошибки в конфигурации.
Укреплящие пачти не связаны напрямую с этой ошибкой. Просто кто-то использует HSM, а кто-то изобретает вторые кучи. Остальные запускают условную убунту, как тестовый сервер CloudFlare, и сливают ключи атакующим.

Крупным вендорам (тому же CloudFlare) детали уязвимости раскрыли заранее. Responsible disclosure, всё такое.

Тут ссылка не открывается. На что её исправить — ума не приложу. Должно быть: https://blog.torproject.org/blog/debian-openssl-flaw%3A-what-does-it-mean-tor-clients%3F Оно трансформируется в https://blog.torproject.org/blog/debian-openssl-flaw:-what-does-it-mean-tor-clients? но не работает. Там двоеточие или знак вопроса нестандартные в url'е?

How did Akamai fix this so quickly, and why didn't you tell your customers in advance?

As a courtesy to us, we were notified shortly before public disclosure, which gave us enough time to patch our systems. We were asked not to publicly disclose the vulnerability, as doing so would have shortened the window of opportunity for others to fix their systems. Once we were notified, our incident management process governed patching, testing, and deploying the fix to our network safely.

Мудаки они и сволочи. Гость, по ходу, был прав. Проприетарщики искали способ, как получше поднагадить открытому софту, поэтому свои гниды были предупреждены заранее, а Tor Project нет.


Да. Для ясности: Akamai не знал про уязвимость, но из-за их собственных модификаций в коде так получилось, что в целом они не были подвержены уязвимости.

На подобную тему есть обсуждение в среде OpenBSD-разработчиков: Ted Uangst и Тео:

No. OpenSSL has exploit mitigation countermeasures to make sure it's exploitable.

What Ted is saying may sound like a joke...

So years ago we added exploit mitigations counter measures to libc malloc and mmap, so that a variety of bugs can be exposed. Such memory accesses will cause an immediate crash, or even a core dump, then the bug can be analyed, and fixed forever.
...
OH, because SOME platforms have slow performance, it means even if you build protective technology into malloc() and free(), it will be ineffective. On ALL PLATFORMS, because that option is the default, and Ted's tests show you can't turn it off because they haven't tested without it in ages.

So then a bug shows up which leaks the content of memory mishandled by that layer. If the memoory had been properly returned via free, it would likely have been handed to munmap, and triggered a daemon crash instead of leaking your keys.

OpenSSL is not developed by a responsible team.

Это их «New Technologies» с этой ссылки. Дескать, если б в OpenSSL пользовались их безопасными аналогами соответствующих сишных функций, такой дичи не произошло бы. Был бы крэш, но не тихая отдача параметров ключей. Чуть ли ни они даже перепроверили этот факт, собрав OpenSSL через такие функции(?).

А тут ещё кто-то хвастает, что PFS в OpenBSD httpd включено по умолчанию.

Очередной раз вспомнили про то, что язык, позволяющий легко выстрелить себе в ногу, не очень подходит для написания безопасного кода:

My opinion, then and now, is that C and other languages without memory checks are unsuitable for writing secure code. Plainly unsuitable. They need to be restricted to writing a small core system, preferably small enough that it can be checked using formal (proof-based) methods, and all the rest, including all application logic, should be written using managed code (such as C#, Java, or whatever – I have no preference).

На EFF пишут, что пока есть только один пример логов IDS, который бы говорил в пользу того, что кто-то знал об этой уязвимости ранее и пользовался ею. Остальные подозрительные логи могут быть объяснены иначе. На Ars Technica есть ещё немного о том же.


Статья как собрание многих ссылок по теме неплоха, но на этой статье отчётливо видно, как некомпетентность и слухи превращаются в достоверность. Понавставляли туда ссылок на жёлтую прессу о том, что в АНБ всё знали, обосновав это «своими источниками». Так и представляю: пришёл шпион в газету и рассказал им все TS: что АНБ знало, что нет, что использовало, что на потом отложило... но народ ест. После Сноудена на АНБ можно навесить всё, что угодно, и во всё будут верить.


Не только рутеры, но и миллионы смартфонов — предусмотрены ли для них централизованные автоматические обновления? Где-то писали, что в MacOS была неуязимая версия OpenSSL, и они тем самым оказались не под ударом.

Не только рутеры, но и миллионы смартфонов

Это я и имел в виду под embedded. Обновляться это всё конечно же не будет. Дай бог если обновят что-то в актуальных версиях мобильных ОС, но на всё старше года забьют, без вариантов.

предусмотрены ли для них централизованные автоматические обновления?

Технически, возможность обновлений имеется, но с Андроидом проблема в том, что за обновления каждый вендор отвечает отдельно. Никаких глобально централизованных апдейтов нет.

В комментариях к новости в блоге есть интересное от Роджера и нескольких анонимов:

many of the big ones (Tor relays — прим. авт.) are in the process of updating right now

Вселяет надежду.

How sad! I have mirrored it at
http://freehaven.net/~arma/ssltest.py

Тесты теперь лежат и у них.

Don't use the NIST curves if you can help it. (We use them for our link encryption, to blend in, but not for our circuit-level encryption.) You might like http://safecurves.cr.yp.to. On first glance it looks like the Safecurves folks understand the issues better than the ones from the site you link.

Оказывается, в Tor всё-таки для используются НИСТовские кривые. Если в них действительно есть бэкдор, насколько это будет опасно?

I scanned all the nodes in consensus for Heartbleed, with the following results:

at least 530 nodes are VULNERABLE,
at least 2995 are NOT VULNERABLE,
the rest I don't know beacause of network timeout or something.

Роджер поправил этого тестера в плане того, что надо смотреть на то, какая часть трафика проходит через уязвимые ноды — это более информативно, чем знать общее число, но и такая информация лучше, чем ничего.

Two or three of the nine directory authorities were unaffected, and the rest were vulnerable.

The long-term authority identity keys are unaffected, since they're kept offline.

The medium-term authority signing keys were affected, and they've been rotated (except for two authorities, which are offline until they can be brought back safely). Rotating them makes things a lot better, but still not perfect.

And the relay identity keys might have been taken, but really that's more of a hassle than a security thing — if we rotate them, existing clients will scream in their logs that they're being mitm'ed, and more importantly existing clients will refuse to proceed, even though the directory documents they fetch are signed with other keys.

It's not clear to me yet that this change is worth a flag day. Hopefully we can do it more smoothly.

Странные вещи. Вроде DA-нод было 10, а тут уже вдруг стало 9? 2 или 3 из них неуязвимы, а другие 2 DA-ноды ещё не обновили свои ключи?

I think if we're going to do that, and maintain them all, we should seriously consider switching to a link encryption that doesn't use the SSL protocol at all. That said, it shouldn't be *too* hard technically.

Это, я так понял, к тому, что поддерживать опциональную линковку Tor также с PolarSSL и GnuTLS, чтоб юзеры могли выбирать, на что завязываться — не вариант. Проще типа будет вообще отказаться от завязки на внешние библиотеки. Тут вспоминается недавно высказанный в связи с уязвимостью аргумент про то, что нет толковой конкуренции. Если б было хотя бы 2-3 сравнимых по качеству и распространённости библиотеки, баг коснулся бы только части интернета, а так получается, что всех.

Google’s Safe Browsing IS AGAIN not deleted from Firefox!!!! You need to do it manualy!

Ложная тревога? О, уже удалили.
Вбросы в блоге удаляют не задумываясь. Сразу видно, что это не pgpru.com. Никакого плюрализма мнений...


Тут о том же.

Минимум 3 часа, минимум 100 тысяч запросов. А в блоге интересуются, насколько это реально для Tor'а:

Private keys have been obtained, but it took over 100k requests and this was outside of Tor. How long on the fastest Tor connection would 100k requests take to complete?

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

А Бернштейн НИСТовские кривые явно отметил как safe=false.

В TLS протоколе ECC реализована только через них.