Názory k článku Heartbleed Bug: jak se k chybě v OpenSSL staví české i světové firmy

Netrápí je proto, protože zranitelnost je dána kódem na serveru, nikoli obsahem hlavičky, kterou server vrací. A kód zpracovávající SSL je na klient1 až klient4.rb.cz v pořádku.

Je možné, že hlavička vracená serverem je vymyšlená a server je něco úplně jiného. Je možné, že před serverem je nějaká brána, na které je SSL zakončeno. Je možné, že mají na serveru OpenSSL 1.0.1e s patchem. Je možné, že mají na serveru OpenSSL 1.0.1e s vypnutým heartbeats. Vzhledem k tomu, že servery mají čerstvé certifikáty, tipoval bych si, že servery postižené byly a platí tedy některá z variant s opravenou verzí 1.0.1e.

Dobrý den, pokud použiji parafrázi: mohli bychom na tato témata napsat krátkou zprávu, a krásnou :) Ale myslím, že potřebují o dost hlubší rozbor - zvlášť ta o "legálním stahování" a poplatcích za kopie. Připravujeme jej na začátek příštího týdne.

Ano, klidně tam může být verze 1.0.1e s opravenou chybou. Takto to má například Fedora 19, kde je stále verze 1.0.1e ale s patchem.

Podle verze toho moc usuzovat nemůžete, protože prakticky všechny stabilní verze distribucí opravují pouze bezpečnostní chyby, rozhodně neupgradují balíčky na novou verzi.

Např. u Debianu jsou to ta divná čísla a písmena za oficiální verzí: 1.0.1e-2+deb7u6

Ta otázka přece stojí jinak, běží naše banky na open source? Skoro určitě ne, a pravděpodobně vůbec nejedou na platformách kde se OpenSSL používá. Takže soráč, to co možná napadlo statisíce škudlilů co jedou na Linuxu nebo open source knihovnách ve Windows, to se velkých seriózní společnosti vůbec nemuselo dotknout...

No a jak jsou na tom naše banky?!?

to flv: :-/

A co se týká OpenSSL, pak mě odpověď dal jiný web, konkrétně zive.cz . Banky u nás OpenSSL nepoužívají. Jiné vyjmenované webové služby, které OpenSSL používají jsou pak dle zive.cz bez problému...

?...

V pořádku. To je tak těžké kliknout na odkaz v článku na test a zadat tam adresu?

NYNÍ v pořádku....a co dříve ?

Mají vydaný čerstvý certifikát, takže chybou asi postiženi byli. Pokud se přihlašujete privátním klíčem, není čeho se bát. Pokud jednorázovým heslem, záleží na implementaci – ale i kdyby se používalo symetrické šifrování a klíč pro jednorázové heslo byl v paměti serveru, je extrémně nepravděpodobné, že by jej útočník získal a dokázal rozpoznat.

Dodatek: TOTP používá sdílený klíč, takže server zná klíč pro vytváření jednorázových hesel. Samozřejmě to ale neznamená, že je ten klíč dostupný v procesu webového serveru, v bezpečné implementaci bude někde mimo a webserver se jen bude dotazovat jiné komponenty, zda uživatelovo heslo je správné.

Dle https://www.openssl.org/news/secadv_20140407.txt
může odposlouchávající útočník získat data nejen ze serveru, ale i klienta.

Stále mi není jasný princip chyby. Dle jednoho z výše uvedených komentářů nejde prvoplánově o rozšifrování odposlouchávaného spojení, ale o vyžádání si dat z paměti serveru i klienta - což může/nemusí vést (až následně) k získání priv. klíče a k rozkódování komunikace.

Mám tomu rozumět tak, že útočník může zasáhnout do komunikace KTERÉ NEROZUMÍ - zasláním nějakého TLS "příkazu" - a získat data z paměti ?

A teď k titulku: co když server bude záplatován a klient nikoli ?
Co může útočník získat ? Nic ? Nebo data z paměti klienta - čili typicky datový blok z prohlížeče (který např. může obsahovat priv. klíče certifikátů, hesla, ... ?

??? - jak to, že "blbě". Chápu to stejně. Tedy dle http://www.root.cz/clanky/heartbleed-bug-vazna-zranitelnost-v-openssl/

V paměti internetového prohlížeče, kde je na jedné záložce otevřený webmail, na druhé elektronické bankovnictví a na třetí stránka se vtipným videem by se ten server s vtipným videem mohl dozvědět zajímavé věci. Naštěstí žádný běžně používaný webový prohlížeč OpenSSL nepoužívá, moderní prohlížeče navíc používají systém jedna záložka - jeden proces.

A to jako podívat se kam? Ona jedna věc je co mají úředníci po kancelářích na stolech. A druhá věc co běží na serveru..

Koukám, minimálně jeden ten test je k ničemu.
Mě to hlásí

Server software: Not reported
Vulnerable: Possibly (might use OpenSSL)
SSL Certificate: Possibly Unsafe (created 7 months ago at Sep 2 10:35:43 2013 GMT)
Assessment: Wait for the site to update before changing your password

Přitom jsem tam nikdy neměl postiženou verzi a to OpenSSL je hodně ořezaný.

https://www.ssllabs.com/ssltest/ tenhle test mi příjde věrohodnější.

... no sorry - teď jsem si teprve přečetl též odkazovaný http://www.root.cz/clanky/heartbleed-bug-vazna-zranitelnost-v-openssl/ , jež je vice méně odpovědí. Moje chyba.

A jelikož zprávy TLS heartbeat jsou přenášeny uvnitř šifr. kanálu, tak (snad ?!) padá riziko odposlechu (útok MITM).
Tedy útok na klienta může vést "jen" server v rámci navázaného spojení.

Right ?

Není potřeba doufat, že mají servery tuto chybu opravenou si můžete sám snadno ověřit.

Pokud se použije opatchovaný distribuční balíček, zvýší se jen číslo distribučního updatu (třeba to deb7u6). Verze aplikace se ale samozřejmě změnit nemůže (byl aplikován jen ten jeden patch, nebyly provedeny všechny změny v dané verzi). Tohle číslo distribučního updatu se pak ani nemusí objevit v informaci o verzi, kterou o sobě poskytuje sám program (takže třeba Apache se od OpenSSL může dozvědět jen 1.0.1e, že má Debian ve verzi balíčku ještě -deb7u6 už se nedozví). Pokud by si administrátoři záplatu aplikovali sami, asi nebudou s číslem verze dělat vůbec nic. No a pokud jenom vypnuli při konfiguraci heartbeat, mohou klidně používat původní nezáplatovanou verzi 1.0.1e. Pokud si OpenSSL kompilují sami, připadá mi ta poslední varianta nejbezpečnější.

Útok lze vést jen v rámci spojení, ale je k tomu příležitost velmi brzy při navazování spojení, takže třeba (pokud vím) i když server vyžaduje přihlášení klientským certifikátem, k útoku může dojít dřív, než je to přihlášení vyžádáno. Útok na klienta tedy může přijít jen od serveru, ke kterému je klient připojen.

Útok pak spočívá v tom, že je možné z druhé strany přenést kus paměti procesu, ve kterém je SSL spojení navázáno. V té paměti může být ledacos – třeba komunikace z jiných spojení, ve které mohou být citlivé údaje. Z tohoto pohledu je to horší, než MITM útok – při MITM musí být útočník na trase mezi vámi a serverem, v případě heartbleed může být úplně kdekoli a tu komunikaci si přečte z paměti serveru. Jediné štěstí je, že si oblast paměti nemůže vybírat, ale dostane ten kus paměti, který zrovna sousedí s místem, kam se do paměti zapíše útočníkův požadavek.

Jinak Firefox, Chrome ani Internet Explorer OpenSSL nepoužívají, takže tam nebezpečí nehrozí. Z rozšířenějších protokolů pak připadá v úvahu útok na poštovního klienta nebo VPN klienta – pořád ale záleží na tom, zda ten program používá OpenSSL v postižené verzi. A další věc je, že případný útočící poštovní nebo VPN server se z klienta nejspíš nedozví nic, co by mu klient dříve neposlal dobrovolně. Riziko by bylo jen při používání většího množství účtů, kdy by se server mohl dozvědět něco patřícího pod ostatní účty.

Co to? Tady samozřejmě všichni vědí, jak se té chybě přezdívá. Je to i v názvu článku. Akorát se to píše Heartbleed, to "bleed" není žádná zkratka, ale prostě krvácení. Heartbeat (tlukot srdce) byl špatně implementován, a tak se z toho stalo heartbleed (krvácející srdce).