Závažná bezpečnostní chyba v OpenSSL 1.1.0

Vývojový tým OpenSSL informuje, že ve čtvrtek 10. listopadu odpoledne bude vydána verze 1.1.0c kryptografické knihovny OpenSSL. Opraveno bude několik bezpečnostních chyb. Jedna z nich je závažná. Větve 1.0.2 a 1.0.1 tuto chybu neobsahují.

8.11.2016 09:33 | Ladislav Hagara | Bezpečnostní upozornění

Komentáře

[j]

Chmm a kolikata to uz je? Dyt je to deravejsi nez flash.

[Tomáš Bžatek]

Naopak, vis jak to ted bude secure?

[JoHnY3]

S Flashem bych to vazne nesrovnaval. To je jeste uplne jina liga.

OpenSSL je hodne komplexni a dlouhodobe az konzervovany kod, ktery se zacal trochu vic uklizet myslim az po hearthbleed chybe. Situaci zhorsily a nebo mozna i zpusobily ruzne bezpecnostni statni certifikace, ktere neprimo podporuji co nejmensi zmeny v kodu a tim padem brani v jeho cisteni a modernizaci. Vysledkem byl dluh v udrzbe, ktery OpenSSL teprve ted postupne dohani.

[R]

A preco teda pridavaju nove diery?

[pava]

Zajimave, ze snad kazde druhe CVE bylo v LibreSSL uz davno opraveno nebo ta chyba je nove v OpenSSL.

[little.owl]

Zatim vetsina spolecnych CVE byla napred objevena v OpenSSL a teprve potom se zpozdenim opravena i v LibreSSL. LibreSSL prestalo CVE se zavaznosti low/moderate a nektere high pochazejici z OpenSSL vubec resit, takze se ani nevi jestli tam jsou ci ne. Pokud se rozhoupaji to uznat se zpozdenim jako problem, nazyvaji to zavadejicim zpusobem jinak. Prikladem je nedavne CVE-2016-8610: "SSL Death Alert", ktere bylo v OpenSSL opraveno 24.10.2016 (1.0.2j, 1.1.0b). V LibreSSL se to dozvedeli se tentyz den a opravili to az vcera 7.11.2016 jako "reliability change". Pak se prsati, ze nemaji CVE, nektere trubky jim to i zerou, a pritom treba v tomto pripade byli jejich uzivatele vystaveni teto verejne zname chybe ctrnact dni.

[Hans1024]

Opravy chyb umoznujicich DoS se v OpenBSD vzdy oznacuji jako reliability fix, aby se odlisily od chyb zneuzitelnych k ziskani dat nebo prevzeti kontroly. Nikdo se neprsati, ze nejsou zadne CVE, ale jich mene a pristup OpenSSL k vyvoji a udrzovani kodu trpi stale stejnymi problemy, kvuli kterym LibreSSL vzniknul. Zvyseny pocet lidi hledajicich bugy v OpenSSL je sice hezky, nicmene porad je to z velke casti adresovani dusledku misto pricin.

[little.owl]

Zvyseny pocet lidi hledajicich bugy v OpenSSL je sice hezky, nicmene porad je to z velke casti adresovani dusledku misto pricin.

A k tomu jste dosel jak?

[Hans1024]

Oni to proste resi typickym zpusobem "mame hodne bugu --> musime vic opravovat bugy" a bud ignoruji souvislost vyskytu bugu se stavem a komplexitou kodu, nebo ten stav z ruznych politickych duvodu nechteji zlepsit. Myslim, ze uz jsem tady o tom vedl dlouhou diskusi kvuli jejich neodstraneni SSLv2.

[chrono]

Prečo by mali odstraňovať SSLv2? Ak aplikácia nechce využívať SSLv2, tak to využívať predsa nemusí (a ak ho z nejakého dôvodu potrebuje, tak to použiť môže).

[little.owl]

Oni to proste resi typickym zpusobem "mame hodne bugu --> musime vic opravovat bugy" a bud ignoruji souvislost vyskytu bugu se stavem a komplexitou kodu, nebo ten stav z ruznych politickych duvodu nechteji zlepsit.

A k tomu jste dosel jak? Pohled do logu repositaru tomu nenasvedcuje, dela se postupny refaktoring existujiciho kodu. Prave ten smer, kdy vice spolecnych chyb je objeveno v OpenSSL spise ukazuje, ze to delaji dusledneji, cemuz samozrejme nahrava i vetsi uzivatelska zakladna.

Myslim, ze uz jsem tady o tom vedl dlouhou diskusi kvuli jejich neodstraneni SSLv2.

To neni otazka knihovny, ale programu co ji pouzivaji.

[Hans1024]

Jasne, kriticka zabezpecovaci knihovna podporujici zabezpecovaci protokol, ktery uz dlouho neni bezpecny, z toho urcite nebude zadny problem. V LibreSSL SSLv2 davno odstrelili, v OpenSSL se po DROWNu rozhodli, ze by teda v defaultu mohl byt vypnuty.

A vypada to ze o te zranitelnosti OpenSSL zminene ve zpravicce vedeli mesic a pul. Tolik k rychlym opravam.

[little.owl]

To jaky se pouzije protokol je zalezitost aplikace a jejich autoru, nikoliv knihovny a neni duvod takto omezovat zpetnou kompatibilitu. Zatimco LibreSSL pouziva pristup, kdy chyby prejmenuje zavadejicim zpusobem a neresi mesice ci vubec.

[Hans1024]

Kdyz to bylo defaultne povolene, tak to jednoznacne byl problem knihovny. Kdyz je to defaultne vypnute, tak je to dalsi neodstraneny balast, ktery ani neslouzi ucelu, ke kteremu se ta knihovna primarne pouziva. Shazovani vseho na autora aplikace je postoj, ktery nijak nevyresi vysledny problem. Autor knihovny ma moznost ovlivnit bezpecnost, a muze s ni zodpovedne nalozit.

[little.owl]

Kdyz je to defaultne vypnute, tak je to dalsi neodstraneny balast, ktery ani neslouzi ucelu, ke kteremu se ta knihovna primarne pouziva.

To je uplny nesmysl. Je naprosto bezne u vetsiny knihoven, ze nektera funkcionalita je volitelna. Nerozhoduje defaultni konfigurace, kterou lze snadno zmenit, ale to jestli je vyvojovym teamem funkcionalita aktivne podporovana - pokud neni a kod neni jiz udrzovan, pak by mela jit pryc, jinak neni duvod.

Shazovani vseho na autora aplikace je postoj, ktery nijak nevyresi vysledny problem. Autor knihovny ma moznost ovlivnit bezpecnost, a muze s ni zodpovedne nalozit.

V tom se neshodnem. To je takovy nabubrely patronismus ve smyslu "My vime co je pro vas dobre a tak to budete muset delat". Podle vaseho pristupu by melo smysl vyhazet se vsech knihoven treba MD5, protoze neposkytuje v soucasnosti v rade uziti dostatecne zabezpeceni - coz je fakt - ale presto si myslim, ze by to byl stejny kretenismus. Staci informovat o vyhodach a nevyhodach, a nechat uzivatele rozhodnout a postupne dojde k omezeni uziti v kritickych scenarich.

[Filip Jirsák]

MD5 ale v řadě situací poskytuje dostatečné zabezpečení. Což o SSLv2 neplatí, pro to není žádné bezpečné použití.

[little.owl]

Risk je nutne posuzovat v kontextu. Pokud se SSLv2 pouziva v zabezpecenem intranetu u par starsich aplikaci, prechod muze pockat a riziko nemusi byt velke. Pokud podporu v OpenSSL uplne odriznete, uzivatele zustanou s posledni verzi, ktera to podporuje, neudrzovanou, kdy je vysledna bezpecnostni situace mnohem horsi, ci sifrovani uplne vypnou. OpenSSL to dela IMHO dobre, ted dava uzivatelum cas premigrovat.

[Filip Jirsák]

Do toho kontextu ovšem patří i to, že pak máte v knihovně spoustu kódu, který se prakticky nepoužívá, může se rozbít s každou opravou, může opravy komplikovat a tím třeba způsobit, že oprava bude chybná, a může představovat i cestu pro napadení knihovny, i když daný uživatel danou funkcionalitu nepoužívá (pokud ji má zakompilovanou).

Pokud je pro někoho přijatelné riziko provozovat něco na SSLv2, je pro něj i přijatelné riziko provozovat to na staré verzi OpenSSL. Protože tam pořád platí, že tu komunikaci hackne každý, kdo se k ní dostane, a horší už to být nemůže.

[little.owl]

Do toho kontextu ovšem patří i to, že pak máte v knihovně spoustu kódu, který se prakticky nepoužívá, může se rozbít s každou opravou, může opravy komplikovat a tím třeba způsobit, že oprava bude chybná, a může představovat i cestu pro napadení knihovny, i když daný uživatel danou funkcionalitu nepoužívá (pokud ji má zakompilovanou).

To je otazka pro maintanery OpenSSL, pokud to chteji a jsou schopni udrzovat, a to ze mene kodu znamena mene pripadnych problemu je jiste znamo i jim. Uzivatel knihovny, tedy treba distribuce, to nemusi kompilovat a konecny uzivatel nastavovat.

Pokud je pro někoho přijatelné riziko provozovat něco na SSLv2, je pro něj i přijatelné riziko provozovat to na staré verzi OpenSSL.

To rozhodne nikoliv, zejmena u sdilene knihovny podporujici i jine protokoly, vyuzivane vice aplikacemi s ruznym nasazenim.

Protože tam pořád platí, že tu komunikaci hackne každý, kdo se k ní dostane, a horší už to být nemůže.

Ano, je to v soucasnosti slabe zabezpeceni, ale aplikace stale funguji. S tim "kazdy" bych byl opatrny.

[Filip Jirsák]

To rozhodne nikoliv, zejmena u sdilene knihovny podporujici i jine protokoly, vyuzivane vice aplikacemi s ruznym nasazenim.

V takovém případě má být nainstalováno více verzí knihovny a tu nebezpečnou má používat výhradně ta aplikace, která ji potřebuje. Pokud by tu nebezpečnou verzi knihovny sdílely i ostatní aplikace, je to přesně ten nejsilnější důvod, proč by podpora těch děravých protokolů měla být odstraněna. Protože vy odůvodníte nutnost podpory SSLv2 pro jednu aplikaci, u které to třeba nevadí, protože se používá jenom interně, ale vedle toho pak můžete provozovat jiné aplikace, třeba veřejně dostupné z internetu – a těm také dáte OpenSSL s podporou SSLv2. A rázem jste problém rozšířil z aplikace, u které na bezpečnosti nezáleží, na nějakou podstatnou aplikaci, která má být bezpečná. Úplně stačí taková prkotina, jako že ta aplikace nebude řešit, jaké protokoly jsou povolené, a povolí vše, co poskytuje OpenSSL.

To je tedy přesně ten důvod, proč by taková legacy aplikace měla být provozována v odděleném prostředí se speciální nebezpečnou verzí OpenSSL a správce by si měl být dobře vědom toho, že je to nezabezpečená aplikace a že k ní nic jiného nepatří.

[little.owl]

V takovém případě má být nainstalováno více verzí knihovny a tu nebezpečnou má používat výhradně ta aplikace, která ji potřebuje.

Pokud je knihovna a jeji kod udrzovan, neni nebezpecna, nebezpecna jsou aplikace, ktere ji pouzivaji neadekvatnim zpusobem.

Protože vy odůvodníte nutnost podpory SSLv2 pro jednu aplikaci, u které to třeba nevadí, protože se používá jenom interně, ale vedle toho pak můžete provozovat jiné aplikace, třeba veřejně dostupné z internetu – a těm také dáte OpenSSL s podporou SSLv2. A rázem jste problém rozšířil z aplikace, u které na bezpečnosti nezáleží, na nějakou podstatnou aplikaci, která má být bezpečná. Úplně stačí taková prkotina, jako že ta aplikace nebude řešit, jaké protokoly jsou povolené, a povolí vše, co poskytuje OpenSSL.

Tvrdil jsem, ze riziko je treba posuzovat v kontextu, udrzovani podpory starsich protokolu v knihovne ma smysl, zbytek je ilustrace, kterou lze rozebirat do nekonecna. Vase reseni, ktere take stale vyzaduje mit podporu v kodu OpenSSL, je fajn, i kdyz za lepsi cestu do budoucna povazuji restriktivni sandboxing vsech sluzeb, vcetne povolenych protokolu, s globalni konfiguraci, pod kontrolou administratora - tohle neni prvni ani posledni protokol, ktery je oslaben ci prolomen.

a správce by si měl být dobře vědom toho, že je to nezabezpečená aplikace a že k ní nic jiného nepatří.

Vetsina bezpecnostnich problemu je zpusobena neudrzovanymi servery a tam je nutne hledat reseni. Spravce nema zapnout podporu SSLv2 v konfiguraci aplikace, pouzit reseni jako stunnel a pokud musi podporovat starsi aplikace potrebujici SSLv2, je treba je povazovat za nezabezpecene se vsemi dusledky.

[Filip Jirsák]

Vase reseni, ktere take stale vyzaduje mit podporu v kodu OpenSSL

Ne, moje řešení znamená vyhodit z OpenSSL podporu SSLv2 a v aplikacích, které SSLv2 stále používají, používat starou verzi OpenSSL, která SSLv2 ještě má. Protože když aplikace používá SSLv2, je už jedno, že používá děravou knihovnu – protože ta komunikace musí stejně být zabezpečena ještě jinak.

Považuju za mnohem větší bezpečnostní riziko aktuální kód s podporou bezpečných protokolů, který je společný s kódem pro podporu SSLv2, než ty staré aplikace vyžadující SSLv2 provozovat se knihovnou se známými bezpečnostními chybami. O to víc v případě projektu OpenSSL, u kterého byla v historii snaha spíš podporovat kdejaké obskurní rozšíření než důraz na bezpečnost kódu. Prostě se bojím toho, že zachování podpory SSLv2 komplikuje kód takovým způsobem, že mohou být přehlíženy bezpečnostní chyby, nebo při opravách chyb a snahách zachovat kompatibilitu i se SSLv2 vznikají chyby nové.

[Hans1024]

Je naprosto bezne u vetsiny knihoven, ze nektera funkcionalita je volitelna. Nerozhoduje defaultni konfigurace, kterou lze snadno zmenit, ale to jestli je vyvojovym teamem funkcionalita aktivne podporovana - pokud neni a kod neni jiz udrzovan, pak by mela jit pryc, jinak neni duvod.

U takhle kriticke knihovny je bezpecna defaultni konfigurace naprosto zasadni - viz Heartbleed, POODLE, DROWN. A cilem by melo byt podporovat kritickou funkcionalitu a ne tunu balastu, ktera se pak negativne projevi na kodu.

V tom se neshodnem. To je takovy nabubrely patronismus ve smyslu "My vime co je pro vas dobre a tak to budete muset delat". Podle vaseho pristupu by melo smysl vyhazet se vsech knihoven treba MD5

Ja jsem pro moznost nastaveni zpusobu zabezpeceni, ale SSLv2 uz proste neni funkcni zpusob zabezpeceni komunikace. MD5 ma spoustu legitimnich pripadu pouziti. Jedinne pouziti pro SSLv2 vidim u zprovoznovani starych proprietarnich exkrementu - na to bych doporucil vytvorit knihovnu libhackshit, a nezadelavat kod OpenSSL.

[Conscript89]

Jasne, kriticka zabezpecovaci knihovna podporujici zabezpecovaci protokol, ktery uz dlouho neni bezpecny

Nevidim tu zadny konflikt s popisem projektu:

OpenSSL is an open source project that provides a robust, commercial-grade, and full-featured toolkit for the Transport Layer Security (TLS) and Secure Sockets Layer (SSL) protocols. It is also a general-purpose cryptography library.

[Hans1024]

My se bavime o tom, jak je ten vysledek bezpecny, a ne o tom, jestli se drzi proklamovanych cilu.