Heartbleed bug: vážná zranitelnost v OpenSSL

Ondřej Caletka 11. 4. 2014

Tento týden zahýbala světem zpráva o zranitelnosti knihovny OpenSSL, umožňující vzdáleně vylákat ze serveru důvěrné informace včetně privátních klíčů nebo hesel uživatelů. V dnešní analýze se pokusíme odpovědět na otázky, kde se daná zranitelnost vzala a co dělat, pokud vaše systémy byly také postiženy.

Co je to TLS heartbeat a k čemu slouží

Rozšíření pro heartbeating bylo do TLS a DTLS přidáno v RFC 6520. Jde o poměrně jednoduché zprávy uvnitř šifrovaného kanálu, velmi podobné třeba ICMP echo zprávám, které používá program ping. Kterákoli strana komunikace může během relace poslat heartbeat request a obratem z druhé strany obdrží heartbeat response.

Hlavní význam heartbeatingu je pro DTLS, tedy TLS nad nespolehlivými transportními protokoly, jakými je například UDP a DCCP. Protistrany si jím jednak periodicky ověřují, že spojení stále funguje, jednak díky volitelné délce zprávy je možné průběžně objevovat MTU cesty. V případě obyčejného TLS provozovaného nad spolehlivými transportními protokoly, jako jsou TCP nebo SCTP, je význam heartbeatingu nižší. Může ale sloužit jako výplňový provoz pro udržování aktivního spojení v NATech a stavových firewallech v době, kdy žádná skutečná data není potřeba přenášet. Nutno dodat, že stejnou funkcí disponuje i transportní protokol TCP, ovšem perioda jeho keepalive zpráv je v řádu hodin, což je pro většinu aplikací nepřijatelné. Mechanizmus obdobný heartbeatingu používá i OpenSSH (konfigurační volba se jmenuje ServerAliveInterval). Ve výchozím nastavení je však vypnuta.

V čem je problém

Stejně jako ICMP ping, i požadavek na TLS heartbeat obsahuje pole dat, které musí protistrana poslat zpět beze změn. Protože toto pole payloadu může být různě dlouhé, předchází mu ve zprávě dvoubajtová hodnota určující jeho délku. Potíž je v tom, že OpenSSL nekontrolovalo, zda délka payloadu udaná v požadavku na heartbeat není delší než délka celé zprávy.

OpenSSL tedy přijatou zprávu uložilo do paměti a vzápětí vygenerovalo odpověď, kterou vrátilo druhé straně. Do odpovědi bylo překopírováno tolik dat, kolik bylo v požadavku na heartbeat deklarováno, že obsahuje. Požadavek přitom ve skutečnosti mohl být kratší. OpenSSL tedy poslalo také část paměti, která bezprostředně následovala za místem, kam byl do paměti uložen příchozí požadavek. Detailní analýzu, včetně náhledu dotčených zdrojových kódů, na svém blogu zveřejnil Sean Cassidy.


Autor: Randall Munroe, podle licence: CC BY-NC 2.5

Jednoduše popsaný princip (XKCD 1354)

Co může být v uniklé paměti

Odpověd na otázku, jak závažná taková zranitelnost může být, zásadním způsobem ovlivňuje to, co se do oblasti paměti, která je útokem vyzrazena, obvykle ukládá. Firma Codenomicon, která zranitelnosti dala jméno a přišla s webovou stránkou Heartbleed.com tvrdí:

Bez použití jakýchkoli přistupových údajů se nám podařilo ukrást tajné klíče k našim X.509 certifikátům, uživatelská jména a hesla, rychlé zprávy, e-maily a důležité pracovní dokumenty.

Krádež uživatelských jmen a hesel, stejně jako e-mailů a dokumentů se dá celkem očekávat a vysvětlení je prosté − do stejné oblasti paměti se zřejmě ukládají data před zašifrováním, případně po rozšifrování. Protože obvyklá politika alokátorů paměti spočívá v přidělování naposledy uvolněné paměti, znamená to, že útočník může s každým novým heartbeatem soustavně získávat nové a nové kousky komunikace, třeba HTTPS protokolu v rozšifrované formě.

Co se týká privátního klíče k X.509 certifikátu, k tomu je část veřejnosti skeptická, zejména proto, že paměť alokovaná pro privátní klíče se po dobu života procesu obvykle neuvolňuje, takže by nemělo být příliš pravděpodobné, že se dostane do nebezpečné oblasti. Tímto argumentoval na svém blogu Robert Graham, z reakcí je však patrné, že přinejmenším za určitých podmínek je skutečně možné získat i privátní klíč.

Nejde jen o servery

Je důležité zmínit, že požadavek na heartbeat může přijít v libovolném směru. Útočit tedy může nejen klient na server, ale i server na klienta. Například webový prohlížeč používající zranitelnou verzi OpenSSL může být teoreticky požádán o heartbeat útočícím webserverem a nechtěně tak útočnému serveru prozradit části šifrované komunikace s jiným serverem. Takový scénář ale není příliš pravděpodobný.

Většina klientských aplikací běžně používaných uživateli (Firefox, Chrome, Thunderbird, Evolution) používá knihovnu NSS od Mozilly, takže tímto problémem postižena není. Potenciálně zranitelný v tomto směru může být například poštovní klient Mutt, nebo WPA supplicant.

První pomoc

Štěstím v neštěstí celého incidentu je, že rozšíření pro heartbeating v naprosté většině případů není nezbytné, obzvláště pro služby založené na spolehlivých transportních protokolech, jako HTTPS, IMAPS nebo SMTPS. Rychlé řešení, které je možné aplikovat na libovolný linuxový systém, tedy spočívá v zahazování požadavků na heartbeat pomocí netfilteru. Stejně tak je možné problém odstranit rekompilací knihovny OpenSSL s vypnutou podporou heartbeatingu.

Snad všechny nemarginální linuxové distribuce stihly zareagovat vydáním bezpečnostních záplat. Bezpečnostní týmy některých z nich, stejně jako další zainteresované subjekty, měly informace o zranitelnosti k dipozici dříve, než bylo CVE-2014–0160 zveřejněno, takže opravu problému bylo možné provést ihned po jeho zveřejnění. Jiné distribuce, jako například Gentoo, zareagovaly do 24 hodin od zveřejnění.

Je však potřeba připomenout, že po aktualizaci OpenSSL knihovny je nezbytné restartovat všechny služby, které ji používají, jinak bude služba nadále používat starou zranitelnou verzi. Zvláštní kapitolou jsou aplikace, které mají knihovnu OpenSSL linkovanou staticky. Takovou je například základní klient sítě Bitcoin. Toho je třeba aktualizovat také.

Je čas měnit certifikáty a hesla?

I když je zranitelnost známá veřejně teprve několik dní, ve zdrojovém kódu OpenSSL existovala poměrně dlouho. Nikdo nedokáže zaručit, že na podobný princip zneužití nepřišel už dříve někdo, kdo si jej nechal pro sebe. Uživatelská data služeb, které využívaly OpenSSL a měly povolený heartbeat, jsou tedy v ohrožení. Problém se podle všeho netýká protokolu SSH; ačkoli OpenSSH také používá některé funkce knihovny OpenSSL, vlastní SSH protokol je v něm řešen interně, neboť se výrazně liší od protokolu TLS.

Server Lupa.cz shrnuje reakci velkých provozovatelů služeb. Ti většinou buď potvrzují, že jejich řešení danou zranitelností netrpělo, nebo potvrzují opravu zranitelnosti a zároveň vyzývají uživatele ke změně hesla.

Stejným způsobem by se měli zachovat všichni zodpovědní správci postižených systémů, adekvátně k významu takových systémů. I když vyzrazení privátního SSL klíče nejspíše není zcela jisté, lze rozhodně doporučit všem významnějším službám vystavení nového certifikátu a revokaci stávajícího. Používání stejného certifikátu lze tolerovat u služeb zanedbatelného významu, kde by revokace představovala nepřiměřené náklady.

PKI model je v tom nevinně

Pozitivní na celé aféře je, že na rozdíl od podobně významných afér před lety nejde tentokrát o problém systému jako takového, o jehož vylepšení usiluje například pracovní skupina DANE. Jde jen o programátorskou chybu, ne nepodobnou té, kterou nedávno trpěla implementace TLS od Apple, či GnuTLS.

V této souvislosti je možná dobré připomenout známý zápisek OpenSSL is written by monkeys, který shrnuje poměrně nekonvenční přístup autorů knihovny k psaní kódu, který je plný zvláštních odsazení, skrytých volání funkcí a maker a dalších vychytávek, které jej činí velmi nepřehledný k pochopení či jakémukoli auditu.

Je až s podivem, kolik seriózních projektů, včetně takových, co si zakládají na čistotě kódu (např. OpenBSD), svěřuje veškerou důvěryhodnost síťové komunikace knihovně, jejíž zdrojový kód vypadá jako jeden velký bastl. Omluvou budiž uznáno, že jde o velmi starý software, jehož první verze byla zveřejněna již v roce 1998. Zajímavý námět ke zlepšení této situace nastínil výše citovaný Sean Cassidy: napsat SSL knihovnu ve vyšším programovacím jazyce, který by nebyl tak náchylný k programátorským chybám.

Našli jste v článku chybu?
Měšec.cz: Cestujte bez starostí, získejte výhodné pojištění

Cestujte bez starostí, získejte výhodné pojištění

120na80.cz: Fotografie z misí Lékařů bez hranic

Fotografie z misí Lékařů bez hranic

DigiZone.cz: Skylink zapojil nový transpondér

Skylink zapojil nový transpondér

Podnikatel.cz: "Okurku" vyřeší slevové servery. Už jim věřte

"Okurku" vyřeší slevové servery. Už jim věřte

DigiZone.cz: ČT veze bronz z klání televizní grafiky

ČT veze bronz z klání televizní grafiky

DigiZone.cz: Kanály Novy na Slovensku oficiálně?

Kanály Novy na Slovensku oficiálně?

120na80.cz: Krémy, nebo spreje na opalování?

Krémy, nebo spreje na opalování?

DigiZone.cz: Náhrada za nevrácená zařízení?

Náhrada za nevrácená zařízení?

Měšec.cz: Práce na tři směny? Neblázněte, mám doma psa

Práce na tři směny? Neblázněte, mám doma psa

Měšec.cz: Udali ho na nelegální software a přišla Policie

Udali ho na nelegální software a přišla Policie

Měšec.cz: Biip karta: recenze předplacené karty

Biip karta: recenze předplacené karty

DigiZone.cz: Noxon iRadio 1 W bude za pár měsíců

Noxon iRadio 1 W bude za pár měsíců

DigiZone.cz: Satelitní Flix TV vyráží do boje

Satelitní Flix TV vyráží do boje

Měšec.cz: Inspirujte se: kam investují čeští dolaroví milionáři?

Inspirujte se: kam investují čeští dolaroví milionáři?

Vitalia.cz: Recepty: Ač bez lepku, chutnají všem

Recepty: Ač bez lepku, chutnají všem

Měšec.cz: Vyplatí se spořit přes DPS?

Vyplatí se spořit přes DPS?

Lupa.cz: Vzali věc, která fungovala, a přidali internet

Vzali věc, která fungovala, a přidali internet

Lupa.cz: Zaměstnanec T-Mobilu ukradl data o zákaznících

Zaměstnanec T-Mobilu ukradl data o zákaznících

DigiZone.cz: Loewe: už i bezztrátové streamování hudby

Loewe: už i bezztrátové streamování hudby

Vitalia.cz: Máte chutě? Nejezděte do světa, ale do Dobřichovic

Máte chutě? Nejezděte do světa, ale do Dobřichovic