Pár gondolat a Debian SSL bugról

 ( errge | 2008. május 16., péntek - 8:08 )

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.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

"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...

Szerencsés helyzetben vagyok többszörösen is.

- ahol van ssh-m, ott nem érintett rendszerem van
- nincsenek usereim egyik éles rendszeremen sem (sose voltak, nem is lesznek)
- az "ssh-vulnkey -a" nem talált semmit

Ja. Szerencsefia.

Kihagytam valamit? :)

--
trey @ gépház

makod van, iszom is mindjart erre egy sort :P

--
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

Igen, akár szophattál is volna. Mérges is lehettél volna, főleg magadra. Senki sem mondta neked, hogy Debian-t, Linux-ot _kell_ használnod. Használhatsz pénzes operációs rendszert is. Persze, ott sincs semmi garancia arra, hogy ilyen baleset nem ér.

--
trey @ gépház

titkon azért egy picit hadd legyen mérges a biztonságmítosz (a sebesség-, kódminőség- és transzparenciamítoszhoz hasonlatos internet meme) lebegtetőire is

Anyagi okokból? Napi lol?

--
trey @ gépház

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 ;)

e!

Pedo mellon a minno! :)

"xandros (eee pc) gives root access if asked in stern voice" rotflmfao

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

De csak a Debian-ban és "leszármazottaiban"! :)

--
trey @ gépház

A programokban és a disztribútorok által szállított kernelekben.

Érdekes, hogy ezt a párhuzamot valahogy senki sem vonja meg...

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:

  1. Ismeri azt a szoftvert a fejlesztő, amibe belenyúlt?
  2. Nem, mert amit módosított rajta, egy egyszerű fordításkori kapcsolóval megadható lett volna...
  3. Legalább rendesen végezte a patchelést a fejlesztő?
  4. Nem, mert ezzel még egy másik hibát is beletett, amit csak 5 hónap múlva (!) javított ki
  5. 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?
  6. Nem, ilyet nem tett.
  7. Bejelentette, hogy több tíz/százezer gépet tett ki veszélynek 2 éven keresztül?
  8. 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.
  9. Kiadtak a Debianosok észlelőeszközt hozzá?
  10. 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.
  11. Tanultak a hibából?
  12. 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.

Szerintem elkuldte. 2 sort mutatott amit kivenne, szolhattak volna, hogy az egyiket nagyon nem kene...

Valoszinuleg kiprobaltak a -DPURIFY -t is, de nem abba az iranyba haladtak tovabb:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=363516#30

De gondolom ezt jobban tudod, elnezest.

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).

Bár, ha jól értem, az egyik sort semmiképpen nem szabadott volna kivenni...

szép kis rainbow table vagy micsoda.
Én egészen egyszerűen entrópiát mérnék (Kolmogorov) az összes generált kulcson: amolyan "milyen erős a kulcs" thermoként, bár ezek után ki bízna meg benne...

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 ;)

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

remélem nem gondolod komolyan, hogy a debuntu nem átgondolt szoftvereket csomagol

ROTFL :D

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

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 ! -

Gondold már végig, hogy mit írsz. Hülyeség és fizikai képtelenség is mindezt összehozni az összes Linux disztribúciónál. Nem beszélve arról, hogy neked is Linux=OSS.

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 ! -

implicit kérem szépen airwin tette ezt, én csak megrökönyödésemnek adtam hangot

nem, airwin csak az openssl-t fikazta (szerintem nincs igaza). Te extrapolaltal a teljes disztribuciora.

- 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?

Elnézést, de van fogalmad arról hogy miről írsz?
//no offense

Kifejtenéd?

lejjebb. a szövegben a 'technikailag' arra vonatkozott, hogy az entropy pool nem lesz sokkal szegényebb attól, ha az inicializálatlan területet nem számolja bele az openssl. ezért is van ott a PURIFY-os rész.

>> Tehát "technikailag szólva" nem csinál semmit.

ilyenről nincs szó az általad idézettben

Valóban. Ott arról van szó, hogy tulajdonképpen mindegy, hogy inicializált vagy nem inicializált puffert ad hozzá az entrópia-pool-hoz.

Egyaltalan nem erted, amit idezgetsz. Szo sincs rola, hogy mindegy lenne, milyen puffert adnak hozza. Ha inicializalt (pl. csupa 0-t tartalmaz), akkor ennek megfeleloen nagyjabol semmit sem er az egesz. Mig ha veletlen tartalmu, akkor szignifikansan noveli az entropiat.

É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.

Minek inicializálni? Csak olvas egyet belőle, és máris ott a véletlen-szám... ;)

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."

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

Igen, az még eddig nem vetődött fel, hogy az eredeti forrásban nem volt ott egy hatalmas, vastag komment, hogy ez a megoldás szándékos és így működik jól.

Ez a thread arról szól, hogy az openssl egy nagy gány. Nyilván lelkes matematikusok írták, akik fél évet tanultak programozni. A kripto résszel nincs bajom, csak a többivel.

Tessék tudomásul venni, hogy az inicializálatlan memóriaterület nem véletlen adatokat tartalmaz.

Olyan figyelmetlen vagy, mint ide buda :)

Ja nem, mert budán vagyok, de szóval érted... Nézz utána.

Gergő

olvassal mar utana. nem a inicializalatlan memoriaterulettel volt gond, hanem, hogy mashol is random beletaknyolt a kodba ezert semmilyen mas forrasbol nem volt entropiabevitel.

--
A game with words...

Ha a fejlesztő vette volna a fáradságot, és odaír akár egy félsoros magyarázatot, hogy a nem inicializált memória használata itt nem hiba, akkor sehol nem taknyolt volna bele a karbantartó.

nem is taknyolt bele sehol, csak a debuntuban

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.

köszi a megerősítést

az most miert az upstream hibaja, hogy valaki random (pun intended) beletaknyol?
ha ezt megmutatja, egy openssl fejlesztonek, hogy o igy szallitja a csomagot, akkor sikitva szedeti ki vele.
amugy oda volt irva, hogy /* purify complains */.

--
A game with words...

Idézet:
amugy oda volt irva, hogy /* purify complains */

Ez egy nagy nulla komment, nulla információtartalommal. A sor kikommentezése után odaírnám mellé, hogy /* not any more */

eppenseggel megmutatta az openssl-dev -en, es egyvalaki reagalt, hogy OK. persze valoszinuleg debuggolasra ertette, de ugy tunik felreertettek egymast.

Mindenesetre senki nem hordult fel, hogy mekkora baromsag...

>> eppenseggel megmutatta az openssl-dev -en
eppenseggel ezt nem

--
openssh-server depends on openssh-blacklist

ez a környezete nélkül, teljesen félrevezető kommentárral kiragadott 2 sor, és végig egyértelműen debuggolásról van szó

--
openssh-server depends on openssh-blacklist

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.

Váááá! A második hatalmas :D

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...

Erről van szó!

He commented out the only important line of a one hundred line long function
Nem nagyon hiszem, hogy ez véletlen volt.

Szerk: ja, és ez a 2. változtatása nem is magyarázható semmilyen Warning szűréssel.

a tét óriási.

ez most vagy átcsusszant a spamszűrőn, vagy a mese morálja végülis az, hogy a m$ lefizette a debuntut (illetve hát manyeyeballs urat is)

ha másképp nem lehet kiskaput csinálni ... akkor csinálnak így


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

íme a nyílt szoftver gyenge pontja. mindig előnyként hirdetik, hogy a kód nyilvános, mind a 6 milliárd ember láthatja, hogy nem káros. látHATja :)

--
joco voltam szevasz

hmm valami nagyon megpatkoltak,
etch alatt 16384 bites RSA generálás ~90perc
lenny alatt csak ~40

:)


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

A kulcsgenerálás jellegéből kifolyólag ugyanazon a rendszeren egymást követően két azonos bithosszúságú kulcs generálása sem lesz ugyanannyi idő... :)

hw ua, os nem
lenny alatt kétszer generáltam :P egyet tagnap, egyet ma
etch alatt csak tegnap este, de az feltűnöen hosszú volt ..


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

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.

ha ssh-key-jel lépsz be, akkot más is be tud lépni, mivel összesen 65536 fél keyt lehetett legenerálni a hibák miatt
sshd-cert is ilyen, és a user keyek is ..


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

amugy ez a gpg kulcsokra is ervenyes (gyk. email alairasok, titkositasok)?

szerk: lehet, hogy hulyeseg, csak azert gondolom, mert az openssl-lel gyartott certifacate-k is gondolom most igy rosszak, oszt lehet, hogy a gpg is openssl-lel gyartja a titkot.

- Use the Source Luke ! -

A GPG-t kihangsúlyozták hogy nem érintett, csak az openssl. Hogy ez pontosan mit fed, olvasd el a teljes bejelentést, ennyit nem foglalkoztam vele :)

azt irtak, hogy gnupg nem erintett, mert gnutls-t hasznal, nem openssl-t...

Őszintén szólva nem tudom, mi az, hogy "ssh-key-el lépsz be" (gondolom távolról ssh-n keresztül). Nem, helyi gépről van szó.

nem lett volna egyszerűbb azt mondani, hogy "nem", ugye? :)

!igen :)


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

Köszönöm a választ és kérdeznék még /csak egyet :)/.
Denes megelőzött, mármint
"amugy ez a gpg kulcsokra is ervenyes (gyk. email alairasok, titkositasok)?"
kiegészíteném, hogy a tárolók által használt kulcsokat sem érinti?

"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

Igen a repokra, köszönöm mégegyszer.

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.

Debian WIKI a szükséges intézkedésekről:
http://wiki.debian.org/SSLkeys


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

Attention whore much, Riskó?

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

Ahh, Gergő, mint attention whore. :)

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ő

lehet hogy tevedtem, akkor bocs.

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.

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?" -=-

hmm egy jó kis Sarge? csak az a baj, hogy már nem támogatott, de az tényleg össze volt rakva...


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

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?" -=-

"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)

ich4-ben és inteles FWH párosban van hw-s rng


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