[HWSW]

A sérülékeny OpenSSL nem csak webes szolgáltatásokban található meg, hanem egy sor hálózati eszközben és az Androidban is. A Cisco már közzétette és folyamatosan frissíti sérülékeny termékei listáját. Az Androidnak a Google szerint csak a 4.1.1 verziója érintett.
https://www.hwsw.hu/hirek/52125/openssl-heartbleed-sebezhetoseg-cisco-juniper-android-biztosag.html

[Emvy]

Erdekes egyebkent, hogy a (klasszikus ertelemben vett) hacker kozossegek elkezdtek elegge gondolkozni azon, hogy tenyleg C-t kell-e hasznalni ezekben a kritikus rendszerekben. A biztonsagi hibak tulnyomo tobbsege* buffer overrun jellegu, ahogy ez is, sok nyelvben ezt lenyegeben lehetetlen megcsinalni.

Az OpenSSL, mint kod szinvonala meg egeszen elkepeszto, erdemes belenezni. A visszateresi ertekeknel hol az 1 jelenti az igent, hol a 0. A "sebesseg" miatt irtak maguknak egy primitiv allokatort a malloc fole, amit ha nem tettek volna meg, akkor jo esellyel ez a hiba se lett volna (csomo esetben segfaultolt volna a tamadas). Satobbi. Remes az egesz.

*nem tudomanyos erteku becsles

[hanischz]

@Emvy: Sztem az egyik legfobb problema hogy sok az oroklott "kokori modszerekkel keszult" kod es senki nem akarja atirni oket. Ha mar c++ hasznalnanak smart pointerekkel, referenicakkal (pointerek helyett), modern stl kontenerekkel mar jobb lenne a helyzet.

Viszont menedzselt nyelv hasznalata sem megoldas mert ha jol emlekszem java is elegge lukas..pont mert c alapra epitkezik

[Emvy]

@hanischz: nem egeszen, mert az egyik esetben te magadnak kell biztositani a dolgokat, a masik esetben pedig siman nem lehetseges. Java-ban nem tudsz veletlenul olyan szituaciot eloallitani, amikor a valahonnan erkezo adat veletlenul atkerulhet egy masik adatstrukturaba.

Persze lehet ilyet csinalni, ha tenyleg nagyon el akarod cseszni (pl. foglalsz egy X meretu tombot, irsz egy allokatort ami azt hasznalja a JVM heap helyett), de Java*-ban ehhez erolkodni kell, nagyon.

*Java helyett mondhatnek rengeteg mast is, nem kell annal leragadni, hogy akkor most a Java jo vagy rossz.

[hanischz]

@Emvy: Ugy ertettem hogy a java framework is onmagaban eleg jukas mert c-ben irtak meg.

[Veér István]

@Emvy: igen, managelt nyelvben erõlküdni kell, hoyg elbaszd, de mitn az OpenSSL allokátor is mutatja, itt is megerõltették maguk a FOSShuszárok, hogy sikerüljön úgy istenigazából elbaszni. Ha itt csináltak egy fos allokátort,. máshol is megtehetik.

Egyébiránt a managelt nyelveknél a jittelt kós is azért assabb kb mindig mint a C kód, mert mindig készül explicit 0-ra inicializáló kód minden változónak helyfoglalásnál a natív kódba. Ez egy tervezési döntés volt, ami az ilyen esetek elõfordulásának valószínûségét csökkenti. Az immutable string is sokat ad a biztonsághoz, a C stílusú stringkezelés hüyleségeinek kivédésével. A jól definiált karakter és byte típusok is segítenek, hogy a multibyte szövegek ne legyenk kihívás.

Mindezek egyben a sebességen túl egyéb hátulütõket is behoznak: Például az immutable string jó, hogy ne csinálj buffer overrunt, de ellenben sokáig bennemaradhat a GC-s mûködés esetén a memórában pl egy jelszó szring, ezért ott azt nem szabad sima String ttípusban tárolni, hogy a rendszer meg tudja gátolni többek közt a jelszó kiswappelõdését, és egyáltalán minimalizálja a memórában nyersen olvasható formában töltött idejét.

Remélem, hogy a D nyelv elterjed, ami sokkal igényesebb és alkalmasabb ilyen feladatok kezelésére, ellenben támogatja a sima scoped nem GC-s objektum életcklus modellt, kód bizalmi szint annotációkat, és általában, C++ agyfasz nélkül.

[xclusiv]

Idézet: Emvy - Dátum: 2014. 04. 11. 11:46

Az OpenSSL, mint kod szinvonala meg egeszen elkepeszto, erdemes belenezni.

Ez elég régóta ismert probléma.
Szerintem itt van az ideje annak, hogy a web-es nagyok, akik erősen függnek ettől a ****kupactól (google, apple, fb, amazon, tanúsítványkiadók, bankok, telkók, stb.) összedobjanak egy team-et az openssl auditálására, még inkább újraírására.

[hilti]

Teljesen értelmetlen az OpenSSL esetében arról vitatkozni miért C-ben van irva és mennyivel biztonságosabb lenne ha modernebb nyelvben iródott volna. 1) kb. 20 éve kezdték el fejleszteni 2) az idõponttól eltekintve is meg van az oka hogy ANSI C-ben irták és opensource (pl. ezért tudják használni az utolsó gagyi környezetben is ahol van egy nyomorult C forditó) 3) egy C-ben C++-ban dolgozó képzett fejlesztõnek egy buffer overflow jellegû bug a lehetõ legcikibb probléma. A legalapvetõbb feladat ezek elkerülése ilyen nyelvi környezetben. Ráadásul van ezer alkalmazás az ilyen jellegû problémák ellenõrzésére, tesztelésére. Szóval normális esetben be sem lehetne "commit"-álni olyan kódot ami ilyen hibát tartalmaz.

[Veér István]

@hilti: egy normális esetben, ahol nem hobbista szabadságharcos gerillák végzik a fejlesztést. Az egész FOSS mozgalom rákfenéje, hogy pékek, szívsebészek, akadémiai arcok csinálják. Persze, hisz aki for-profit helyen dolgozik, az tudja, hogy mennyit ér a mukája, és tudja, hogy a szoftver fejlesztés egy kis (de nagyon fontos része) a kód megírása. Nem véletlen, hogy az opensource projektek esetében a dokumentáció, unit tesztek ritkaságszámba mennek.

[hilti]

azt már meg sem emlitem hogy az OpenSSL eléggé lejáratta magát tavaly az NSA storyval, szóval manapság már az is megfordul az ember fejében hogy egy ilyen horderejû hiba tényleg véletlenül kerül -e bele a kódba és marad 2 évig a fû alatt. Egy normális unit test esetén ki kellett volna buknia

[joghurt]

@Emvy: Egy eléggé közérthetõ magyarázat a Heartbleedrõl: http://xkcd.com/1354/

[dragon1993]

Nexus 4, Android 4.4.2 alatt azt írja ,hogy érintett.

[Emvy]

@joghurt: jaja, lattam

[montyx]

@dragon1993:
dettó. ez azért "mennek a picsába" szituáció nem kicsit. persze frissítés nulla, majd jön a 4.4.3...talán

[godot]

Az openssl-t fõképpen a Google fejleszti évek óta, szóval a fizetett fejlesztõik már szét auditálhatták volna ha akarják. A hibát is egy fizetett T-Systems alkalmazott tette a kódba.

[Leni]

@godot: Esetleg forrás? Vagy csak így bemondásra megy

[Emvy]

@godot: igazabol tokmindegy, ki rakta bele, mindenki hibazik. A durva az, hogy nem volt auditalva.

[godot]

@Leni:



http://www.smh.com.au/it-pro/security-it/who-is-robin-seggelmann-and-did-his-heartbleed-break-the-internet-20140411-zqtjj.html
http://www.smh.com.au/it-pro/security-it/man-who-introduced-serious-heartbleed-security-flaw-denies-he-inserted-it-deliberately-20140410-zqta1.html

Mellesleg Segglemann jegyzi többek között az RFC6520-at is aminek implementálása ilyen jól sikerült az openssl-ben.

A Google fejlesztõje fedezte fel a hibát egyébként, nézd meg az openssl forrástárolóját, meg azt is mennyi kód megy bele a Google-tól.

[godot]

@Emvy: Igazából @Veér István Floss huszáros megjegyzésére akartam reagálni. Az openssl-t is fõképpen fizetett feljesztõk tolják már régóta, és ettõl nem lett jobb.

[Leni]

@godot: "A hibát is egy fizetett T-Systems alkalmazott tette a kódba. "

És ez hol is van benne a cikkben? Az, hogy most épp ott dolgozik az egy dolog. Értem én mit akarsz mondani, de szerintem az állításod itt eléggé félrevezetõ..