Pár gondolat a Debian SSL bugról

Vélemény

Megkérdőjelezhető stílusban, de olvasmányosan megpróbáltam összefoglalni a Debian aktuális OpenSSL hibáját és a következményeit. Tartalmazza a javítani szándékozott hiba leírását, a disclosure felháborító részleteit, és egy korábbi nagyon hasonló hibára való utalást. Megtalálható itt.

( trey | 2008. 05. 16., p – 08:11 )

"If you say that anyone can make a mistake, then I will give you the final shock now. When he found it out, he silently updated the package on 2008-05-07 in unstable."

Az elfogadható, hogy valaki hibázik. Ki nem hibázott még soha? Az azonban, hogy valaki megpróbálja ezt leplezni, takargatni, az nem.

Az az egy szerencséje a jóembernek, hogy nem érint a probléma. Ahol Linux-on ssh-t használok, ott Dapper fut. A Dapper pedig - afaik - nem érintett szerencsére.

Egyébként is alapszabályként alkalmazom, hogy SSH-t csak trusted hostra engedélyezek, kulccsal és nem az egész világnak.

--
trey @ gépház

"Egyébként is alapszabályként alkalmazom, hogy SSH-t csak trusted hostra engedélyezek, kulccsal és nem az egész világnak."

de most pont az a helyzet, hogyha olyannak adtal hozzaferest, aki erintett debian/ubuntu renszeren generalta a kulcsat, akkor erintett vagy te is.

--
A game with words...

Engem az dühített, hogy nekem pl. emiatt kellett egy új SSL cert is. Szerencsére a reissue nem került pénzbe (benne volt az árban), de sok helyen ez is pénzbe kerül, és ha fizetnem kellett volna, akkor hajjaj, most még mérgesebb lennék.

Biztos ami biztos, az új kulcsot és a csr-t már FreeBSD-n generáltam :P

Akár. De látom, harapós kedvedben voltál, sebaj.

Valóban senki sem mondta, de mégis megvan a bizalom részemről - mégha halovány is - a Debian és Ubuntu rendszerek iránt. Ahol ez az Ubuntu alapú vps fut, nem futtathatnék pénzes operációs rendszert, de tegyük hozzá, hogy nem feltétlenül akarnék egyáltalán.

De valószínűleg bármit írhattam volna, megkaptam volna arra is a leszólást ;)

( kikke | 2008. 05. 16., p – 09:31 )

És még hány ilyen hiba lehet...
--
the tide is turning

( szotsaki | 2008. 05. 16., p – 10:08 )

A másik legjobb, az ellenőrzés:
"Kiadtak egy 5 MB körüli bináris hasht tartalmazó ellenőrző csomagot, amelyről senkinek sincs fogalma, hogyan készült. De persze ők sírnak a legjobban, ha akár 1 kb-os bináris firmware-t kapnak valamelyik gyártól."

Ha elemezzük az eddigieket, elég érdekesen néz ki a helyzet:

  • Ismeri azt a szoftvert a fejlesztő, amibe belenyúlt?
  • Nem, mert amit módosított rajta, egy egyszerű fordításkori kapcsolóval megadható lett volna...
  • Legalább rendesen végezte a patchelést a fejlesztő?
  • Nem, mert ezzel még egy másik hibát is beletett, amit csak 5 hónap múlva (!) javított ki
  • Tájékoztatta a fő fejlesztőket, hogy belenyúkált egy kriptográfiai szoftver kódjába, ami amúgy az egyik legkényesebb terület a biztonságtechnikában?
  • Nem, ilyet nem tett.
  • Bejelentette, hogy több tíz/százezer gépet tett ki veszélynek 2 éven keresztül?
  • Nem, egyszerűen azt gondolta, hogy majd maguktól szépen néhány éven belül lecserélődnek a hibás kulcsok, és a gond el lesz felejtve.
  • Kiadtak a Debianosok észlelőeszközt hozzá?
  • Igen, még talán ez a történet egy pozitív pontja, ámbár ezt is csak késéssel tették meg. Ami külön érdekes, hogy azt már nem mondják sehol a nyílt forráskód leghangosabb szószólói, hogy ez az eszköz hogyan készült.
  • Tanultak a hibából?
  • Valószínű nem, mert korábban eljátszódott már egy hasonló eset.

Lehetséges, hogy más disztróknál is előfordul a fenti felsorolásnak egy-egy pontja, de ennyire bénák nincsenek, hogy szinte az összes lehetséges hibát elkövessék, amit el lehet, mind az egyéni fejlesztő szintjén, mind az egész projekt szintjén.

--
- Name ONE thing that your Linux computer can do that my MAC can't!
- Right click.

"# Tájékoztatta a fő fejlesztőket, hogy belenyúkált egy kriptográfiai szoftver kódjába, ami amúgy az egyik legkényesebb terület a biztonságtechnikában?
# Nem, ilyet nem tett."

just for the record:

http://marc.info/?l=openssl-dev&m=114651085826293&w=2

De mar sokszor leirak, csak ugy tunik pofazni konnyebb. Az egeszbol csak az vilagos, hogy ez egy ronda nagy pech es alapveto biztonsagi kodok tekinteteben nagyobb odafigyeles kene, _mindket_ oldalrol.

Ha ertenel angolul, akkor tudnad, hogy debuggingot elosegitendo tette fel a kerdest. Es a valasz is ott volt: "build with -DPURIFY". Kiprobalta? Nem hinnem...

Amugy meg a tajekoztatas az lett volna, ha a zsenialis patch-et atkuldi az openssl developereknek. Vajon mi lett volna a valasz?

Es NEM, az openssl-ek NEM FELELOSEK a debian-specific patch-ekert. Ezt verd ki a fejedbol.

Na jo, belemegyek.

Ket sort mutatni, vagy kuldeni egy patch-et, hogy olvasszak be a kodjukba nem ugyanaz a dolog. Fel sem merult, hogy a valtoztatas bele kene keruljon az openssl kodbazisba. Pedig - imho - egy ilyen valtoztatast az ember NEM csinal, megbeszeli az openssl fiukkal es majd OK teszik bele, ha jonak latjak.

Tehat szerintem a fiuk nem neztek meg, mirol is van szo, mert nem lehetett komolyan venni a dolgot. En se sz@rnek ra, ha valaki a sajat celjara belemaszik a kodomba. Ha viszont be akarja olvasztani, az mas tal teszta.

A beidezett post-ban szo sincs purify-rol, sot, az egesz bugreport soran csak a Kurt altal beidezett kodreszletben jelenik meg, na meg egy mostani post-ban, amely magyarazza mi is tortent. Ugyanugy idezhettel volna akar a http://xszemes.hu -rol is. Errol ennyit.

Szerintem itt alapvetően félreértették egymást. Legalábbis az openssl-devel mindenképpen csak debuggolásra gondol, ez látszik a válaszból. ("If it helps with debugging, I'm in favor of removing them.") A kérdésből meg az, hogy Kurt nem igazán érti, hogy mit csinál az a 2 kivett sor. ("What I currently see as best option is to actually comment out those 2 lines of code. But I have no idea what effect this really has on the RNG. The only effect I see is that the pool might receive less entropy. But on the other hand, I'm not even sure how much entropy some unitialised data has.")

Mindegy a véleményem nem változott. Olyasvalaki ne gányoljon bele kritikus dolgokba, amit nem igazán lát át. Még az se nagyon, aki átlátja, inkább a develekkel közösen. Így mellesleg mindenki profitál belőle (ha előremozdító dolgot csinál).

magán a kulcson hiába mérsz entrópiát, az a megszokott értéket mutatná. a probléma azzal van hogy a prng inicializálása (seed-elése) nem elég véletlen, és ha ugyanarról indítod a pszeudo-véletlenszám generátort, akkor ugyanazt a 'véletlen' sorozatot fogja generálni mindíg...

ott már tényleg késő.
Viszont meggondolnám, hogy ha az IV-vel (~kel) nem tud mit kezdeni egy zip, az már jó jel lenne. Nemtom, vak ötlet.(egyébként ismert init-es prng-k gyakoriak az [MC] szimulációknál, de tény, hogy ez nem az az eset, amikor reprodukálható eseteket kell generálni ;)

( airwin | 2008. 05. 16., p – 10:20 )

Az OpenSSL is egy jól átgondolt szoftver ám. Nem-inicializált buffert használni véletlenszám generálásra...

jo vicc volt, mi? mondjuk minden linux disztribucio ugyanannyira atgondolt szoftvereket csomagol (leven, hogy ugyanazokat a szoftvereket csomagoljak, max. mas verzioban). Ilyet meg lehet irkalni, hogy minden linux disztribucio szar (ugye snq- troll implicite ezt tette) - majd Adi jot rohog, de azon kivul nagy butasag.

- Use the Source Luke ! -

asszem kcsit felreertettem snq--t, en altalaban a szoftverek atgondoltsagarol regeltem, mint pl. a szoftver alapveto strukturaja, stb. (ugy ertettem snq- troll hozzaszolasa erre utal), nem arrol, hogy tesznek-e bele durva bugot. Mert szerintem amugy is a szoftver maga lehet atgondolt, meg ha van is benne egy durva atgondolatlansag (a debian bug).

Amugy linux reszhalmaza az OSS-nek, mibol gondolod, hogy szerintem Linux=OSS ? Mindenesetre, rosszul gondolod.

- Use the Source Luke ! -

Pihengessél, légyszi'! Azért röhögtem snq kommentjén, mert annak ellenére tudom benne értékelni az iróniát, hogy néhány gépen nekem is kellett most kulcsokat cserélgetnem.

--
Sokan nincsenek tudatában annak, / hogy egyszer mindenki meghal. / Akik ráébrednek erre, / azonnal abbahagyják az ellenségeskedést.

"When OpenSSL's PRNG routines are called to generate random numbers the supplied buffer contents are mixed into the entropy pool: so it technically does not matter whether the buffer is initialized at this point or not. Valgrind (and other test tools) will complain about this. When using Valgrind, make sure the OpenSSL library has been compiled with the PURIFY macro defined (-DPURIFY) to get rid of these warnings." - FAQ

Tehát "technikailag szólva" nem csinál semmit. Így már oké. Vajon az openssl hány százaléka áll olyan kódból, ami "technikailag szólva" nem csinál semmit?

És szerinted mit tartalmaz egy nem-inicializált puffer a stack-ben?

Mert szerintem rosszabb esetben ugyancsak csupa nullát a memórialap ZFOD-jának köszönhetően.

Jobb esetben egy előző függvény stack-frame-jébe címez bele, ami valószínűleg kevés változó adatot fog tartalmazni. Ez már nem nulla, de a tippem, hogy vajmi kevés információ lesz benne, ami futásról futásra változik. Ez pedig nem sokkal növel entrópiát.

Szerintem.

nem csak az inicializálatlan memóriaterületről van szó. a csávó egész egyszerűen a teljes entropy pool frissítést kikommentezte (amúgy ha jól tudom pl. diszkmegszakításokból, egyéb io műveletekből és hasonlókból is gyűjt az openssl entrópiát, nem csak az inicializálatlan memóriából).

az #ifndef PURIFY -os rész csak az inicializálatlan területre vonatkozott, de ha már ott látott egy MD_Update függvényt, akkor hirtelenmódon kikommentezte a kód egy másik részén is, ahol másfajta, inicializált pufferekre hívták volna.

Ja, elmennek a picsába ezzel a takony megoldással. Mintha nem volna más lehetőség véletlenszám kinyerésére. Meg azért is elmennek, hogy ennyire dokumentálatlanul hagynak egy ilyen gány megoldást. Ha már gány (perze, honnan tudná, hogy gány, hiszen ő HIGHLY SKILLED SECURITY SOFTWARE DEVELOPER) legalább odaírná, hogy nebáncsd. Vagy még inkább, hogy fixme.
Vagy legalább azt, hogy miért is van úgy, ahogy...

Az, hogy Pongor/Vitéz a kurva nagy halálfejes karót rávési egy ilyen megoldásra, az hurkabiztos. :)

Persze a Kurt is béna volt. És nem csak fejlesztőként, hanem kommunikációból is. Ha nem értem az egymondatos választ, akkor biztos visszakérdezek. Legfeljebb nem a debian.org -os mailcímemről, hogy ne járassam le a projektet (ha ez valakinek fontos...) :)

Szóval itt páran jól elcsesztek valami fontosat, ami miatt kb. mindannyian szívunk. Ez gáz. Én mondjuk kiraknám a csávót a maintainerek közül, az biztos.

A Debian projekt nevében pedig örömmel kontributálnék forrást valami korrekt véletlenszámgenerálás megoldásra.

--
Gabriel Akos

Az esetek legalább 99,9999 százalékában a nem inicializált memóriaterületet felhasználni hiba. Ha ilyet találok valahol, én is kijavítom, mert normális esetben nem csinál ilyet az ember. Ha mégis ilyen megoldást kellene beépíteni, akkor alaposan le kell dokumentálni, hogy miért jó úgy, ahogyan van. Ha nincs dokumentálva, az egy hatalmas BUG!

Az, hogy csak a Debianban jött elő a probléma, nem véletlen. Gyanúm szerint máshol bele se néztek a kódba, csak ész nélkül kiadták. Extra szerencsétlenség, hogy aki "fixálta" a bugot, nem volt a helyzet magaslatán, illetve senki nem ellenőrizte, hogy mit csinál.

Tehát szerintem mind a két oldal vastagon sáros az ügyben, az OpenSSL developerek legalább annyira, ha nem jobban, mint a Debian maintainer.

a kornyezete nelkult nem ertem (ott van, h melyik file hanyadik sorai), a felrevezeto kommentarral kapcsolatban nem tudom mire gondolsz es ugy tunik nem mindenki szamara volt egyertelmu, hogy vegig debuggolasrol van szo. Akkor vegulis szerinted nem mutatta meg?

Teny, hogy ha mar belepiszkalt mas kodjaba -ami raadasul ilyen fontos-, 3szor meg kellett volna kerdeznie, hogy akkor jo lesz-e igy, en csak arra a nepszeru velemenyre reagaltam, miszerint az openssl fejlesztok sirva rohogtek volna mar az otlet lattan is.

( ezqgtouvszfgc | 2008. 05. 16., p – 11:46 )

don't employ silly ones.
Pont fordítva, a cucc zseniális: egy sor kikommentezésével elég nagy hatást el lehet érni, csak egy kis valgrind narratíva kell, amihez talán a purify comment adhatta a tippet -- részemről export kompatibilitási patch-nek tekintem, ahogy a többit (D5). Hogy ezt így benézték a debiannal, és a verisign-által finanszírozott canonicalnal, az adja az egésznek a pikantériáját...

Sziasztok!

Mivel nekem ez a téma magas mint "malacnak a zsiráf vályú" kérdeznélek benneteket, hogy egy átlagos felhasználó számára jelent ez a hiba valami biztonsági kockázatot? Átlagos felhasználó alatt értem, hogy feltelepítem a rendszert és pár alkalmazást, majd használom.

"Affected keys include SSH keys, OpenVPN keys, DNSSEC keys, and key material for use in X.509 certificates and session keys used in SSL/TLS connections. Keys generated with GnuPG or GNUTLS are not affected, though."

elvileg azok nem érintettek, ha a repokra gondolsz

debian gnu/linux @ linux-2.6.22.24-op1 | patch
info

( penztar v | 2008. 05. 16., p – 19:31 )

Hello!

Ha jól értelmeztem a bejelentést és itt a postokat akkor generálni kell új kulcsokat a serveren is és a userek kulcsát is,ugye?
Erre meg én csak azt szoktam mondani ,hogy amit ember készít az soha nem hiba mentes.
Üdv.

( comet | 2008. 05. 16., p – 20:48 )

Attention whore much, Riskó?

Azt megértem, ha blogolod az érzelmeidet, de miért kell itt a hupot szennyezni?

Bocsi, ha zavar a két sor, amivel utaltam rá :)

Odaírtam, hogy szándékosan megkérdőjelezhető stílusban van, nem muszáj elolvasni.

Valamint egy csomó olyan félreértést tisztáz, ami a köztudatban él ezzel kapcsolatban és szerintem egész jó kis linkgyűjtemény is van a végén a bugról.

Van ugyanazon az oldalon eldugva egy készülő unix (értsd: shell programozás) jegyzet is, ami szerintem egész friss és tartalmas a (magyar) versenytársakhoz képest és sehol nem láthattad hírét. Pont azért, mert még nincs kész (még annyira se, hogy a saját elvárásaimnak megfeleljen) és nem akarok előbb szennyezni vele. Persze most megtettem de csak 8x. commentként, így remélem megbocsátod ;-)

Gergő

latom csendben kiszedted azt a reszt, hogy (kb) "sikitva rohogtek volna az openssl fejlesztok, ha meglatjak" es betettel egy linket alulra, amibol felig-meddig kiderul, hogy bizony megmutatta es most az openssl-es arcok kodositettek.

egy UPDATE szekciot illett volna letrehozni, ha mar kinn volt a cikk nyilvanossag elott. nem mindegy, hogy Kurt totalisan balfasz, vagy csak nemileg balfasz es felreertettek egymast egy openssl fejlesztovel. (http://marc.info/?l=openssl-dev&m=114652287210110&w=2)

Az én weblapomon az sosem volt kint. Valószínűleg összekeversz a links.org-os 347-es poszttal, abban volt ez a rész, emlékszem rá.

És azt a threadet, amire hivatkozol, olvasd is végig, hogy lásd, hogy azt mondták neki, hogy vizsgálja meg a PURIFY konstanst és, hogy csak debugging esetén nyúlkáljon azokhoz a részekhez.

Gergő

( ngaba | 2008. 05. 17., szo – 10:46 )

Mondjuk nem tudom ki vette észre a hibát, de megemelem a kalapom előtte, ha ezt az óriási bugot nem használta ki előtte saját céljaira.

( Chain-Q v | 2008. 05. 17., szo – 18:22 )

A Debian PowerPC portjanak minosege meredeken esik, miota kitettek Sven Luthert, mert kritizalni mert par felistent az Installer teamben, mert honapokon at leszartak par fontos (es trivialis bugot javito) patchet a Pegasos meg az Efika telepitese kapcsan...

Most meg ez az OpenSSL bug. Nemreg bebootoltam az egyik regebbi vinyomon meg meglevo Ubuntu 5.10-et, es zokogtam, hogy ugyanazon a gepen mennyivel jobban megy, mint egy 8.04 vagy egy Etch.

Lassan tenyleg neznem kell egy masik disztrot, mer' kezd unalmas lenni... :(

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

A szervereim Dapper ill. Sarge alapuak mind, mennek is mint az atom, semmi gaz. Viszont desktopra ujabb cucc kell, es pl. a latest Gnash Etch-en sem fordul, csak Lenny-testingen, valami libc++ mizeria miatt (amit SZVSZ rohelyesnek talalok, de mindegy). Az FF3-rol nem is beszelve, stb. Szoval... :(

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

( pme | 2008. 05. 18., v – 17:33 )

"Anyone who considers arithmetical methods of producing random digits is, of course, in a state of sin." -- Neumann Janos http://en.wikipedia.org/wiki/Pseudorandom_number_generator

Kriptografiai software-ek eseteben alapveto dolog a "veletlen szamok" iranti igeny. A "software veletlenszam generalas" nagy varazslat, es az eredmenye mindig PSZEUDO veletlenszam marad.

Valami oknal fogva a veletlen szamok veletlensegenek vizsgalata nem elterjedt. Gyanitom, hogy rovidseguk miatt onmagukban ez nem lehetseges. A forras vizsgalata szinten nem vezet eredmenyre (felrevezeto eredmenyre vezet), ha a vizsgalat ki(le)merit(het)i magat a forrast. Ma sincs arra mod, hogy pontosan meghatarozzuk hany random bit-t van az entropy pool-ban.

Eros a gyanum, hogy az ssl belsejeben is tobb helyrol van "osszevadaszva" a seed, olyan "majd csak elegge ossze-vissza lesz" alapon. De nincs jo tervezesi eljaras, mely minden korulmenyek kozott megfeleloen mukodo seed-et produkal (PRZ os pgp-jeben meg billentyuket kellett nyomkodni a generalas soran, es a leutesek kozti idokulonbseget figyelte...).

A hardware veletlenszam generatorok hasznatala nem elterjedt, pedig nem tunnek bonyolultnak. Tegye fol a kezet aki ilyesmit hasznal: http://www.cryogenius.com/hardware/rng/, a tobbi mind bunos, beleerteve persze magamat is.

Aki nagy veszelyben erzi magat, akar gonosz behatolok, akar joindulau software-fejlesztok miatt, az sorgosen szerezzen be egy jo minosegu RNG-t. De ebben se higgyen vakon, ellenorizze a forrast statisztikai modszerekkel. (pl. http://www.phy.duke.edu/~rgb/General/general.php)