Názory k článku Heartbleed bug: vážná zranitelnost v OpenSSL

Diky, pekny uvod! Konecne neco jineho nez ta spousta domnenek a dojmu, co se nam tu v poslednich dnech roji… :)

+256

C++11 by úplně stačilo

Dakujem za clanok. Ak som to spravne pochopil tak utocnici maju tym vecsiu sancu ziskat moje udaje cim castejsie sa prihlasujem, cize ked stahuejem maily raz za 10 minut tak ma maju skoro urcite, ale ked ako admin menim nastavenie crona raz za mesiac tak by museli mat riadne stastie aby ziskali moje heslo.

Sice je to plné nesrozumitelných slov, co mě uráží, ale to málo co jsem rozumněl mi dalo jakous takous představu o problematice...

V 90. letech jsem trochu přičuchnul k programování podobných kritických aplikací a vždy platilo, že pokud v programu používám citlivá data (heslo, klíč, ale i rozšifrovanou komunikaci), musím je držet v paměti jen po nezbytnou dobu a před uvolněním pamětí vymazat (přepsat nejlépe náhodným řetězcem). Právě proto, aby pak někdo nedostal alokovanou paměť se zbytkem citlivých údajů. Toto je absolutní požadavek a má přednost před jakýmikoliv nevýhodami (snížení propustnosti, ...).

Jak je možné, že tak základní pravidlo ignorují vývojáři OpenSSL? To to opravdu psala tlupa nadšenců bez základních znalostí o bezpečném programování?

Nevim nic o tom ze by na normalnim OS za normalni situace mohla aplikace cist pamet, kterou nema pridelenou. To ze system muze pridelit kus pameti kterou predtim pouzivam (a nevycistil ) prohlizec, je jedna vec. To ze by si ji OpenSSl melo nejdriv vycistit ... uz druha.

Dnes se za správné řešení (pokud už chcete nebo musíte používat jazyk s explicitním memory managementem) považuje používat takové implementace malloc a free které znemožňují podobné úniky dat. Chtít po programátorech aby data z paměti mazali přímo v kódu své aplikace je pro ně spousta práce a hlavně se v tom velmi lehce dá udělat chyba.

Bohužel vývojáři OpenSSL si udělali vlastní implementaci malloc a free která je z pohledu bezpečnosti úplně špatně, a tím vedla k tomuto problému (Heartbleed).

Víc se dá dočíst například na http://it.slashdot.org/story/14/04/10/1343236/theo-de-raadts-small-rant-on-openssl

Víc se dá dočíst například na http://it.slashdot.org/story/14/04/10/1343236/theo-de-raadts-small-rant-on-openssl

Panebože, zneuznaný sociopat opět radí. Kdy zas bude nějaká "pomooooc, krachujeme" sbírka na jeho OS?

Theo De Raadt je kontroverzní osoba, ale myslím si že osobní útoky sem nepatří - v tomto případě má totiž pravdu.

Jenomže problém je, když dostanu třeba čtyřkilový blok vedle používanýho 16kilovýho, kde jsou citlivý data.

Takže nestačí jenom mazat RAMku, ale ještě je celkem dobrý validovat komunikaci s vnějším světem. "A podmínka if(RealDataLength != ReceivedDataLength) throw EBrokenPacketError" nesmí nikde chybět. Průšvih je, že tohle je tak triviální věc, že každý bere jako samozřejmost existenci téhle podmínky a ani se neobtěžovali napsat na to nějaký unit test!

Jenomže problém je, když dostanu třeba čtyřkilový blok vedle používanýho 16kilovýho, kde jsou citlivý data.
Jenže to není problém této chyby. Tady se opravdu posílají v heartbeat response uvolněná data z heapu. Nečtou se používaná data.

Mýlíte se, neposílají se data uvolněná z heapu. Princip chyby je v tom, že se vezme délka payloadu podstrčená útočníkem, alokuje se potřebný buffer pro odpověď a do toho bufferu se zkopíruje payload dat z requestu. Co je v paměti kolem requestu nikdo neví, může to být alokovaná i nealokovaná pamět. Více viz
http://blog.cryptographyengineering.com/2014/04/attack-of-week-openssl-heartbleed.html

Nene. Já jsem to pochopil takhle:
1. Útočník pošle ping s daty 16 Bytů a požadavkem na 64kB.
2. Server alokuje paměť pro přijatý paket (řekněme 4kB ve widlích - minimální objem). Co je uloženo kolem je mu jedno.
3. Server odešle požadovaných 64kB, ty 4kB jsou na začátku.
4. Útočník chytne odpověď a zahodí první 4kB dat. Má 60kB heapu ze serveru.
5. S každým opakováním může získat jiný kus RAMky.

No a v těch blocích za alokovaným bufferem už je to loterie, co se v nich najde. Může to být vyplněný nějakou neutrální hodnotou (třeba 0xdeadbeef jak doporučuje McConnel), náhodná hodnota, nebo tam může být přihlašovací paket jinýho uživatele, ketrý čeká na parsování. Útočník dostane blok binárních dat a musí je ještě parsovat, aby zjistil, co vlastně (ne)má. A pokud chce třeba 1MB RAMky, musí dotaz opakovat a nějak si poskládat image RAM. Což chvíli trvá a RAM se při tom dynamicky mění... Takže kumšt není vytáhnout 60kB RAM, kumšt je umět rozpoznat, co přišlo a něco s tím podniknout. A štěstí je rovnou chytnost data, který potřebuje.

Každopádně nevím, jestli je to víc chyba, nebo ostuda.

Pěkný

Díky, konečně jednoduchý a jasný článek v češtině, kde je popsáno, v čem je ta chyba.

Je az zarazejici ze problem se opravuje vypnutim heartbeat, namisto toho, aby se velikost dodanych a odeslanych dat kontrolovala/nas­tavovala spravne!

A jako pridavek bych pridal moznost logovani kdyz prijde utok (lze poznat podle rozdilu velikosti)

K jaké paměti má vlastně OpenSSL přístup? Z logiky věci by měly být paměťové prostory jednotlivých procesů oddělené. Nebo je paměť společná pro celý HTTP server, včetně všech modulů, interpretů a podobně?

Pokud ano, tak mi to připadá jako dost velký návrhový nedostatek - v porovnání například s IIS, kde jsou třeba FastCGI moduly zcela odděleny (i co se přístupových práv týče).

OpenSSL má přístup k celé paměti aktuálního procesu který tu knihovnu používá. To platí na Windows stejně jako na Unixech. Pokud jde o Apache httpd, tak tam jde o modul mod_ssl, který realizuje SSL/TLS, a běží ve stejném procesu který obsluhuje spojení s klienty. Pokud v tom samém procesu běží například PHP, je k dispozici spousta dat, ale i pokud je aplikační zpracování v jiném procesu (např. PHP přes FastCGI, nebo třeba aplikační server připojený přes mod_proxy_ajp) tak je v paměti procesu celkem dost dat - například tělo i parametry HTTP požadavků, což mohou být i přístupová jména, hesla nebo autorizační cookie - takže je to úplně stejné jako u IIS.

Je jasné že přes OpenSSL teče samotná komunikace s hesly a vůbec tím vším, ale jedná se mi spíš o to, jestli by se v dotčené čísti paměti mohly vyskytnout i interní data serveru (například PHP sessions, hodnoty proměnných a tak podobně). To by byl IMO mnohem větší průser.

Kdyz si v C naalokuji pamet co je obsahem? Nemuze se stat, ze tam budou data treba z uplne jineho procesu co jiz danou pamet uvolnil? Copak se pri uvolnovani pameti ten usek napred prepisuje nejakymi nulami?

Alokace paměti má dvě vrstvy: procesovou a jadernou. Jaderná alokuje vždy po stránkách, jinak to neumí. Ty samozřejmě mohly patřit jiné aplikace, a tak je při alokaci vždy vynuluje. Takže k úniku dat z jiné aplikace takhle dojít nemůže. Uvnitř procesu se pak tyto stránky rozdělují na menší jednotky, protože datové struktury málokdy potřebují celou stránku. Ty se po dealokaci recyklují (volání jádra jsou dost drahá, proto se alokátor snaží je minimalizovat), ale to už nikdo nemaže a tak při další alokaci můžou být na naalokovaném místě dříve smazaná data toho samého procesu.

Inu, flejmy na tema bezpecnost MS vs OSS maji na par let predem urceneho viteze. Domnivam se, ze dusledek bude vetsi obezretnost korporatu nez pouziji kod, ktery napsal "kdejaky Jarda".

Nekdo by mohl argumentovat - a co MS08-067? Chyba MS08-067 sice umoznovala vzdalene spustit kod, ale jen pokud byly do internetu vystrceny porty, ktere tam nemaji co delat. Tohle (https://news.ycombinator.com/item?id=7576389) je trochu jine kafe…

MS10-049

No tohle je na urovni exploitu v prohlizeci, ktere jsou (bohuzel) bezne. Utocnik musi dosahnout toho, ze obet navstivi kompromitovany web…

Prijde mi, ze na tuto knihovnu "nejakeho Jendy" bylo spolehano zejmena proto, ze to pouzivaji vsichni, tak to musi byt ok. http://permalink.gmane.org/gmane.comp.security.cryptography.randombit/3341: "Overall, I would say that yes, OpenSSL is a huge mess for application
developers. In that sense, it's very bad. On the other hand, it's the
most thoroughly reviewed open source crypto implementation, and hasn't
had very many security bugs found in the library per se. " Toto ("most thoroughly reviewed open source crypto implementation") byla asi jen dobra vira…

Jinak by tohle nezustalo 2 roky nepovsimnute:
/* Enter response type, length and copy payload */
*bp++ = TLS1_HB_RESPONSE;
s2n(payload, bp);
memcpy(bp, pl, payload);

// hodnotu promenne payload kontroluje utocnik

Moc by som sa netesil ak MS este nema zadne vratka tak ich urcite dostane. Preco? Sloboda nieco stoji a na vychode je taka krajina kde ludia citaju azbuku, a maju jadrove hlavice. Je mozne ze za tyzden uz bude tako krajina susedit zo Slovenskom. Putina by nesledoval len blazon.
Len tak som si stiahol openSSL zdrojaky ci su naozaj take necitatelne. Pre kratkost casu som si vybral kod AES. Dalo by sa mu vytknut ze je tam malo komentarov a ze mena premennych su striktne dvojznakove niekedy doplnene cislom (napr. rk[5] = rk[1] ^ rk[4]; ). Ale myslim ze je ten kod pochopitelny.

Chápu vaše znepokojení z pozvolna nastávajícího souseda, ale už jste zjistil co to znamená to doplnění číslem? ;-) Jedna z mých oblíbených funkcí "doplňování číslem" v C je že to je v podstatě jen makro - takže se a[b] převádí na *(a+b), takže a[b] je to samé co b[a] neboli by se ten příklad dal přepsat na rk[5] = 1[rk] ^ 4[rk]; a to teprve vypadá zajímavě! :-)

V principu ano, v reálu ne:

T a[];
a[b]

je totiž to samé co *(a+sizeof(T)*b)

a[b] je sice to samé jako *(a+b), ale ukazatelová aritmetika není komutativní, tedy a + b ≠ b + a ;-)

„Je mozne ze za tyzden uz bude tako krajina susedit zo Slovenskom.“

A za 14 dní s ČR! :-)

„a ze mena premennych su striktne dvojznakove niekedy doplnene cislom“

Někdy jsou dokonce jména proměnných doplněná jinými proměnnými! (např. bitmap[i][j])

Aj si za tym „a ze mena premennych su striktne dvojznakove niekedy doplnene cislom“ stojim, daval som tam priklad na dvojznakove rk[ 7] = rk[ 1] ^ rk[ 6];
Pridavam priklad na dvojznakove doplnene cislom tp1 = rk[j]; A pre upresnenie myslim "tp1".
Ked vtipkujeme na temu hranic CR tak pridam este taky smiesny dodatok. Nejaky rusky oddiel zabludi prejde hranice SR sporadicky odpor rozdrti a po tych 14 dnoch 96.8% slovakov bude suhlasit v referende s pripojenim k Rusku :-)

http://www.cvedetails.com/cve/CVE-2008-1446/

To by mě zajímalo, jak se ty data teda načetly, když se nějak nebrala v úvahu ta délka.

Ten článek je bulvárního typu ..
To sem si o ROOT nemyslela že klesne až takhle.

V článku ůmyslně a zcela chybí označení kterých SSL knihoven a jaké verze se to týká což je informace důležitá než blekotání okolo s neurčitostí...

Chybí i pitva kódu v té ssl knihovně přesně kde to je způsobeno .

Nic si z toho nedelejte, i funkcne negramotni lide s touhou hodnotit se u nas najdou...

Upřímně řečeno, pokud vám ani teď nedocvakne, že jediná (JEDINÁ) správná cesta jsou vysokoúrovňové architektury a ne zrůdnosti typu C, RISCové instrukční sady, UNIX, vonneumanovská architektura atd., tak vám to nedojde nikdy.

A ty vysokourovnove architektury budou napsany v cem konkrentne ? Rozkouskovani a parsing packetu bude vzdy docela nizkourovnova prace nehlede na programovacim jazyku. Musim prece cist presne jak to mam RFC, ne doufat, ze to snad dopadne dobre a ten int bude opravdu 32 bitu a jeste se to spravne prehodi podle endianity. Na druhou stranu bullet proof memory alokator by docela hodil.

„Rozkouskovani a parsing packetu bude vzdy docela nizkourovnova prace nehlede na programovacim jazyku. Musim prece cist presne jak to mam RFC, ne doufat, ze to snad dopadne dobre a ten int bude opravdu 32 bitu a jeste se to spravne prehodi podle endianity.“

K tomu ale přece vůbec není potřeba memcpy, které ti omylem přepíše kus paměti, která s tím vůbec nesouvisí.

A například v Pythonu se parsuje binární paket takto:

struct.unpack("!I",by­tearray(q[16:20]))

Kupodivu je endianita jasně daná, i je jasně dané, že je to 32bit unsigned.

A ten struct.unpack to nakopiruje do neuronovy pameti telepaticky?

Ne, proč? Většina toho může být také naprogramována ve vyšším jazyce a ten základ dělá nejnutnější a uhlídat u něj hranice je podstatně jednodušší, než když se to dělá pokaždé znova v rozsáhlé implementaci kdejakého protokolu.

Napr. v jazyce Erlang jsou na praci s binarnimi daty celkem elegantni syntakticke konstrukce ktere jsou velmi rychle (mikrosekundy). Delat v tom nejaky binarni protokol je radost. Na ASN1 tam je knihovna a pod. Integery jsou tam pro jistotu nekonecne. Na SSL je tam systemova interni knihovna (nevim jak moc kompletni).

Neda se to embedovat do jinych jazyku (jako treba Lua).

Jinymi slovy - daji se najit potecionalne zajimave cesty ci jejich naznaky.

Vsetko sa to zaklada na viere ze kniznice v nejakom jazyku su nezranitelne. Odporucil by som sa pozriet na videa z defcon tusim 19. Prednasajuci napisal program v c nieco ako hello world co vypisoval co bolo v prikazovom riadku ako parameter. Pomocou printf funkcie spravnych parametrov co pretiekli v pameti ziskal prava root, len tak za 40 minut prednasky.

Jasne ... doporucil bych to zmastit v .NET ... tam prede kazdej na tom jednom radku uvidi, ze to nedela nic spatnyho ...

.NETové VM je téměř stejně tristní, jako x86-64 (téměř, protože disponuje alespoň bezpodmínečně nutnými základy jako bounds checking či garbage collector). Chcete-li vědět, co znamená pojem "vysokoúrovňová architektura", začněte studiem architektury Scheme-79.

U .NETu se řeší spousta věcí nikoliv na úrovni VM, ale jazyka a kompilátoru.

Prelozil som si zaciatok. "Scheme-79 je jednocipovy mikroprocesor ktory implementuje dialekt jazyka lisp". Co by to bolo v realnom serveri? Nieco ako matematicky koprocesor pre 386? Ako hlavny procesor si to neviem predstavit hlavne preto lebo vsetky program by sa museli prerobit z x86 na lisp, to je tak 20 rokov prace ludstva. Viem si to predstavit v dalekej buducnosti ako pocitac lode Enterprise a namiesto lispu by bola anglictina napriklad.

sorry nie implementuje ale interpretuje

Jednou k tomu stejně dojde. Například, až bude bude jednou průmysl donucen přestat hopkat kolem vonneumanovské architektury a přejít ke skutečně masivně paralelním architekturám (dataflow), protože ze samotné podstaty sekveční architektura prostě nejde donekonečna chaoticky oblepovat "zlepšováky" typu OoOE.

Jinak co se týče obhajoby tvrzení, že eliminovat složitost výpočetních systémů u zdroje (tzn. v hardwaru) je nejen správné, ale i nutné, nemá-li tato složitost dosáhnout skutečně absurdních a nezvladatelných rozměrů, mnohem více je k dočtení zde.

Tak by mne zajimalo, nakolik je zranitelna custom opatchovana openssl s podporou jisteho cryptohw(SPARC T4). Asi nezbyde nic jineho nez si to prakticky hacknout abych zase prudil.
No auditori zatim neprudi. Nechame to vyhnit.

V případě, že používám správce hesel - Sticky Password, musím změnit stávající hesla na serverech, které byly chybou zasaženy? Jak moc je nebezpečné, je nezměnit?

Děkuji za odpověď.