Heartbleed bug tesztelés

Hálózatok általános

Sziasztok!

Van két gépem, és azt szeretném megtudni, hogy vajon a bug érintette-e ezeket.

Az egyiken van OpenVPN, tehát ez érintett - ezt valahol olvastam.

A másikon csak levezés van.
Postfix, STARTTLS titkosítással smtp és submission porton
dovecot, imaps porton.

Google segítségével nem találtam olyan listát, ami egyes programok érintettségét mutatná (mint pl. azt, hogy az OpenVPN érintett). Bizonyára van ilyen lista, de nem akadtam rá.
Ha valaki tud egy URL-t, az segítene.

Illetve találtam tesztelő weblapokat, amik adott gép adott portját tesztelik.
Viszont amiket eddig próbáltam, nem tudnak SMTP-t beszélni.
Az imaps-ra kiírták, hogy nem érintett, de nem tudom, hogy a postfix STARTLS titkosítás esetén érintett-e.
Van valami teszt weblap/program erre?

  • 10231 megtekintés

( hrgy84 | 2014. 04. 14., h – 14:51 )

Csinalj egy SMTP/SSL portot is, celszeruen az smtps szolgaltatasnak megfelelo helyen (465). Ezt mar mindenki tudja tesztelni.

OpenVPN eseteben en kerdes nelkul cserelnem a tanusitvanyokat. Sosem art.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

( janoszen v | 2014. 04. 14., h – 14:50 )

Nezd meg az OpenSSL verziodat. Ha a Postfix alatt is a patchelt verzio fut, akkor tudtommal nem vagy sebezheto.

Pontosan igy tudod. Az smtps-t es az smtp/tls -t ugyanaz a szoftver biztositja, az egyetlen kulonbseg az, hogy smtp/tls eseen a handshake egy STARTTLS utan indul el, az smtps eseteben meg azonnal. Mivel ezek a szolgaltatasok nagyreszt az ssl handshake-t nezik csak meg, protokollokat nem nagyon beszelnek, igy a handshake tesztelesevel kb. tul is vagy a dolgon.

Pont azert ajanlom az smtps teszteleset, mert azt is a postfix biztositja, es te valojaban azt akarod tesztelni, hogy az SSL stacked korrekt-e, nem a konkret smtp/tls mukodeset.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

( Stageline | 2014. 04. 15., k – 08:54 )

Csak az OpenSSL 1.0.1 verzió bugzik és az ezzel készített certeket kell cserélni nem? de?

A bug lenyege, hogy a serulekeny verzioval futtatott szerverek (Apache, Exim, Postfix, Dovecot, stb) keresre kiszolgaljak a szerver memoriajanak egy 64 kb-os szeletet, amelyben adott esetben maga a titkositatlan kulcs is szerepelhet. Mivel ezt nem is lehet latni a logokban es tetszolegesen sokszor kerheto le 64 kb-os szelet, barki mindenfele jel nelkul ellophatta az SSL kulcsodat amivel csinalhat egy fake szervert a nevedben es ellophatja az osszes ugyfeladatot. Az egyetlen megoldas ha komolyan gondolod az SSL hasznalatat, hogy a javitod a serulekeny verziot a szervereden, kersz egy uj SSL certet es visszavonatod a regi certet a kibocsajtoval.

Ha mar a temanal vagy, ellenorizd le az SSL configodat egyeb hibakra is.

Bovebb, kozertheto magyarazatot a bug mukodeserol az XKCD-n talalsz.

őőőő...

hát de nem arról volt szó, hogy a memóriában bármi lehet, pl. usernév és jelszó, meg bankkártya adatok, meg ilyesmi.

Tehát az egy dolog, hogy az ember programot frissít és újraindít, de emellett bármi olyasmit, amit ellophattak, cserélni kell.

Vagyis ha egy gép felnyomható, akkor gyakorlatilag mindent, ami azonosításhoz használható és a gépen előfordul.

Ezért kérdeztem, mert az egy dolog, hogy az első gépen le kell cserélnem az OpenVPN összes kulcsát (szerver és kliens kulcsokat is), valamint az összes felhasználó (szám szerint 2: root és gee) jelszavát.

Viszont azt még nem tudtam eldönteni, hogy a második gép sérülékeny volt-e (nem volt időm tesztelni még). Ha igen, akkor ott az összes felhasználónak új jelszót kell generálni, plusz ha valakinek privát ssh kulcsa lenne (nem valószínű), akkor azt lecserélni és mindenhol letiltani az authorized_hosts-ban, ha valakinek a pgp kulcsának a titkos része ott van és használta (nem valószínű), akkor azt a kulcsot lecserélni és letiltani.
Plusz persze a levelezés által használt tanúsítványokat lecserélni.
Lehet, hogy más is van, nem gondoltam még végig, de nem állnék neki, ha a hiba nem volt kihasználható.

Végtére az én kommentem is neki szólt :-)

Csak azt akartam mondani (neki), hogy nem csak a tanúsítványok érintettek, valamint mindegy, hogy mivel hozta létre a tanúsítványait, ha a rendszeren hibás openssl lib volt, akkor a mással létrehozott cuccokat is el lehetett lopni.

Az ubuntu 12.04 emlékeim szerint libssl1.0.0 -el lett kiadva, ami viszont már a telepítéskor (ha be van pipálva hogy kell ssh szerver) készít automatikusan kulcsokat. Ezek alapján az összes frissítetlen 12.04 ubuntu veszélyben lehet. Az ssl kulcsok miatt különösen. Jól gondolom?

Nem úgy van ez, hogy bármi ellopható a memóriából?

Tehát ha ssh van a gépen nem tudom kihasználni a bugot, de ha van egy érintett szolgáltatás, pl. https, akkor akár az ssh kulcsot is megszerezhetem (ha szerencsém van és épp a memóriában van és épp azt a területet kértem el).

Igen, de amikor megkapja a memóriát a httpd a kerneltől, akkor úgy tudom, nem törlik gondosan ezt a területet, hanem ha előzőleg ez a lap az ssh kezében volt, és éppen oda töltötte be a privát kulcsodat, akkor az a httpd memóriaterületéről kiolvasható.

Szerintem mondjuk ez már olyan dolog, aminek biztosan nagyon kicsi az esélye, mivel egy csomó véletlennek kell pont a megfelelő sorrendben bekövetkeznie.

De nem nulla, és mivel biztonságról beszélünk, a jobb a békesség alapon én minden azonosítót lecserélnék az érintett gépemen.

Nem, erre nincs semmi esély. Az összes oprendszer úgy ad új memóriát egy processznek memória foglaláskor, hogy abban semmi nyom nincs arról, hogy azt a fizikai memória page-et korábban egy másik processz mire használta.

"Szemét" úgy olvasható ki a memóriából, hogy az aktuális processz tett oda foglalást, majd szabadította fel, de még az oprendszernek nem lett visszaadva az memóriaterület.

http://stackoverflow.com/questions/13281773/inter-process-real-memory-p…

Amikor a kernel új memória lapot ad a processznek, az mindig ki van nullázva. Egészen pontosan ez egy kernel fordításkori paraméter, embedded rendszerekben néha ki szokták kapcsolni performancia okok miatt, de a "normál" disztribúciók ezzel fordulnak. Amikor program felszabadít egy területet, majd újra lefoglal egyet, akkor az adott memória lap nem feltétlen ment vissza közben a kernelhez, ilyenkor lehet rajta saját maga által otthagyott szemét.

Jól van akkor, ezek szerint más processztől nem szivároghat át az adat. Ennek örülök.

Akkor a következő kérdés:
ha egy postfix egy másik processzt használ a jelszó ellenőrzéshez, de azért ugye ő maga adja tovább a jelszót, akkor az azért a postfix memóriájából esetleg kiszedhető? Gondolom igen.