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.
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.
ČLÁNKY DO MAILU