Vážný bezpečnostní problém s OpenSSL v Debianu

Debian ... delaj marchy ... a hajzl maj na chodbe ;-)

(přebráno z abclinuxu)

> More details show that someone seriously fucked up in debian.

Well, this Kurt has seriously asked for details on the relevant openssl-dev list:

http://marc.info/?l=openssl-dev&m=114651085826293&w=2

And see what "arrogant as usual" Ben Laurie states:

http://www.links.org/?p=327

"they should contribute their patches upstream to the package maintainers. Had Debian done this in this case, we (the OpenSSL Team) would have fallen about laughing, and once we had got our breath back, told them what a terrible idea this was."

Kurt has clearly done so, and I know personally of another totally ignored patch from our company and I have heard in the past about OpenBSD people trying to send patches to OpenSSL maintainers to no avail.

The OpenSSL maintainers have proven not to read their mail, they aren't interested in cleaning up their big mess.

Laurie also states "never fix a bug you don t understand" and this OpenSSL "hero" seems to forget that something that seems smart and OK now and here can be plain bad and ugly when looked at with some more distance or knowledge.

His "Adding uninitialised memory to it can do no harm and might do some good, which is why we do it." is pure arrogant and shortsighted shit to me.

+++chefren

AHA. Může to být důvod proč dnes najednou přestalo moje putty znát moje HTPC? Nebo se mi tam někdo vloupal?

Tezko hadat, kdyz nereknete distribuci, ale klice by se jen tak samy od sebe pregenerovavat nemely {i kdyz snad v Ubuntu bylo soucasti patche testovatko slabosti klicu, takze je mozne, ze vam to hezky windowsacky pregeneroval - ale podrobneji jsem jejich ohlaseni neprohlizel).

Distribuci jsem snad udal. Přesněji ještě Ubuntu 7.10. Neměl jsem problém s přihlášením... jen mi putty vypsalo že má server jiný klíč než pod kterým ho znalo do teď.

Součástí updatu v Ubuntu je automatický „přegenerátor“ klíčů. Zkuste se mrknout do /var/log/dpkg.log, jestli tam je instalace balíčků open{ssl,ssh,vpn}-blacklist, které tohle dělají.

Pokud update bez explicitniho souhlasu uzivateli pregeneruje klice, a zpusobi, ze se nenaloguje, tak to je bug.

No ten update napíše: V některých klíčích byl problém a proto byly přegenerovány (plus seznam klíčů), ale na nic se neptá. Nějak to Ubuntu začíná windowsovatět :)

Tak tohle je krávovina.

Dneska do ubuntu přišla oprava. Vypíše to varování a informuje o novém nástroji, který umí zkontrolovat, jestli je daný klíč OK nebo ne.

Ale teda nepřihlásil jsem se do VPN, protože ten klíč byl kompromitovaný a openvpn to teď kontroluje. Řekl jsem tedy adminovi o nový klíč. Jak bych to obcházel ale, přiznám se, nevím.

Tyhle základní balíky jdou přímo z Debianu, vývojáři ubuntu nemají potřebu tam nic měnit. A jestli windowsovatí Debian, tak to bych fakt neřekl :-)

Sam ted resim upgrady SSH, SSL a spol a delam to rucne. Pokud server zjisti, ze klic je backlistovan, nabidne uzivateli regeneraci (ktera, pokud jsem si vsiml, nejde obejit), kazdopadne to nedela bez vedomi uzivatele. Ovsem zde zalezi na tom, jaky level dotazu mate nastaveny u dpkg. Pokud je tam "na nic se neptat", nedivte se, ze vam Debian/Ubuntu klice pregeneruje a ve vypisu si toho nevsimnete. A pokud server spravuje nekdo jiny a vy na nem mate jen ucet, rozhodne by bylo slusne, kdyby vam dal o zmene klice zpravu. Pokud vam ji neda, vysledek je asi jasny.

A jeste ktomu VPN. Obejit to jde, openVPN proste jen vola ten chceckovaci nastroj a podle jeho vysledku bud povoli nebo zakaze pristup. Pokud si "hacknete" svuj system a ten checkovaci nastroj nahradite necim, co vraci true, projde to. Tohle ale doporucuju jen jako nouzovku, pokud je nutne stary klic pouzit k tomu, abyste ho nahradili novym.

"Installing these packages on hosts with weak keys will cause the ssh server to regenerate its keys." - http://wiki.debian.org/SSLkeys#head-974d8e1e1a4fd26f5ef20635eda3f58860d9569b

Když SSH server míval zranitelný klíč, kdokoliv se mohl vydávat za něj, tedy veřejný klíč neplnil svou funkci, tedy jako by nebyl. V takovém případě když SSH klient detekuje změnu veřejného klíče, neměl by řvát a jen se zeptat jestli uživatel důvěřuje novému klíči. (Samozřejmě se nedá očekávat že tuto situaci budou rozpoznávat SSH klienti ne-debianího původu.)

Nejsem si 100% jistý příčinou, ale mám dojem že se mi na debianu stalo to samé, změnil se mi klíč (zřejmě při aktualizaci) a já se pak nemohl vzdáleně přihlásit.

Díky za nakopnutí. Bylo to tam.

Nějak té zprávičce nerozumím. Vyplývá z ní bud, že vývojaři Debianu zanesli do OpenSSL svým patchem chybu a všimli si jí až ted, ale pak nechápu, proč se oprava této chyby musela dostat do hlavní vývojové větve, nebo že v OpenSSL byla už dlouho chyba, kterou vývojaři Debianu opravili už v září 2006 a ted se jim konečně podařilo tuto opravu protlačit do hlavní vývojové větve. V tom případě by ale Debian a všechny odvozené distribuce byly za vodou a název zprávičky je nesmyslný.
Co se tedy vlastně stalo?

1. V zari 2006 vyvojari _debianu_ pri "oprave" cehosi vyrobili vazny bug v openssl
2. Tento bug zustal v _debianu_ jako jejich interni patch a nedostal se zpet k vyvojarum openssl (kteri by jim asi rekli ze je problem)
3. Ted se na to prislo

Lépe to jde vidět přímo z debianího bugu, ale pokusím se udělat rychlé shrnutí (P.S. Je to psané laickým jazykem, tak mě pokud možno nekamenujte za špatnou terminologii, případně mě v klidu opravte v reakci).

Někdy v roce 2006 někdo nahlásil, že programy slinkované s openssl se nedají valgrindem skoro vůbec debugovat, protože to na jednom hodně používaném místě hlásí přístup do neinicializované paměti. Chvíli se to diskutovalo a oprava této chyby nakonec udělala to, že onen kus ze zdrojáků vymazala (zakomentovala).

Bohužel tento kus přidával další entropii do generátoru náhodných čísel a odstraněním této jedné řádky se snížila "náhodnost" generátoru náhodných čísel. Vzhledem k tomu, že z tohoto generátoru vychází další šifry (např. generování RSA, DSA klíčů), tak se snížila bezpečnost těchto klíčů, protože jsou lépe predikovatelné.

S hlavní vývojovou větví to nemá vůbec nic společného.

P.S.: Celá tato záležitost ukazuje ještě na jednu věc - jak je důležité psát komentáře v kódu, který je "divný".

Velice děkuji za podrobnější vysvětlení ... Já vím, že je těžké v zařízení, které je ze své podstaty deterministické získat náhodnou hodnotu, ale nezdá s mi, že čtení/nečtení neinicializované proměnné mělo tak zásadní vliv na výslednou náhodnost :)

To neni uplne presne, umazani prace s neinicializovanou pameti samo o sobe by zadny kriticky dopad nemelo (entropie prece nemuze zaviset jen na tom co je zrovna v ram).

Bohuzel nekde jinde byl pak umazan (zakomentovan) jeste podobny kus kodu a ten zpusobuje tu "kriticnost".

Tak. Výsledkem bylo, že jediným zdrojem entropie byl PID procesu. Tedy maximálně 2^15 bitů. To je opravdu hodně málo - vemte si, že "na první pohled" lze poznat, jestli je nějaký klíč takto postižený nebo ne - máme na to teď v debianu-ubuntu nástroj :-)