NSA věděla o chybě Heartbleed v OpenSSL

NSA údajně věděla o závažné chybě Heartbleed v OpenSSL už od jejího zanesení do kódu a využívala ji k získávání hesel a dalších důvěrných informací. Ačkoliv má NSA primárně sloužit k obraně USA, dala raději přednost využití pro útok než ochraně vlastního obyvatelstva před špehováním jinými zeměmi.

11.4.2014 22:48 | Luboš Doležel (Doli) | Bezpečnostní upozornění

Komentáře

[Odin]

Je zajimave, ze nsa o tom vedela roky, ale opensource verejnost na to prisla az ted. Vzdycky se mi otevrenost kodu libila kvuli transparentnosti a potencialne rychle oprave chyb, ale nyni mi prijde, ze otevrenost zapusobila kontraproduktivne. Doufam, ze takovychto pripadu nebude vic a ze se budou bugy v opensource odhalovat efektivneji.

[SOS]

Doplnim a upresnim: Doufam, [..] ze se budou bugy [..] odhalovat [..] sami od sebe.

[MK2]

Kdyby to ale opensource nebyl, NSA by na to přišla stějně ale veřejnost by na to nepřišla nikdy. To že byl dostupný kód určitě NSA pomohlo, ale rozhodující pomoc to nebyla. Nemyslím totiž, že pro organizaci s takovými prostředky je closedsource nečím víc než jen mírně zdržující nepříjemností.

[jadd]

http://www.pepak.net/bezpecnost/open-source-a-backdoory/

[pavlix]

Nějak mi není jasné jak může být v tomto případě open source nevýhodu. V případě open source mají ke kódu přístup všichni, v případě closed source jen někteří. Dá se předpokládat, že NSA nemá nejmenší problém se mezi ty některé zařadit.

[Bill Gates]

Je to takove .. no .. urcite ma OSS vyhodu protoze je vic pod dohledem. Na druhou stranu kdyz se do OSS mohla dostat tahle chyba a nikdo si ji 2 roky v OSS nevsimnul, co brani NSA zaimplementovat jeste mazanejsi problem, ktery bude tak dumyslne skryt a patch bude tak dobre zduvodnen, ze komunita patch prijme (od kohokoliv kdo s NSA zdanlive nemusi mit nic spolecneho) a NSA treba diky panice ted protlacila na servery dalsi, jeste zakernejsi diru. je jasne, ze v OSS je takova dira odhalitelna za nejaky cas. V tomto pripade to byly tusim 2 roky? To je dost casu.. Minimalne na vyuzivani zanesene chyby a minimalne na ziskani casu na vyvoj sofistikovanejsi chyby diky pouceni se z minula, diky tomu jak se komunita zachovala, zkratka vyvoj.. evoluce.

[Bystroushaak]

Viz. NSA operation ORCHESTRA: Annual Status Report

[Bill Gates]

To je strasne dlouhe na muj vkus .. o co tam jde prosim .. ? Ve zkratce .. Diky .. Nebo se tam resi totez co jsem napsal ? :D

[Bystroushaak]

Je to přednáška, kde se autor poněkud paranoidně zaměřuje na situaci, kdy by on sám byl NSA s bilionovým rozpočtem a dostal za úkol co nejúčiněji se dostat kam to jen půjde, ale nesmí použít blackops (ala zabíjení a vydírání) a nesmí plýtvat penězi (protože je státní organizace a někdo na něj dohlíží). Jen dodám, že NSA má podobně velký rozpočet a přesně tenhle úkol.

Ta přednáška je výroční zpráva, kterou on jakožto (smyšlený samozřejmě) šéf NSA předává posluchačům a popisuje jim, za co konkrétně utrácí. Na základě pozorování dějů v okolním světě si vymyslel strategie, které by stály co nejméně peněz a přitom ovlivnily co nejvíc lidí a umožnily toho sledovat co nejvíc.

Je to velmi zajímavě, inteligentně a vtipně podané. Hodně se tam věnuje opensource a nemalá část je věnována právě openssl, do které tam kope jak se jen kopat dá a několikrát zmiňuje, že kdyby on byl NSA, tak se zaměří přesně na tohle, protože je v ní takový bordel, že si NSA nemůže nic víc přát.

Datum zveřejnění videa je 12. 2. 2014, což z něj dělá poměrně prorockou záležitost.

[Bystroushaak]

*bilionovým/miliardovým, samozřejmě v dolarech.

[Bill Gates]

Diky, jak bude cas, mrknu na to na cele ..

[pc2005]

Datum zveřejnění videa je 12. 2. 2014, což z něj dělá poměrně prorockou záležitost.

Ono je klidně možné, že se alespoň jeden z těch dvou nálezců tou přednáškou inspiroval a začal se ve zdrojácích OpenSSL šťourat.

[Bystroushaak]

Jo, to mě taky napadlo.

[D.A.Tiger]

co brani NSA zaimplementovat jeste mazanejsi problem, ktery bude tak dumyslne skryt a patch bude tak dobre zduvodnen, ze komunita patch prijme

Hmmm... podobnou otazku jsem kdysi kladl take - Jak moc duveryhodne jsou "duveryhodne" repositare? Co brani nekomu pridat se k vyvoji nejakeho projektu (distra, pluginy pro web brovser, atpd....) a pres balicky v repu jej kompromitovat? Je tak tezke udelat "oficialniho" trojskeho kone? Jasno v tom nemam doted, a nezbyva mi nez jen doufat, ze se o to nikdo nepokusil, nebo se to zatim nikomu nepovedlo....

[Luk]

Je to projekt od projektu jiné. Existují projekty, kam se nedostane nikdo (např. Postfix, který je dlouhodobě one man show). Některé mají dost striktní přístup (např. Linux, ale tam se to liší podle různých subsystémů), jiné volnější (většina projektů), u některých může přispívat v podstatě úplně každý (teď mě nenapadá vhodný příklad, ale i takové projekty jsou).

Každé má samozřejmě své. Když vezmu svůj projekt incron, tak tam jsem uplatňoval tu politiku, že veškeré změny dělám osobně. Sice mi lidé posílali různé patche, ale ty jsem nikdy neaplikoval mechanicky - vždycky jsem změnu provedl ručně, většinou mírně jinak, než co obsahoval patch (žádný patch nebyl příliš rozsáhlý, šlo spíše o formality typu inkludování nějakých hlaviček, aby to šlo zkompilovat na systému XY).

Samozřejmě, že do distribučních balíčků už mohlo jít něco jiného, než bylo v oficiálním repozitáři - čili v tomto místě se tam teoreticky mohlo něco dostat, i když předpokládám, že nedostalo (kdo by měl zájem, může to prověřit). Připomínám, že přesně takhle se kdysi dostala do Debianu ona "upravená" verze OpenSSL, která generovala klíče z velmi omezeného prostoru (v upstreamu problém nebyl).

[pakanek]

Soutěž v napsání nevinného kódu obsahujícího chybu: http://underhanded.xcott.com/

[Jirka]

Přístup mají všichni, ale přiznejte se, kolik z vás si ty kódy čte doma před spaním?

[w4rr10r]

Bílí klobouci se tím živí.

[kralyk z abclinuxu]

Červení taky

[Jendа]

Černí taky.

[Bedňa]

A žltí tiež, za misku s ryžou.

[jadd]

:)

[Bill Gates]

Hm .. a i pres to, ze se tim zivi, trvalo jim to dva roky. Navic po aktualizaci openssl se mi na notebooku rozesralo mysql a stahovani fotek z fotaku coz je pro me daleko zivotne dulezitejsi nez hack openssl za NATem, protoze si nejaky aktivni blb myslel ze nova konfigurace pro me bude lepsi. Dohajzlu uz i s aktualizacema. Dam cokoliv za jeden stabilni nemenici se system. Tenhle opensource ma desne nevyhody (samozrejme krome rady vyhod). Kdejaky kreten pridela kdejakou hovadinu aby projevil aktivitu a svuj studentsky um, a dopadne to tak, ze clovek pak musi davat kupu rozbitych veci dohromady. Nevim co je lepsi. Jestli nechat system tak a radeji stabilne fungovat s tim s cim fungovat potrebuji, nebo zaplatovat, downgradovat, prechazet na jiny SW, jak magor a pak tyden neresit nic z toho co potrebuji, protoze budu muset system davat do kupy. Jak u debilu toto, prominte, ale fakt me to nasralo. Nemam nic proti linuxu, mam ho moc rad, na widle me nikdo nedostane. Jak ale odrezat tuny dementnich po aktivite prahnoucich blbu, kteri se snazi do komunitniho software protlacit prave tu svou hnupinu? NSA nevyjimaje. To je jeden z techto aktivistu, tlacicich sve hnupiny za konkretnim cilem, ne za cilem byt "velkym programatorem" ale za cilem uplne jinym. Priznam se me je to jedno, kuwa ja potrebuju stahnout ty fotky a ne se ted tyden jebat s tim, co se zas rozbilo.

[Luk]

Dohajzlu uz i s aktualizacema. Dam cokoliv za jeden stabilni nemenici se system.

Žádný takový není. Každý systém, pokud nedělá jen něco naprosto triviálního (a ani u takového to neplatí 100%), obsahuje chyby a proto se musí aktualizovat.

Tenhle opensource ma desne nevyhody (samozrejme krome rady vyhod). Kdejaky kreten pridela kdejakou hovadinu aby projevil aktivitu a svuj studentsky um, a dopadne to tak, ze clovek pak musi davat kupu rozbitych veci dohromady.

To není problém open source, to je problém toho, kdo projekt spravuje. Když si tam nechá tyhle věci strčit, tak to podle toho vypadá. Stejná situace může nastat i u closed source, pokud si správce projektu nechá vnutit nějaké nesmysly, ať už vytvořené formou pluginu, nezávislého programu nebo třeba jen jako referenční implementace, kterou někdo zapracuje do hlavního kódu. Naopak open source může fungovat i stylem, že to spravuje jeden autor/tým/firma a nenechají si tam cpát cokoli zvenčí, drží si všechno pod vlastní kontrolou.

Jinak systém lze rozbít i úplně nezávisle. Například některé ovladače hardwaru mohou napáchat ve fungujícím systému děsnou paseku. Vzpomínám kupříkladu na jeden ovladač televizní karty, který dokázal naprosto parádně rozstřelit fungující Windows (XP SP2; před SP2 problém nebyl a všechno fungovalo!). Během instalace spadl systém do modré obrazovky - po restartu už nejelo prakticky nic a kromě přeinstalace systému nebyl způsob, jak to opravit. To jen jako poznámka na okraj.

[Bill Gates]

jj.. Jsem programator.. vse co pisete je mi jasne. Sam si obcas ve vlastnim projektu kusem kodu v dobre vire ze neco vylepsi, rozbiju neco uplne jineho jinde, co bych vubec necekal. Samotnemu se mi to nelibi, hledam reseni jak tomu predejit .. snad jen rozdelit projekt na vice na sobe nezavislych projektu a delat dukladne logovani chybovych stavu, ale kdyz dukladne, tak tim myslim opravdu viditelne (ne nekde kilometr daleko v logu zasite) kdyz uz neco prestane jet, tak at si to rekne presne co tomu chybi. Je to hrozne obtizne prijit na nejake funkcni reseni, ktere by nemelo sanci dojebkat neco nekde jinde. S dukladnym logovanim ale u svych projektu nalezam uspech. Vyplaci se to. Chyby se pak samozrejme snaze pacifikuji.

No a jeste kdyz si takhle klacky pod nohy nehazu sam a haze mi je i jiny aktivista z komunity .. to fakt pak nas*re :D Ten muj problem s fotakem asi bude resit restart NTB. to bude neco kolem dbus nebo tak neco .. nevim .. Uz se mi to jednou rozsypalo po aktualizaci .. Nejhorsi je ze to clovek musi resit v momente kdy to je absolutne nevhodne se tomu venovat a neni cas.

[kralyk z abclinuxu]

Dam cokoliv za jeden stabilni nemenici se system.

Tak to si budeš muset koupit psací stroj...

[Bill Gates]

vim, vim.. ovsem tohle taky neni reseni.. Ovsem jak tohle vyresit .. leda hledat a hledat az clovek najde opravdu stabilni system. Coz chapu, ze muze byt neresitelne ... :(

[pc2005]

Psací stroj má tunu race condition. Schválně zkus zmáčknout víc kláves najednou, nebo hodně rychle po sobě .

[pavlix]

Psací stroj má tunu race condition. Schválně zkus zmáčknout víc kláves najednou, nebo hodně rychle po sobě .

Zkus stisknout několik kláves současně na klávesnici počítače a zjistíš, že race condition jaksi zůstala.

[pc2005]

Wolfenstein 3D a "ILM" funguje skvěle. I když přiznávám, že mám nějakou supershitoidní klávesnici snad ještě do DIN5, u které jedna množina stisknutých kláves blokovala jakoukoliv jinou.

Na psacím stroji by současné zmáčnutí "ILM" způsobilo srážku těch kladívek s písmeny, což se pak občas musí ručně vrátit zpět.

[martin]

V principu na tom neni klavesnice o moc lip, tady je to pekne vysvetlene: http://www.microsoft.com/appliedsciences/antighostingexplained.mspx

[pc2005]

Přiznávám, že jsem mě ghosting nenapadl. Nicméně (je to i v tom článku od MS):

Řešení 0: Každé tlačítko samostatně (blésmrt, ale 105 kláves/IO není dneska problém).

Řešení 1: Diody (minimálně jedna moje klávesnice by s tím neměla problém - PCB ).

Řešení 2: Měření odporu. Propoje na folii mají nezanedbatelný odpor a tak rozdíl mezi 3 a 4 klávesami není problém detekovat nějakým ADC (má téměř každý PIC). Během standardního provozu je možno kalibrovat a adaptovat se tak na stárnutí té folie.

[pavlix]

Na psacím stroji by současné zmáčnutí "ILM" způsobilo srážku těch kladívek s písmeny, což se pak občas musí ručně vrátit zpět.

To lze interpretovat i tak, že psací stroj naopak race condition zabrání a předává kontrolu uživateli.

[pc2005]

No já se jako (malý dítě hrající si s babičinným psacím strojem) docela bál, že se tím poničí.

[pavlix]

My jsme v rodině pár psacích strojů měli a já jsem se nebál ničeho. A kupodivu jsem zničil spoustu jiných věcí ale psací stroj si nevybavuju.

[Luk]

Psací stroje musely vydržet i kruté jednoprsté bušení příslušníků VB, takže obavy o zničení dítětem nebyly moc na místě (většina součástí byla ocelových, žádný plast jako u dnešních počítačových klávesnice).

[Šangala]

Viděl jsi běžného příslušníka VB nebo stávající policie krutě bušit? - sepsání jednoho odstavce trvá minimálně dvě hodiny - takže kruté to moc nebude .

[Luk]

Krutost != rychlost

Tou "krutostí" jsem měl na mysli, že psací stroj trpěl pod těžkými, v roztodivných úhlech vedenými údery jediného prstu, do něhož směřovala veškerá hybnost rozpohybované paže.

[pc2005]

Nj, ale jednoprsté znamená, že nedojde ke kolizi (no leda, že by se nestrefil na jednu klávesu ). Každopádně u mého prvního postu:

modprobe nadsázka

[Luk]

no leda, že by se nestrefil na jednu klávesu

Nejlepší je trefit se mezi klávesy

[Jendа]

Hele, dostal jsem logáro. Píšou na něm:
✔ Arithmetic-oriented instruction set including integer, fixed and floating-point instructions
✔ Bignum and arbitrary-precision libraries available
✔ No hardware backdoors, fully transparent operation
✔ 100% EMP proof
✔ Solar powered, only little illumination necessary

[Petr Kos]

A nestačilo bu to instalovaní aktualizací vypnout?

[Jirka]

Aktualizovat jednou za čas ručně a vybírat co jo a co ne. Úplně bych to nevypínal.

[pavlix]

Přístup mají všichni, ale přiznejte se, kolik z vás si ty kódy čte doma před spaním?

V čem přesně tedy closed source pomůže?

[Filip Jirsák]

Mně na tom spíše připadá zajímavé, že NSA o tom věděla roky (přesněji více než dva roky), ale ta chyba se do kódu dostala teprve před dvěma roky a pár měsíci. Taky by mne zajímalo, zda o té chybě věděly ty roky i ty novinářské zdroje, a kámošům novinářům ani nikomu jinému to neřekli, protože se nikdo neptal. Nebo jestli se to dozvěděli až teď, po odhalení chyby - že si vedení NSA svolalo všechny zaměstnance, a sdělilo jim, že je to přísně tajné, nikomu to nesmí říct, ale NSA o té chybě věděla dávno.

[pc2005]

Třeba NSA poslalo interní memo, že musí přestat tuhle díru používat, protože teďka se bude každej snažit tenhle útok detekovat, což by je mohlo prozradit.

[vhor]

Ale jestli NSA o téhle chybě nevěděla, tak si teď musí rvát vlasy :)

[R]

Vo Windows sa podobne "chyby" robia priamo na objednavku NSA a kedze je kod zatvoreny, nedozvie sa o tom nikto.

[Kovář David]

A pak taky ještě způsobila pád meteoritu v Čeljabinsku... Celou dobu to drží pod pokličkou a náááhodou to praskne 5 dní po objevení chyby. Děsná náhoda. Spíš bych to tipoval na snahu Jasona Healey se zviditelnit a není nic lepšího, než obvinit NSA. Pokud se bude bránit, nikdo jí stejně neuvěří a otisknou to 100% všichni. Pravděpodobnost pravdivosti této zprávy není IMHO ani 50%

[Lol Phirae]

Pravděpodobnost pravdivosti této zprávy není IMHO ani 50%

Ještě jsi zapomněl na obligátní "Kdo nemá co skrývat, tak se nemá čeho bát."

[tany]

Ale upřímně na to něco bude ...

[mikirc]

Na tom sice něco je, ale koho by se taková NSA mohla bát? A že toho skrývá určitě požehnaně.

[MadCatX]

Tuhle story o vševědoucí NSA taky moc nežeru. Navíc to zatím vypadá, že vylámat tímto způsobem soukromé klíče je přinejmenším obtížné (viz analyza CloudFlare), takže k masovému louskání HTTPS by nejspíš nedocházelo ani tak.

[Jendа]

Celou dobu to drží pod pokličkou a náááhodou to praskne 5 dní po objevení chyby.

Samozřejmě. Po objevení chyby je totiž najednou jasné, co mám v záznamech ze svého honeypotu hledat - předtím to byly jenom nějaké divné nevalidní TLS pakety, teď už vím, co to znamená.

[marbu]

Přesně.

search for heartbleed in pcap file

searching for heartbleed in secat logs (i když tohle je spíš false positive)

[M]

+1

[Satan]

Two people familiar with the matter said

Někdo z osud.cz, předpokládám?

[Ivorne]

Teď mě napadlo: nemělo by být možné detekovat takový útok valgrindem? Jako je jasný, že by člověka muselo napadnout to testnout na 'správných' datech.

Vlastně všechna taková podobná přetečení by měla být detekovatelná valgrindem, ne? Takže si říkám, jestli by nebylo rozumné kritické aplikace pouštět na nějaké obdobě valgrindu, která by tohle detekovala.

[Jardík]

Jak psali někde u OpenBSD, OpenSSL má nějaký vlastní alokátor. Takže valgrind by asi nepomohl.

[asdfsdfasdfff]

Valgrind umoznuje pomerne jednoduche napojenie na iny alokator. Su tam na to client requests - pre viac info Valgrind docs alebo zdrojaky.

[kralyk z abclinuxu]

Jak psali někde u OpenBSD, OpenSSL má nějaký vlastní alokátor.

To zas někdo trpěl NIH syndromem, ne? Nebo má opravdu OpenSSL nějaké speciální nároky na alokaci paměti?

[pc2005]

OpenSSL nějaké speciální nároky na alokaci paměti?

Osobně bych třeba ukládal klíče do oddelené paměti a po free() bych je přepsal nulama. Je ale otázka zda to OpenSSL opravdu dělá .

[Jendа]

Na to ale snad nepotřebuješ vlastní alokátor.

[pc2005]

Hmm tak to nevím, ale vyběr pole z paměti OS, u kterého je zaručeno, že bude uprostřed ničeho a/nebo buffer overrun od ostatních oblastí způsobí segfault nebo pouze přeteče někam jinam ... mě v 5:24 ráno připadá klidně na nutnost spolupráce s kernelem.

Na druhou stranu je otázka, které ty paměťové struktury by bylo potřeba oddělit, nejspíš všechny :-/.

BTW Co jsem se v rychlosti koukal, tak v OPENSSL_malloc (po několika aliasech openssl-1.0.1g/crypto/crypto.h) nic speciálního není, jen wrapper okolo debug mallocu a systémovýho mallocu nahraditelnýho něčím uživatelským.

[pavlix]

Na tohle by se mi líbily forkující servery či servery aktivované přes inetd/systemd, kde violation povede k okamžité havárii procesu za vygenerování core dumpu.

[pavlix]

Plus samozřejmě mým ideálel by bylo, aby proces, který drží klíče nebo hesla, poskytoval jen lokální API pro přístup ke klíčům a nic jiného.

[Filip Jirsák]

Ještě lepší by bylo, kdyby neposkytoval API pro přístup ke klíčům, ale jen pro použití klíče - šifrování a dešifrování. Když se požaduje vyšší bezpečnost, dělá se tohle přece mimo počítač, na čipové kartě nebo v HSM. Navíc OpenSSL s těmito externími nástroji pracovat umí, takže by stačilo tu softwarovou část vydělit za stejné rozhraní a uživatel by si vybral, zda chce použít čipovou kartu, HSM nebo "softwarový HSM" v jiném procesu.

[pavlix]

Ještě lepší by bylo, kdyby neposkytoval API pro přístup ke klíčům, ale jen pro použití klíče

To jsme se špatně pochopili. Tím API pro přístup nebylo myšleno konkrétně API pro získávání celých klíčů, ale obecně APi pro práci s těmi klíči dle konkrétních možností a potřeb. SoftHSM je jeden z konkrétních projektů, které můžou s tímto pomoci a který při troše snahy může znamenat, že aplikace půjde používat i s pravým HSM.

[Martin Mareš]

Nevím, jak to dělá OpenSSL, ale bývá dobrým zvykem tajné klíče nejen přepisovat nulami, ale také paměť, ve které bydlí, mlock()-nout, aby se nevyswapovala na disk. A to už se s malloc()-em dělá těžko.

[Šangala]

I kdyby, ale tady nejde (jen) o paměť alokovanou pro klíče.

[kralyk z abclinuxu]

OpenSSL nějaké speciální nároky na alokaci paměti?

Osobně bych třeba ukládal klíče do oddelené paměti a po free() bych je přepsal nulama. Je ale otázka zda to OpenSSL opravdu dělá .

To máš pravdu, něco takového například dělá Botan a teď koukám, že v OpenSSL na to mají buffer, ale myslimže ten jejich alloc/free s tímhle nesouvisí...

[rastos]

a po free() bych je přepsal nulama.

M_PERTURB

Donedávna som o tom tiež netušil. A hanbím sa za to.

[pc2005]

Thx za info.

[kralyk z abclinuxu]

Zajímavé, ale je to pouze v glibc, ne?

[Šangala]

Si myslím, že by na to stačil valgrind, ale asi by to jen tak neodhalil, při to útoku ano, ale jinak asi ne (tak moc jsme to nezkoumal).

Nejedná se o vlastní alokátor, podle mmého zběžného zkoumání, jen je to obalené pro debugování, ani jakékoliv přepisování paměti to nezařizuje (což samozřejmě může dělat patřičná fce předem na správném místě).

OPENSSL_malloc −> 
  CRYPTO_malloc −> 
    malloc_ex_func −> 
      default_malloc_ex −> 
        malloc_func −> malloc

(OPENSSL_malloc_locked jde v stejném_locked řetězci.)

include/openssl/crypto.h

#define OPENSSL_malloc(num) CRYPTO_malloc((int)num,__FILE__,__LINE__)

crypto/mem.c

void *CRYPTO_malloc(int num, const char *file, int line){
...
  ret = malloc_locked_ex_func(num,file,line);
...
  retun ret;
}

/*a jsme u malloc*/
static void *(*malloc_func)(size_t)         = malloc;
static void *default_malloc_ex(size_t num, const char *file, int line)
  { return malloc_func(num); }
static void *(*malloc_ex_func)(size_t, const char *file, int line)

---- Dále

include/openssl/crypto.h:

#define CRYPTO_malloc_init()  CRYPTO_set_mem_functions(\
  malloc, realloc, free)

include/openssl/crypto.h
int CRYPTO_set_mem_functions(void *(*m)(size_t), void *(*r)(void *, size_t),void (*f)(void *)){
...
  malloc_func=m; malloc_ex_func=default_malloc_ex;
  realloc_func=r; realloc_ex_func=default_realloc_ex;
  free_func=f;
....

takže pokud se to někde specificky nepřestavovalo (je tam něco jako IMPLEMENT_DYNAMIC_BIND_FN co se tam někde používá a to používá CRYPTO_set_mem_functions, ale jestli jsem to pochopil, tak jsou to zas jen další obálky v případě free dělají další opičárny navíc - snad čistění paměti), opírá se to o std fce, tedy valgrind to zjistí…

[Jardík]

No oni tam psali něco v tom smyslu, že to do systému nevrací paměť (jejich free by to normálně snad unmapnul či tak nějak jsem to pochopil), ale oni ty bloky cachují tím jejich alokátorem a nevrací je zpět.

What Ted is saying may sound like a joke...

So years ago we added exploit mitigations counter measures to libc malloc and mmap, so that a variety of bugs can be exposed. Such memory accesses will cause an immediate crash, or even a core dump, then the bug can be analyed, and fixed forever.

Some other debugging toolkits get them too. To a large extent these come with almost no performance cost.

But around that time OpenSSL adds a wrapper around malloc & free so that the library will cache memory on it's own, and not free it to the protective malloc.

You can find the comment in their sources ...

#ifndef OPENSSL_NO_BUF_FREELISTS /* On some platforms, malloc() performance is bad enough that you can't just

OH, because SOME platforms have slow performance, it means even if you build protective technology into malloc() and free(), it will be ineffective. On ALL PLATFORMS, because that option is the default, and Ted's tests show you can't turn it off because they haven't tested without it in ages.

So then a bug shows up which leaks the content of memory mishandled by that layer. If the memoory had been properly returned via free, it would likely have been handed to munmap, and triggered a daemon crash instead of leaking your keys.

(zdroj)

[deda.jabko]

oni ty bloky cachují tím jejich alokátorem a nevrací je zpět.

To je divne, ze si to resi posvem, protoze takto se defaultne chova vetsina alokatoru.

[kralyk z abclinuxu]

Zdroj je tady. Někdo to zřejmě následně přeposlal do diskuse openssl, kde mu na to napsali, že:

We've been compiling -DOPENSSL_NO_BUF_FREELISTS forever.  Our only complaint is that the BUF is
misspelled :)

Theo can be obnoxious.  This should not be news to most folks.

	/r$

[kralyk z abclinuxu]

Takže beru zpět to o tom NIH syndromu, zřejmě jsou ty jejich alloc/free pouze wrapper, jestli to správně chápu...

[Šangala]

Hm musím, vzít své prohlášení zpět, protože jsem šel jen jedním směrem, v kódu je roj variací na SSL_CTX_new které používá OPENSSL_malloc, a v SSL_CTX_free se (bohužel až na úplném konci) paměť uvolní pomocí OPENSSL_free, nicméně nechce se mi v tom babrat bo těch fcí tohoto typu je tam roj, tam se ztratí i NSAServer - v tomto ohledu se mi kód vůbec nelíbí, by to chtělo vysekat a udělat OpenSSLLite :).

[Filip Jirsák]

Já to chápu tak, že ti lidé z Codenomiconu na to přišli právě při rozvoji nějakého jejich nástroje pro automatické testování. I když ten pravděpodobně nefunguje na straně serveru, ale spíš jako klient posílá serveru nejrůznější data a zjišťuje, jak se s tím server srovná.

Každopádně ale knihovna jako OpenSSL by podle mne měla být na buffer overflow testována už na úrovni automatické analýzy zdrojového kódu. Valgrind bych bral až jako druhý stupeň kontroly.

[Petr Tomášek]

Probůh, to jsou zase ideologické žvásty.

Nějaký šašek se přihlásí do novin a abclinuxu hned vyblije bulvární titulek „NSA věděla.“ Že to NSA samozřejmě nikoho nezajímá...

Jasně, vždycky za všechno může NSA nebo CIA...

[AlYoSHA]

Z uvedenj spravy vypliva ze NSA prd zalezi na bezbecnosti. Ta organizacia je sposobom fungovania skor zlocinecka ako bezpecnostna. Mali by zazalovat svoju skratku za zavadzanie.

[Petr Tomášek]

Z uvedene zpravy vyplyva, ze (1) existuji lide, kteri tvrdi, ze NSA o chybe predem vedela a (2) ze NSA to popira. Nic vic z toho nevyplyva...

[AlYoSHA]

Cakas snad ze to priznaju ? Konspiracnym teoriam ze sa o tu chybu nejak "postarali" neverim. Ze ju vyuzivali uz uveritelne je. Vzhladom na rozsah cinnosti ktore vysli na povrch v suvislosi z unikom informacii z NSA by ma to tak velmi neprekvapilo. NSA ma pomerne dost zamestnancov takze tam budu aj experti na analyzu rozneho sifrovacieho software. Chybu proste odhalili ale neinformovali o nej a vyuzivali vo svoj prospech. Resp. "v prospech ludu".

[Petr Tomášek]

To jsou prachsprosté spekulace. Stejně tak dobře mohli o chybě vědět ruské a čísnské tajné služby, nebo třeba zelení mužíčci...

[Šangala]

Potencionálně mohl vědět kdokoliv - to je to důležité - basta.

Obvykle se tímto směrem nevyjadřuji, ale ve světle některých vyjádření či akcí: „druhá věta není rozhodně nezaujatá a faktická“.

[Jerry]

Pokud jsou v NSA tak sikovni a chybu objevili a nakonec to jeste udrzeli v tajnosti tak asi to co delaj, delaj dobre :) Spis si ale myslim, ze nekdo pustil informaci, aby se zviditelnil, tak jak to tu pise nekdo vyse. Co jsem videl nejake seznmy postizenych webu, tak banky u nas jedou zrejme na Windowsech, nebot jsem tam tu chybu nezahlid, a nejaky freemaily snad nikoho nerozhazej. Takze za mne mnoho povyku pro nic, alespon ma o cem bulvar psat a strasit. Byt laik tak jsem z tech bulvarnich zprav celkem vyplasenej :)

[Luk]

banky u nas jedou zrejme na Windowsech

Banky obvykle nejedou na Windowsech (myslím skutečné systémy včetně internetbankingu; něco jiného jsou informativní weby, které mohou jet na čemkoliv - např. ČSOB jede na Widlích .NET, KB má něco javového, FIO má Apache asi na Linuxu...).

Asi nejrozšířenější platformou, aspoň u nás, je AS/400 se systémem OS/400 (ve znění těch desetkrát přejmenovaných nových verzí, jako iSeries, Power atd.), software je v RPG (čím dál méně) a v Javě. Nic microsoftího bych tam moc neočekával a OpenSSL taky asi ne.

[Jerry]

Mel jsem na mysli samozrejme internebanking, za Ty Wokna jsem si rikal, ze se mi zrejme nekdo vysmeje nebo pouci, takze diky za info :)

[Lol Phirae]

OpenSSL taky asi ne.

A fakt myslíš, že tam před tím nemají nějakou load-balancing proxy?

[Luk]

To mohou mít, ale na věci to nic nemění (protože load-balancing proxy není jen nginx, lighttpd apod.).

[nicco]

mBank IB bezi na Woknech

[daemon]

AS/400 se ještě používá? To jsem netušil. Někdy kolem r. 1995 jsem ten systém potkal v obchodním domě Tusculum. Byla to středně velká bedna, ke které všichni přistupovali s náležitým respektem.

[Luk]

Ono se to už dávno nejmenuje AS/400 (proběhlo postupně několik přejmenování - iSeries, System i, POWER... - a nadělal se v tom šílený guláš, už jsem v tom dávno ztratil přehled), ale platforma pořád pokračuje a v podstatě lze používat i programy, které vznikly na samém začátku (nejsou binárně kompatibilní, ale jsou nástroje na převod). Už řadu let pravidelně přednáším na konferencích Common (sdružení uživatelů technologií IBM) a tam bývají lidé z bank a různých velkých firem. Sice postupně "čtyřstovky" ubývají, ale pořád jich je v ČR a SR více než dost, hlavně právě v bankách.

[daemon]

To je zajímavé. Zaznamenal jsem v minulosti, že to u IBM různě přejmenovávali, ale netušil jsem, že je u nás ten systém stále tak rozšířený. Vím o HP Himalaya tak jsem měl pocit, že třeba banky jedou na tom.

[jadd]

nebude se teď víc prosazovat gnutls před nebo je něco kde openssl nemůže nahradit?

[Luk]

Ve GnuTLS byla také nedávno nalezena nepříjemná chyba.

Bohužel neznám podrobnosti ohledně toho, co teď která knihovna umí/neumí. Před časem ale bylo výhodnější používat GnuTLS, protože tam byla podpora SNI a hlavně novějších verzí TLS než 1.0, která trpí problémy "by design" (tj. přímo v protokolu, nezávisle na implementaci). Myslím, že i teď toho GnuTLS umí víc než OpenSSL, ale je to jen moje domněnka a nebudu trávit čas tím, abych si ji ověřoval.

Další aspekty jsou licenční. OpenSSL má zvláštní licenci, která není kompatibilní s GPL. V GPL je sice zvláštní výjimka, která zřejmě umožňuje linkovat knihovny jako OpenSSL, ale situace není úplně jasná. U jiných licencí to může být ještě složitější. Naproti tomu GnuTLS má licenci LGPL, což znamená v podstatě bezproblémové linkování v programu pod jakoukoli licencí.

Když to shrnu: nic není ideální, ale tady se přikláním spíše na stranu GnuTLS (používám s Apachem už několik let a po funkční stránce je úplně v pohodě - určitou nevýhodou je slabší dokumentace pro příslušný modul do Apache).

[jadd]

Díky oboum za vysvětlení, přes vaše odkazy jsem se dostal na lwn.net a wikipedii

[Luk]

Díky za ty odkazy. Vidím, že moje domněnka byla správná - zajímavá u GnuTLS je hlavně podpora DANE, která má sice zatím malý praktický význam, ale brzy už tomu může být jinak.

[Hans1024]

pred mesicem

myslim, ze je to tak nastejno

[Martin Čížek]

Mně by spíš zajímalo víc rozborů na téma "v jaké míře mohla asi být chyba využita".

Zde je rozbor alokací paměti: http://blog.existentialize.com/diagnosis-of-the-openssl-heartbleed-bug.html

Ano, každý je potenciálně vážně ohrožen, ale na druhou stranu masové zneužití podle mne není zase tak pravděpodobné.

Možnosti útoku:

1. zajímá mne jeden server a chci z něj něco citlivého dostat
2. zajímá mne nějaký citlivý typ informace a tu zkusím získat napříč Internetem

Že by dlouhodobě docházelo v masové míře k prvnímu typu útoku, mi nepřipadá pravděpodobné. Vyžaduje to zřejmě sofistikovanější postupy typu paralelní posílání vhodných požadavků (nejen SSL, ale i plných HTTP), aby se do postižené paměti dostalo něco vhodného. Toto by nějaké IDS už mohly hlásit (byť ně přímo jako tuto chybu).

Druhý typ útoku je asi pravděpodobnější. Útočník by pravděpodobně mohl najít nějaké obecně rozpoznatelné datové struktury, včetně soukromých klíčů serverů (openssl na klientech teď neřeším). Na druhou stranu, vlastnictví soukromého klíče serveru znamená, že si snadněji rozjedu podvrženou službu, ale pořád ještě musím ovlivnit DNS apod. Pokud byly v paměťovém prostoru nějaké "běžné aplikace", útočníci by třeba něco našly i tam. Na druhou stranu, pochybuju, že by někdo třeba masově vykradl čísla kreditek a dosud je masově nezneužil . Co by třeba ale asi získat šlo, je vylepšený slovník hesel používaných napříč internetem - zhruba na té úrovni vidím možné zneužití...

Mimochodem, jaká vlastně může být pravděpodobnost segfaultů při masivním zneužití? Segfaulty by značně zvýšily riziko odhalení chyby během zneužívání.

[Bystroushaak]

Své zkušenosti jsem shrnul v diskuzi vedle.

Možnosti útoku

Co jsem já viděl, tak docházelo k možnosti číslo 3 - natěžím ze všeho co půjde a pak to budu někdy v budoucnu analyzovat a třeba na něco kápnu. Někdo si vybíral servery zadáním inurl:https do google a sjížděním všech stále nepatchnutých, někteří vzali seznam českých domén, nmapem si je vyfiltrovali a pak těžili co se kde dalo (a pořád ještě dá).

[Luk]

Mimochodem:

Kdo získá přístup k počítačovému systému nebo k nosiči informací a
a) neoprávněně užije data uložená v počítačovém systému nebo na nosiči informací,
...
bude potrestán odnětím svobody až na dvě léta, zákazem činnosti nebo propadnutím věci nebo jiné majetkové hodnoty.

Pak jsou tam ještě vyšší sazby (hlavně s rostoucí škodou nebo prospěchem), až do 8 let. Samozřejmě, kde není žalobce, není soudce. Ale to jen jako upozornění pro ty, kdo by to chtěli zkoušet. Někdo by mohl nalíčit honeypot a pár blbečků by se určitě chytilo.

[Bystroushaak]

Pak jsou tam ještě vyšší sazby (hlavně s rostoucí škodou nebo prospěchem), až do 8 let. Samozřejmě, kde není žalobce, není soudce. Ale to jen jako upozornění pro ty, kdo by to chtěli zkoušet. Někdo by mohl nalíčit honeypot a pár blbečků by se určitě chytilo.

Já mám svědomí čisté, zkoušel jsem to jen z výzkumných důvodů, abych si udělal představu, jak na tom jsem (tzn žádný mass dump a jeho analýza, kromě vlastních strojů). Na druhou stranu jsem na pár IRC kanálech, kde nikoho nezajímalo jak to funguje, hlavně že to funguje. Což je to, co mě na celé té chybě upřimně děsí, ta triviálnost použití.

[Martin Čížek]

To je relevantní poznámka, díky; tzn. možnost dva podstatně rozšířená díky té zpětné analýze... takže hlavně nepanikařit a rychle vyměnit všechna hesla, co prošla postiženým paměťovým prostorem.

[PanZvedavy]

Ted je otazkou kolik je v openssl dalsich der o kterych zatim nikdo nevi.

Nahodne?!? objeveni bugu na verejnosti taky muze mit i jine pozadi...jako napriklad, ze cinani nebo rusove(nebo nekdo dalsi)ho take objevili a zacali ve vetsim pouzivat.
Takze to muze byt strategicky ustup o maly krucek...vsak za ty roky a investovane penize uz maji urcite nekolik dalsich "heartbugu" nejen v openssl.

Co je na celem tomto cirkusu ovsem nejzajimavejsi je fakt, že tak dulezity kus sw, ktery je vepchan vsude mozne, neni pod vetsim dohledem zainteresovanych stran, coz se ted asi zmeni. Skoro to vypada, jako by pomyslna vetsina usnula na vavrinech a predpokladala, ze kdyz je to opensource, tak si kod urcite prohlidla spousta lidi co tomu rozumi a urcite to bude v poradku a bezpecne.

Ted uz jen cekam, kdy se objevi dalsi stavnata chutovka...co treba ten znamy bezpecnostni projekt NSA... SElinux, ktery je v zakladu distribuovan v nemalo stezejnich distribucich jako je redhat. Kolik lidi vlastne skutecne rozumi tomu slozitemu kodu, kterym SElinux je? Mala chybicka na par radcich tuhle, nejaky bug tamhle a ejhle...samy tvurci na mailing listu priznavaji, ze nejmenovana drobna chybicka mohla zpusobit vaznej bezpecnostni problem.

Nekteri linux ultras se smeji windowsakum, ze kolik zadnich vratek tam MS udelalo pro zvedavce ze zpravodajskych sluzeb. A ted jim na jejich PC bezi linuxove jadro prospikovane kodem od NSA.
Urcite jsem jen zbytecne paranoidni, protoze zijeme v krasnem, svobodnem svete, kde se vsichni miluji navzajem.

ps: podle zakonu usa senatu, musi vsechny sw firmy vytvarejici sw na pude usa, poskytnout tamejsim sluzbam pristup, vytvorenim zadnich vratek, do vlastniho sw. Ptal se nekdo redhatu a dalsich firem sidlicich v usa jestli uz byli pozadani o vytvoreni techto der?

[Luk]

SELinuxu je dobré se vyhýbat, jak to jen jde. I kdyby tam nic nebylo, tak je to ohromně složitý krám.

Jinak už jsem četl hlasy volající po tom, aby tvorba a "dovoz" bezpečnostního softwaru (jakéhokoliv, nejen typu OpenSSL) podléhaly státní regulaci. Tohle je věc, která je ještě děsivější než to všechno ostatní. Nemoci si zabezpečit komunikaci a data jinou než státem požehnanou technologií je cesta do pekel. (Něco podobného ostatně měla - nebo možná ještě má? - Jižní Korea, kde kvůli tomu panovala monokultura Internet Exploreru.)

[rbc]

Systemd je oproti dosavadnimu initu taky slozity kram, kam se da schovat ledacos. Proces s pid 1, rootovska privilegia, mraky komponent, Redhat, NSA, one ring to rule them all. To bude jeste svanda.

[xxx]

Tak ja chapu, ze blogy jsou uz nejakou dobu pod nadvladou anti USA jadra. Ale ze agitka pronikla uz i do zpravicek mne prekvapuje. Takze jake dalsi zpravy od "dvou lidi srozumnenych s pripadem" se jeste dozvime?

[pavlix]

Tak ja chapu, ze blogy jsou uz nejakou dobu pod nadvladou anti USA jadra.

Co si pod tím máme my nezúčastnění představit?

[marek_hb]

a fakt si někdo myslí, že by tohoto nevyužila JAKÁKOLI jiná agentura?

to jsou místní antiami tak zaslepení?

[pavlix]

Opravdu je tak těžké si za NSA tu libovolnou jinou agenturu dosadit, zvláště pak v diskuzi pod zprávou agentury JPP?

[marek_hb]

a je opravdu tak těžké použít trochu hlavu místo neustálého démonizování USA/NSA? - já netvrdím, že jsou svatí a už vůbec si o nich nedělám iluze, ale takhle si zjednodušovat svět ....

[pavlix]

To asi nebude otázka na mě.

[kralyk z abclinuxu]

a fakt si někdo myslí, že by tohoto nevyužila JAKÁKOLI jiná agentura?

To máš asi pravdu, tu chybu je tak jednoduché zneužít, že by toho byla schopna i ta naše BSE nebo jak se jmenuje...

[Jose]

Využila by toha samozřejmně jakákoliv agentura i toho největšího banánistánu, nicméně takovouhle chybu si zařídit by už jakákoliv agentura nedala.

[nouri]

Když to věděli, tak proč nenahlásili chybu?

[Petr Tomášek]

To praveze vubec neni jisty, ze to vedeli.

[jdsulin2]

Je docela jednoduche zjistit, kdo te chyby vyuzival ne ? Proste si projdu vypis packetu (a ze jich musi byt hodne, pro nejake rozumne scanovani) a musi mi byt hned jasne odkud vitr vane. Nejspis proto se k tomu NSA tak ochotne priznala. Druha vec je fakt, ze to asi chlapci moc nepouzili, zjisteni udaju je v tomto konkretnim pripade tezce automatizovatelne a pozaduje docela aktivni pristup (jasne v kazdem zachyceni SSL komunikace to muzu zkusit, ale sance, ze trefim klic na jeji rozkodovani je v podsate 0%). Myslim, ze k tomu maji v OpenSSL mnohem lepsi backdoory o kterych nevime.

[Conscript89]

priznala?