LINUX.ORG.RU

Предсказуемый генератор случайных чисел в Debian/Ubuntu

 , , , ,


0

0

Было обнаружено, что ГСЧ в пакете openssl в Debian (а также Debian-based дистрибутивах) был предсказуемым с версии 0.9.8c-1 (добавленной в unstable 2006-09-17) из-за Debian-специфичной поправки. Могли быть затронуты ключи SSH, OpenVPN, DNSSEC и ключевой материал для сертификатов X.509, а также ключи сессий SSL/TLS-соединений. Рекомендуется пересоздать весь криптографический материал, созданый OpenSSL начиная с версии 0.9.8c-1 на системах Debian. Также следует считать скомпрометированными все ключи DSA, использованные для подписывания или авторизации на затронутых системах Debian, т.к. Digital Signature Algorithm завязан на секретное случайное число, используемое при генерации.

Должны быть выложены: детектор слабого ключевого материала http://security.debian.org/project/ex... и инструкции по смене ключей.

Ошибка была исправлена в stable ветке (etch) с версии 0.9.8c-4etch3. В unstable ветке (sid) и тестовой (lenny) ошибка исправлена с 0.9.8g-9. Старая stable ветка (sarge) не затронута. Также в пакете openssl были исправлены еще две уязвимости.

>>> Подробности

anonymous

Проверено: anonymous_incognito ()

прозреваю заговор BSD-ешников
после недавней неутешительной новости про багу

hizel ★★★★★
()
Ответ на: комментарий от Sylvia

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

это другая крайность.

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

например бывают патчи лечащие досадные ошибки автора который например не понимает чем 32-битная архитектура отличается от 64-битной за неимением оной. однажды даже сам правил софтину автор которой уже давно забил на нее. а надо было не пользовать и радоваться что патчей нет?

black7
()
Ответ на: комментарий от anonymous

>Хух, повезло ! Видовс 98 Эс-Е !

байки из склепа

black7
()

Вот так дыра! Во-первых, серьёзная уязвимость с точки зрения доступа к информации, а не всяких root-shell-ов. А во-вторых эту дырку ещё надо было постараться найти! Вот за это -- респект!

anonymous
()
Ответ на: комментарий от anonymous

>пречищалась ле ты перж Патрегом?

лол. пропаганда метанизации луж :)

black7
()

А если бы это поделие кто-то на сервер поставил?

anonymous
()

Фуууфффф, пронесло... Ни одного ключа на демьянбэс последние полтора года не ненерировал. :)

Lumi ★★★★★
()
Ответ на: комментарий от anonymous

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

Значит, на debian.org параноики, раз заблокировали аккаунты?

madcore ★★★★★
()
Ответ на: комментарий от Lumi

>s/ненерировал/генерировал/

>Иногда очень хочется редактирование :(

Удаление чем не устраивает? Скору жалко?

madcore ★★★★★
()

http://wiki.debian.org/SSLkeys Characteristics of potentially vulnerable keys: generated since 2006-09-17 generated with etch, lenny or sid (sarge is not vulnerable) generated using openssl, ssh-keygen, or 'openvpn --keygen' (GnuPG and GNUTLS are not affected)

ну с этим все ясно

Additionally, some keys may be compromised in the following situations: key generated with broken openssl = bad (это тоже) key generated with good openssl and used to ssh from a machine with bad ssl = bad ( это явно паранойа, это надо чтобы уже перехватывали и расшифровывали траффик, если mission critical - тут менять, а если openvpn для покупок из WiFi зоны - тут навряд ли)

что то совсем ничего не пишут про сертификаты , которые были подписаны на плохом openssl но с нормальными ключами (старые и сгенерированные на нормальной системе)

Sylvia ★★★★★
()

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

Yurand
()
Ответ на: комментарий от Yurand

> Меня удивляет нафига эти придурки вообше полезли комментарии править, вот уж супер необходимый патч. Заняться им нечем.

valgrid попутал.

sv75 ★★★★★
()

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

anonymous
()
Ответ на: комментарий от madcore

> Удаление чем не устраивает?

Из-за дурацкой описки в одну букву?

> Скору жалко?

Ничуть.

Lumi ★★★★★
()
Ответ на: комментарий от anonymous

> Как я понимаю, подмножество скомпрометированых ключей можно сгенерить. Велико ли оно? Сколько займет перебор?

Да. Нет. Мало. см. тулзу дял скачивания и ссылку на вики.

> Какой дополнительной инфой о системе нужно располагать?

Для OpenVPN - видимо достаточно IP, если я правильно понимаю.

sv75 ★★★★★
()
Ответ на: комментарий от anonymous

>Народ, расскажите, в чем все-таки опасность? Как я понимаю, подмножество скомпрометированых ключей можно сгенерить. Велико ли оно? Сколько займет перебор? Какой дополнительной инфой о системе нужно располагать?

По ссылкам впадлу сходить?

It looks likely that the only remaining source of entropy in the generated keys comes from the PID of the process. This is 16 bits, typically much less effective entropy. So there may, in fact, be just a few thousand possibilities for a specific key size. Looks like 'dowkd.pl' lists about 262,000 entries. -- MarshRay

Are you telling me that the only source of entropy is the process' PID, and some uninitialized memory that may even be filled in a predictable manner by the execution trace leading up to use of the buffer? -- KenBloom

Under correct circumstances, OpenSSL was, indeed, adding so-called uninitialized memory to the entropy pool, but this was not the primary source of entropy (provided externally through ssleay_add_rand). Please see below for more detail. -- NathanielFilardo

anonymous
()
Ответ на: комментарий от anonymous

Да чё вы разнылись? Баг обнаружил сам разработчик. Воспользоваться этим багом врядли кто успел до этого. Генерите новые ключи и забудьте об этом неприятном (хотя новость полезная) событии ;)

anonymous
()
Ответ на: комментарий от madcore

> Значит, на debian.org параноики, раз заблокировали аккаунты?

В некоторых профессиях (связанных с обеспечением безопасности в той или иной форме) отсутствие "паранойи" означает некомпетентность.

askh ★★★★
()
Ответ на: комментарий от andreyu

>> Ух... Виста как всегда на коне

>Модель коня какая?

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

black7
()

Почитал по пробегавшей уже здесь ссылке (http://www.links.org/?p=327) нападки красноглазого BSDшника и одновременно девелопера OpenSSL и стало откровенно жалко ментейнеров Debian. На них накинулись как на врагов народа все кому не лень, несмотря на то что ментейнеры стремились сделать всё как можно лучше для своих же неблагодарных пользователей.

Однако все же порадовал десятый комментарий (http://www.links.org/?p=327#comment-176526), приятно что хоть кто-то рассуждает здраво:

It may well be shame-on-Debian for not sending patches upstream, but it’s NOT shame-on-Debian for patching something they didn’t understand. Instead, it’s shame-on-OpenSSL for leaving an undocumented landmine in security-critical code.

Everybody knows that crypto is full of subtlety, and it’s *really* easy for one not immersed in it to not fully understand the intricacies. But crypto is still written by humans, and crypto can still have run-of-the-mill bugs too.

In more than 25 years of C development experience, I’ve never run across code whose proper operation depended on a variable being uninitialized, and so it’s not ridiculous that even a skilled, thoughtful developer would have assumed this was one of those run-of-the-mill bugs. “Who’d ever want to do *that*?”

Well in this case the OpenSSL team did want to do that, and it’s perfectly reasonable (and a kind of clever idea), but when one uses a construct that’s vanishingly rare, one really ought to document it:

unsigned char tmpbuf[ENTROPY_NEEDED]; /* do not initialize - this is starting entropy! */

Adding that single comment to rand_unix.c would have likely avoided this whole issue by leaving a big sign: “Don’t step on the landmine”.

Дебиановцы конечно сглупили с этим патчем, все иногда ошибаются. И всё равно команда Debian - лучшие. Long live Debian!

SKYRiDER ★★★
()
Ответ на: комментарий от SKYRiDER

вообще то статья правильная

What can we learn from this? Firstly, vendors should not be fixing problems (or, really, anything) in open source packages by patching them locally - they should contribute their patches upstream to the package maintainers.

Secondly, if you are going to fix bugs, then you should install this maxim of mine firmly in your head: never fix a bug you don’t understand.

Sylvia ★★★★★
()
Ответ на: комментарий от Sylvia

впрочем ) надеюсь и разработчики Дебиан и все прочие из этого урок извлекут и в дальнейшем ничего подобного не повторится, прикол конечно, что 2 года генерировались ключики , которые на самом деле ничего не стоят. Интересно кто нибудь из "великих мира сего" (я про тех кто rootCA и приравненные к ним) генерировали ключики дебиановской openssl ?

Sylvia ★★★★★
()
Ответ на: комментарий от anonymous

> Значит, на debian.org параноики, раз заблокировали аккаунты?

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

Sylvia ★★★★★
()
Ответ на: комментарий от Sylvia

Да, эти аргументы в статье правильные, но и для этих утверждений есть весьма разумные оправдания/контраргументы, достаточно почитать хотя бы комментарии к самой статье. Лично меня взбесил сам менторский тон этого OpenSSL разработчика, который бросился поучать остальных не разобравшись в ситуации до конца.

SKYRiDER ★★★
()
Ответ на: комментарий от SKYRiDER

просто факты таковы что 2 года, дыра с ключами...
кого угодно разозлит, по сути все что должно было быть секретным таковым не являлось, а если есть дампы перехваченного траффика - все они могут быть расшифрованы.
Кого то максимум подстерегает неприятность как перехват данных кредитки и снятие с нее пары сотен долларов, а для кого то секретность более существенна, вообщем я к тому что общество лихорадить будет еще долго и последствия еще вылезут

Sylvia ★★★★★
()
Ответ на: комментарий от SKYRiDER

> It may well be shame-on-Debian for not sending patches upstream

Несколькими комментами ниже:

> Funny thing is, it *was* reported to openssl-dev: http://marc.info/?l=openssl-dev&m=114651085826293&w=2

> I’m not seeing a reply from you there or a negative reply whatsoever.

Что тут ещё сказать? Меинтейнеров жалко, что им приходится работать с такими вот "дружелюбными" разработчиками.

kastaneda
()
Ответ на: комментарий от Sylvia

> кого угодно разозлит,

Bugs happens. Попей валеума

> а если есть дампы перехваченного траффика - все они могут быть расшифрованы.

Не надо выдумывать.

anonymous
()
Ответ на: комментарий от Sylvia

> которые на самом деле ничего не стоят.

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

> и все прочие из этого урок извлекут

кстати и вас в этой ветке это касается

elipse ★★★
()

линухе капец!

каптча wasing

anonymous
()
Ответ на: комментарий от Sylvia

> и последствия еще вылезут

последствия не вылазят вот долбоящры - могут :))))

elipse ★★★
()

А зачем вообще ментейнер полез править код OpenSSL??=-O Нечего не имею против Debian, но ИМХО почему бы было не написать настоящим проффесионалам, которые пишут OpenSSL, похоже это один из недостаков открытого кода, каждый может зделать вот такую гадость, в данном случае подставил пол мира под ствол...*BRAVO*

ZANSWER
()

а мне мама говорила юзать old stable, а я не слушал :(

Muromec ☆☆
()
Ответ на: комментарий от ZANSWER

> почему бы было не написать настоящим проффесионалам, которые пишут OpenSSL

Вы вообще читать умеете ? дебиановцы _ПИСАЛИ_ авторам openssl про эту строчку которую закоментровали. писали в 2006 году. А авторы openssl положили на их письмо.

> похоже это один из недостаков открытого кода

какой ? лень и тупость разработчика ? Вы не поверите - но это общечеловеческая проблема ;)

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

угу и для этого не обязательно быть разработчиком открытого кода ;)

Eshkin_kot ★★
()
Ответ на: комментарий от Eshkin_kot

> дебиановцы _ПИСАЛИ_ авторам openssl про эту строчку которую закоментровали. писали в 2006 году. А авторы openssl положили на их письмо.

т.е. авторы openssl должны были этот быдлопатч немедленно в мейнстрим принять, чтобы не одни дебьянщики сейчас локти кусали?

Crocodille
()
Ответ на: комментарий от Crocodille

> т.е. авторы openssl должны были этот быдлопатч немедленно в мейнстрим принять, чтобы не одни дебьянщики сейчас локти кусали?

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

elipse ★★★
()
Ответ на: комментарий от elipse

List: openssl-dev Subject: Re: Random number generator, uninitialised data and valgrind. From: Ulf_Mцller <ulf () openssl ! org> Date: 2006-05-01 22:34:12 Message-ID: 44568CE4.9020906 () openssl ! org [Download message RAW]

Kurt Roeckx schrieb: > What I currently see as best option is to actually comment out > those 2 lines of code. But I have no idea what effect this > really has on the RNG. The only effect I see is that the pool > might receive less entropy. But on the other hand, I'm not even > sure how much entropy some unitialised data has. > Not much. If it helps with debugging, I'm in favor of removing them. (However the last time I checked, valgrind reported thousands of bogus error messages. Has that situation gotten better?)

Вопросы?

anonymous
()
Ответ на: комментарий от anonymous

List:       openssl-dev
Subject:    Re: Random number generator, uninitialised data and valgrind.
From:       Ulf_Mцller <ulf () openssl ! org>
Date:       2006-05-01 22:34:12
Message-ID: 44568CE4.9020906 () openssl ! org
[Download message RAW]

Kurt Roeckx schrieb:
> What I currently see as best option is to actually comment out
> those 2 lines of code.  But I have no idea what effect this
> really has on the RNG.  The only effect I see is that the pool
> might receive less entropy.  But on the other hand, I'm not even
> sure how much entropy some unitialised data has.
>   
Not much. If it helps with debugging, I'm in favor of removing them. 
(However the last time I checked, valgrind reported thousands of bogus 
error messages. Has that situation gotten better?)


Вопросы?

anonymous
()

apt-cache show openssl

Package: openssl Priority: optional Section: utils Installed-Size: 2296 Maintainer: Debian OpenSSL Team <pkg-openssl-devel@lists.alioth.debian.org> Architecture: i386 Version: 0.9.8c-4 Depends: libc6 (>= 2.3.6-6), libssl0.9.8 (>= 0.9.8c-1), zlib1g (>= 1:1.2.1) Suggests: ca-certificates Conflicts: ssleay (<< 0.9.2b) Filename: pool/main/o/openssl/openssl_0.9.8c-4_i386.deb

Etch r0

то есть все этчи этим не болеют, я так понимаю ?

anonymous
()
Ответ на: комментарий от anonymous

между прочим предсказуемость генератора случайных чисел существует в windows 2000 и XP. ознакомьтесь : http://www.computerra.ru/magazine/344158/

>Как уже сообщалось, Бенни Пинкас, Цви Гуттерман и Лео Доррендорф (Benny Pinkas, Zvi Gutterman, Leo Dorrendorf), криптографы из университетов Хайфы и Иерусалима, вскрыли схему работы генератора псевдослучайных чисел, используемого Microsoft во всех криптоприложениях Windows 2000. Исследователи проанализировали стойкость подсистемы защиты и выявили в ней серьезнейшую уязвимость. В частности, они обнаружили, что из-за слабой схемы генератора злоумышленники могут всего лишь по одному внутреннему состоянию алгоритма предсказывать большое количество криптоключей, вырабатываемых в ОС. Причем не только ключей для будущих потребностей, но и уже сгенерированных.

>Windows 2000 по сию пору используется многими компаниями и организациями, оставаясь, согласно общим оценкам, второй по популярности операционной системой Microsoft после XP. Но когда разнеслась весть о слабостях в PRNG (pseudo-random number generator), встал вопрос об уязвимости крипто в более новых системах, XP и Vista, - можно ли и их атаковать аналогичным образом?

>Поначалу реакция Microsoft была довольно уклончивой и сводилась к заверениям, что последние версии Windows "содержат разнообразные изменения и доработки в схеме генератора случайных чисел", но затем Редмонд все же признал, что Windows XP тоже уязвима для атаки, описанной в работе Пинкаса, Гуттермана и Доррендорфа.

теперь сравните:

Майкрософту указывают на суествующую уязвимость во всех системах 2000/XP - они лишь отмахиваються, пытаясь представить ее несерьезной. Уязвимость так и не исправлена

разработчики Debian сами находят проблему, информируют сообщество, сразу же выпускают необходимый патч.

//Vaness

anonymous
()
Ответ на: комментарий от anonymous

> то есть все этчи этим не болеют, я так понимаю ?
"болеют" на самом деле все
http://blog.drinsama.de/erich/en/linux/2008051401-consequences-of-sslssh-weak...
....
Fixing the bad key-generation is just half of the deal.
"Recalling" all the keys in use out there is the big challenge, that affects all systems using SSH (and to a different extend, SSL).
The most reliable way is if all other distributions would release a security update as well, which refuses to accept the keys that were generated by vulnerable Debian systems.

...
Let me just repeat it in other words: Any Linux/Unix/*BSD system is vulnerable that grants access to a key that was generated on an affected Debian or Ubuntu system. (Until the system has a reliable detection method of such weak keys.) Keys are usually generated on the users workstation, so if any of your users is or was potentially running Debian or Ubuntu ... you get the idea.
...

а вообще,полезно все прочитать

elipse ★★★
()
Ответ на: комментарий от elipse

вообще же, если на стороне битого дебиана будет сгенерирован новый "правильный" ключ, то конектящиеся к нему и ретхат и фря со старым ключём в ~/.ssh/known_hosts скажут "да идите вы нафик! ай синк э мен-ин-зе-миддл! смените ключ!"

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

anonymous
()
Ответ на: комментарий от anonymous

> так что лучше читать нормальные секурити обзоры, а не всех подряд.

не передергивайте и там совсем не об этом, мне все переводить лень и нет времени.

Erich Schubert из Debian - это "кто попало" ? :)))

ладно , вот еще "не авторитет"

http://metasploit.com/users/hdm/tools/debian-openssl/

The Impact
All SSL and SSH keys generated on Debian-based systems (Ubuntu, Kubuntu, etc) between September 2006 and May 13th, 2008 may be affected. In the case of SSL keys, all generated certificates will be need to recreated and sent off to the Certificate Authority to sign. Any Certificate Authority keys generated on a Debian-based system will need be regenerated and revoked. All system administrators that allow users to access their servers with SSH and public key authentication need to audit those keys to see if any of them were created on a vulnerabile system. Any tools that relied on OpenSSL's PRNG to secure the data they transferred may be vulnerable to an offline attack. Any SSH server that uses a host key generated by a flawed system is subject to traffic decryption and a man-in-the-middle attack would be invisible to the users. This flaw is ugly because even systems that do not use the Debian software need to be audited in case any key is being used that was created on a Debian system. The Debian and Ubuntu projects have released a set of tools for identifying vulnerable keys. You can find these listed in the references section below.



elipse ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.