Biztonsági hiba az OpenSSL-ben egy debianos patch miatt

Címkék

A DSA-1571-1 számot viselő Debian Security Advisory (DSA) szerint egy korábbi, hibás Debian OpenSSL patch miatt a rendszerrel előállított kulcsok nem megbízhatóak, a véletlenszám-generátorban okozott gyengeség miatt.

A hibát Luciano Bello találta, aki megállapította, hogy a Debianban található OpenSSL csomag véletlenszám-generátora megjósolható kimenetet ad. A "könnyítés" egy nem megfelelő Debian patch-csel került be a rendszerbe.

A DSA szerint minden, a Debianban lévő és 0.9.8c-1-es verziónál újabb (értelemszerűen a most javítottnál korábbi) OpenSSL segítségével létrehozott összes kulcsot célszerű lecserélni. Továbbá az összes -érintett Debian rendszeren- aláírásra, vagy autentikációra használt Digital Signature Algorithm (DSA) kulcsokat kompromittáltnak érdemes tekinteni.

A 0.9.8c-1 verziószámú, hibás OpenSSL 2006. 09. 17-én került bele az akkori unstable disztribúcióba és onnan került vissza az etch-be is. A sarge nem érintett ezzel a hibával.

Hozzászólások

Ezért veszélyes -nem hozzáértőként- patchelgetni más kódját. Szerintem sokkal rosszabb a Debian "tartsuk a verziót és próbáljuk patkolni az új hibák megismerése után", mint ha rendesen frissítenék a programokat az épp adott legújabb verzióra...
(a kernel detto, csak az nem Debian-betegség)

Ez miert lenne Debian only problema?

Masreszt ezzel a hozzaallassal soha senki nem fejlestzhetne mas kodjat, csak az, aki elkezdte.

Harmadreszt igy meg mindig kevesebb hiba kerul a produktion rendszerekre.

Negyedszer pedig a disztribeknek a kernelt kell patchelniuk. Ez Linus ajanlasa, tetszik vagy nem.

tompos

Az advisory szerint debian-specific, a CVE-2008-0166-ot probaltak annak idejen javitani debian-specifikus modon.

A kriptografiaval kapcsolatban en is azt gondolom, hogy aki nem ert hozza az ne nagyon nyuljon ezekbe a kodokba, keves mas terulethez kell ilyen alapos elmeleti hatterismeret.

Igen, ahhoz a szokáshoz, hogy a debian régi verziót patchel, ennek semmi köze.

Bra cikkének rossz a címe, az eredeti patchnek semmi köze nem volt a securityhoz, az eredeti patch semmilyen hibát nem javított, csupán egy vélt hibát. Az, hogy az a vélt hiba nem is hiba, egyértelmű volt az akkori openssl fejlesztői dokumentációjából és forráskódjából is.

Ezek a seggfejek egyszerűen megjavították azt, ami nem is volt rossz. Közben bevezettek egy _nagyon durva_ security bugot. Megnézve a diff-eket, látható, hogy az openssl maintainere egyáltalán nem ért a C-hez, nem tudja mi az az #ifndef és nem tud megkülönböztetni out meg in paramétereket. A bevezetett security hibát szép csöndben kijavította egy május 7-ei unstable feltöltésben, aki olvasott changelogot, akkor kiszúrhatta a durva sebezhetőséget, mégis csak ma szóltak róla.

A hiba TÉNYLEG kihasználható és nem csak elméleti. Az elmúlt két évben a hibás szoftverekkel generált kulcsok egy 2^18 nagyságú halmazból kerülnek ki, nem pedig az elvárt 2^80 - 2^160 szokásos nagyságrendűből.

Egy könnyen előállítható szótár segítségével tetszőleges nyilvános kulcsról megmondható a titkos kulcsa, illetve egy nem hibás szoftverrel generált, de bármikor is hibás szoftverrel felhasznált DSA kulcshoz az aláírás ellenőrzője (tehát pl. a szerver keyauth esetén) meg tudja mondani a titkos kulcsát.

NEM ELEGENDŐ a szoftvercsomagok frissítése, az összes DSA kulcs törlése és a 2006-nál újabb RSA kulcsok törlése szükséges. Továbbá minden olyan kommunikációt, amit ilyen kulcsokkal végeztünk plaintext csatorna fölött végrehajtottnak célszerű feltételezni, azaz a jelszavainkat is változtassuk meg!

Soha nem írok ilyen webes fórumokba, azért tettem kivételt, mert ez most komoly.

Gergő

--8<--
Package: debian-keyring
Priority: optional
Section: misc
Installed-Size: 25652
Maintainer: James Troup
Architecture: all
Version: 2007.12.04
Recommends: gnupg (>= 1.0.6-4)
Filename: pool/main/d/debian-keyring/debian-keyring_2007.12.04_all.deb
Size: 20600706
MD5sum: 2625bdad6930ef0b9bd6177daa483946
SHA1: df006a96a855777aa9a0320b7e03c6176f2e3e6b
SHA256: 460afdbe2f691525f71b0fc7429a071cbd7287f1576c2dc2c77fa994169c4155
Description: GnuPG (and obsolete PGP) keys of Debian Developers
The Debian project wants developers to digitally sign the
announcements of their packages with GnuPG, to protect against
forgeries. This package contains keyrings of GnuPG and (deprecated)
PGP keys of developers.
Tag: role::app-data, security::authentication, suite::debian
-->8--

fincsi lesz ...

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

http://www.links.org/?p=327

Incidentally, while I am talking about vendors who are bad for security, it saddens me to have to report that FreeBSD, my favourite open source operating system, are also guilty. Not only do they have local patches in their ports system that should clearly be sent upstream, but they also install packages without running the self-tests. This has bitten me twice by installing broken crypto, most recently in the py-openssl package.

Ahaha. :D

Nem tud valaki egy junior sheep administrator állást valahol? :)) Nincs kedvem cserélgetni a kulcsokat . :/

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

"Ez miert lenne Debian only problema?"
Mert ők a bug szerzői.

"Masreszt ezzel a hozzaallassal soha senki nem fejlestzhetne mas kodjat, csak az, aki elkezdte."
A Debian nem fejleszti az OpenSSL-t (és más csomagokat), hanem kiválaszt egy verziót, azt beleteszi a $RND_TYSTRY nevű kiadásába, majd befagyasztja a kódot, ahhoz már csak bugfixeket ad ki.
Ez meg azért veszélyes, mert az 1.0.0-ás eredeti kód helyett két év múlva már a 3.5.4-nél tart a fejlesztő, majd kiderül, hogy van egy bug.
A Debian csomagolónak el kell döntenie, hogy ez érinti-e az 1.0.0-át. Nem mondanám, hogy ez triviális feladat. Aztán ha úgy gondolja, hogy igen (itt már elvileg érti a régi és az új kód működését is), adaptálnia kell az eredeti fejlesztő javítását a régi verzióra.
Ezt elég sok helyen el lehet rontani, és új hibákat is hozhat (lásd fent).

"Harmadreszt igy meg mindig kevesebb hiba kerul a produktion rendszerekre."
Ezt azért bizonyítanod kellene. Rendszeresen olvasom az általam használt programok changelogjait és bizony a legtöbbnek már elég stabil kódbázisa van ahhoz, hogy ezek a changelogok nagy része bugfixekről szóljon, azaz nem új funkciók, hanem hibajavítások kerülnek be.
Szerintem egy apache 2.2.8 kevesebb hibát tartalmaz, mint a 2.2.0. Csak a hasamra ütöttem, de hogy ne mondjak hülyeséget, azért az előző mondat leírása után megnéztem a changelogját is:
http://www.apache.org/dist/httpd/CHANGES_2.2.8

Szerintem teljesen egyértelmű, hogy nagyobb kockázat 2.2.3-as apache-ot futtatni (a Debian-féle kókányolással meg főleg), mint frissíteni 2.2.8-ra.

"Negyedszer pedig a disztribeknek a kernelt kell patchelniuk. Ez Linus ajanlasa, tetszik vagy nem."
Szerencsére nem érint. Sem mint fejlesztőt (a hajam kitépném), sem mint felhasználót.
De azért még tarthatom rossznak, ugye?

Ez meg azért veszélyes, mert az 1.0.0-ás eredeti kód helyett két év múlva már a 3.5.4-nél tart a fejlesztő, majd kiderül, hogy van egy bug.
A Debian csomagolónak el kell döntenie, hogy ez érinti-e az 1.0.0-át. Nem mondanám, hogy ez triviális feladat. Aztán ha úgy gondolja, hogy igen (itt már elvileg érti a régi és az új kód működését is), adaptálnia kell az eredeti fejlesztő javítását a régi verzióra. Ezt elég sok helyen el lehet rontani, és új hibákat is hozhat (lásd fent).

Melyik disztribútor nem így jár el? (komolyabbak közül, pl. Novell, Red Hat. Fedorával kíméljetek, az a másik véglet)

Nem követem nyomon a Linux disztribúciókat, ezt értelemszerűen olyannak kellene megválaszolnia, aki igen.
Jellemzően FreeBSD-t használok, a hozzá adott portok ilyenek. Ahol nem kell, nincsenek saját patchek, ahol kell, ott rendszerint OS-specifikus (fusson, elérési utak, stb), illetve sokszor előfordul, hogy ezeket a következő release-nél törli a karbantartó, mert az eredeti fejlesztő beletette a kiadásba.

Nekem nagyon bejött a "stabil" alaprendszer (amelyből szolgáltatásokat tekintve szinte semmit sem használok, szinte minden ports-ból megy), amelyre -teljesen elkülönülve, ez nálunk a menedzsment megoldás miatt is fontos, hiszen külön tudunk OS és ports release-t csinálni- olyan progikat teszek, amiket akarok.
Eddig sehol sem zavart, hogy a 7-es FreeBSD-n 2.2.0-ás apache-ról 2.2.8-asra tudtam frissíteni anélkül, hogy hackelni kellett volna bármit, ha pedig a 2.0.x-ről frissítettem a 2.2.x-re, tudtam, hogy változhatott a konfiguráció, egyebek, ezért előtte utánanéztem, kipróbáltam, hogy mivel jár ez.

Ez a te döntésed, de nem úgy, mint a Debianban, ahol "unstable", meg "testing" csomagokat kell használnod (amelyek ugye ugyanazon ágból hivatkoznak librarykra, meg rossz esetben az "egész OS-re").

Nekem logikusabb és használhatóbbnak tűnik, mint a debianos megoldás.

"- az OpenBSD-sek szeretnek ilyet csinálni (sőt, átvenni, és folytatni a maguk szakállára)"

debianosok ugyan ezt csinálják

"... mindenesetre én a magam részéről az elvet tartom rossznak."
akkor hogy állunk most?

hibázni meg hibázhat bárki, lehet holnap meg obsd-sek jelentenek be hasonló bugot ...

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

Egy szóval sem mondtam, hogy szerintem az OpenBSD jól csinálja, nem is én hoztam ide.
A Debian meg tudtommal nem éppen a forkjairól, vagy rewrite-jairól híres (mint OpenSSH, OpenCVS, meg kitudja még mi).

Hogy állnánk? Szerintem az OS vendor próbálja követni azoknak a programoknak a verzióit, amelyekből építkezik, ne pancsolja a kódot csak azért, hogy öt évig 2.2.0 lehessen a programból.

Értem ugyan, amit írsz, de remélem, hogy azért aki biztonsági javítást tol egy régebbi kódba egy új alapján, az legalább érti, amit csinál... Legalábbis így kéne lennie.

Az viszont szerintem hasznos dolog, hogy a stabil verzióban nincsenek verzióváltások, mert nekem pl. a laptopomon, ahol testing debian fut, nem egyszer előfordult, hogy aptitude upgrade után valami nem indult el (mert mondjuk új lett a konfig fájl formátuma, vagy ilyesmi).
Ezt stabil rendszeren jó elkerülni.

Szóval van két szempont. Aztán a választás az meg voltaképp az üzemeltetőé, hogy akkor ő most stable-t, testinget, unstable-t, vagy mit tesz fel magának.

G

A "legalábbis így kéne lennie"-vel kapcsolatban csak Gergőt tudnám idézni: "Ezek a seggfejek egyszerűen megjavították azt, ami nem is volt rossz. Közben bevezettek egy _nagyon durva_ security bugot. Megnézve a diff-eket, látható, hogy az openssl maintainere egyáltalán nem ért a C-hez, nem tudja mi az az #ifndef és nem tud megkülönböztetni out meg in paramétereket."
Pedig ő aztán nagyon odavan a Debianért. :)

Szóval sajnos jellemzően nem ez a helyzet. Aki csomagol, az nem feltétlenül gyakorlott programozó és ha ne adj isten az is lenne, akkor sem biztos, hogy van ideje megérteni a változást, vagy egyáltalán átlátja az egészet teljes egészében.

Ezt a témát feszegettem már korábban is (lusta vagyok előkeresni a hozzászólásokat): az, hogy a vendor (jelen esetben Debian csomagoló) önmaga patchelget, biztonsági kockázat (lehet), mert nem feltétlenül érti a kódot, illetve a változást, amit bevitt.

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

Itt a srác levele. Ő javította 2006-ban a nem létező bugot. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=363516

Szerintem nem úgy tűnik, hogy semmit nem ért hozzá, de az látszik, hogy érthetne többet :-)

Viszont mi többet tehet valaki, aki mondjuk nem ért valamit a maga teljességében, minthogy a fejlesztőket megkérdezi?

Ha meg ott senki nem mondja neki azt, hogy figyelj, ne vedd ki, mert az kell, akkor nem értem, miért ő a hibás.

G

Lehet az ok, "pillanatnyi" rövdizárlat is. Volt már rá példa valamelyik sarge kernel frissítésnél asszem, hogy a kernel image csomagolásánál elfelejtették betölteni a kernel configot és kb. modulok nélküli kernel image el jöttek ki első körben.

Meg nem mondom hány csomag van most összességében a debian etchben mondjuk, de még ha 99% os teljesítményt nyújtanának, akkor is úm. "elszarnak" több mint 100 csomagot.

--------------------

Nem a zsömle kicsi, a pofátok nagy...

Ez meg azért veszélyes, mert az 1.0.0-ás eredeti kód helyett két év múlva már a 3.5.4-nél tart a fejlesztő, majd kiderül, hogy van egy bug.

Ez szerintem egy kétélű dolog. Egyrészről igazad van, másrészről meg nincsen, mert a 3.5.4 tartalmazhat olyan bugokat amiket az 1.0.0 nem / ha elfogadjuk azt hogy minden programban vannak hibák, akkor azt is el kell hogy minden új funkció által használt programrészekben is, mivel ezek a régi verzióban nincsenek meg, így a régi program ilyen téren "érintetlen" /, harmadrészt lehetnek olyan változások amelyek miatt az 1.0.0 -s verziót használó rendszeren a 3.5.4 már nem fut el. Negyedrészt lehetnek egyéb olyan külső alkalmazások melyek az 1.0.0-t használják és a 3.5.4 essel már nem mennek el.

Szándékosan nem mondtam programnevet sehol sem, csak tisztán elméleti alapon írogatok egy "képzelt" program 1.0.0 és 3.5.4 verziója között. :-)

Szerintem egy apache 2.2.8 kevesebb hibát tartalmaz, mint a 2.2.0.

Nem erről van szó, hanem hogy ezek közül hány olyan "magas kockázatú" (pl. biztonsági) hiba van ami 2.2.8at érintette és 2.2.0 2.2.3-at is?

Ill. hogy konkrét példánál maradjunk a debian etch ben levő apache2 azért elég sok lib* -től, stb. függ. Verzióemelésnél ezt a tényezőt is figyelembe kell venni, mert új apache2 + túl régi lib* környezet okozhat inkompatiblitási problémákat pl. A verziószám lépés nem túl nagy mondjuk, de ez önmagában még nem garancia semmire sem.

--------------

Nem a zsömle kicsi, a pofátok nagy...

Ez miért is következne a fentiekből? A legalacsonyabb semmiképp.
A BSD-k amúgy teljes operációs rendszerek (nem csak egy csomagkezelő és hozzá egy rakás csomag, meg némi saját ragasztó), amelyek "gyártói" hasonlóképpen járnak el sok alkalmazás tekintetében, mint a Debian: az alap OS-ben lévő 3rd party alkalmazások egy részét főverzión belül nem váltják, csak a biztonsági hibák hatására frissítenek.
De -konkrétan a FreeBSD-nél- nincs olyan éles policy, hogy egy STABLE-ben nem lehet sendmail verziót ugrani (meg is teszik nemegyszer), inkább a karbantartóra van bízva, hogy mit választ:
- megpróbálja megérteni az egy-egy hibára adott gyártói bugfixet és azt visszatenni a régebbi kódba (lásd fent)
- ha hiba van és van patch, de még nincs release, patchel és utána frissíti az egész alkalmazást
- ha hiba van, megvárja a release-t és arra frissít
- mindig frissít, ha új verzió van és úgy látja jónak (hiszen ezért karbantartó, hogy kipróbálja a saját rendszerén, utána beletolja a CURRENT-be, majd ha nem volt vele gond, le a STABLE-be)

Mi az az egy, amit értesz? Mi lenne, illetve mire gondolsz? Szerinted az apache 2.2.x-nek más az API-ja, mint a 2.2.y-nak?
Jó esetben a vendor dolga, hogy rendben tartsa a szoftverét és ne csak egy HEAD/trunk/akárminek hívják a verziókezelőjében verziót csináljon, amelybe ész nélkül fejleszt, majd minden második hónapban reszel picit és kiadja azt, ami van.

Akkor javaslok egy számolási módot: featureök száma/kiadások száma=hibalehetőség mértéke

Azaz az int main(){return 0;} kód 0 (feature)/1 (kiadás), azaz 0 hibalehetőségű.

Nyilván minden project minősége más, de egy project különböző kiadásait már össze lehet hasonlítani talán ezzel a módszerrel.

Ettol bonyolultabb az egyenlet.
Valoszinuleg kijon, hogy a hosszan karbantartott valtozatok megbizhatobbak egy kicsit.

Alapvetoen ugy szoktak kalkulalni, hogy az l soros szofvarben van n hiba.
A teszteles/hasznalat soran t ido alatt a hibak p reszet ]0.0..1.0[ talaljak meg. A kov t ido intervallumban a maradek p reszet .. stb. (Ez fugg a teszterek szamatol, hibatalasi kepesegeitol) (ebbol lehet diff egyenletet karcolni)

Az egyenlet tovabb bonyolodik, hogy gyakorlatilag ugyan arrol a szoftverrol van szo, de L sor megvaltozott, es feltehetoleg hasonlo sor/hiba aranyban kerultek hibak, mint az elozo verziokba.

Egy olyan szoftvernel amiben hiaba van 10000 hiba felhasznalok nagyobb resze nem talalkozik egyikkel sem, felfedeznek mondjuk 9000 belole es javitjak (mondjuk 1 ev alatt), akkor egy ujabb l/L<0.01 kodvaltoztatas mondjuk hozz 100 uj hibat. Amiek felet par heten belul javitjak. Maradek elhuzodik. Igy mondjuk 1050 vs. 999 rejtett hiba lehet morfondirozni.

Feltehetjuk azt is, hogy fejlesztok is tanulnak es tesztelok (userek) szama is novekedett..
(Ha szofware felhasznali szama novekszik, a hibak felfedezesenek sebbesege is novekszik.)

Most nincs kedvem szamolni..
Hagyhatjuk is, mert ez meg mindig nem a teljes kep :)

Ha jól látom egy dolgot nem veszel figyelembe. Ez pedig az, hogy itt nem arról van szó, hogy egy szoftvert a fejlesztője lineárisan javít/fejleszt és kész, hanem arról, hogy a szoftver halad a maga ütemében, míg a disztribútor leragad egy adott verziónál, amire próbálja rátenni a közben megváltozott szoftverhez készült javításokat.

Az olyanra csak a masodik bekezdes vonatkozik. A bugfix hibathozhat azt nem szamoljuk :), (ritka eset ,hogy kvazi azonal(1-2nap) nincs belole anyazas.)

Ne bonyolitsuk tul, igy is -ugy is rengeteg ismeretlen konstans lesz az egyenletbe, amit nehez merni.
szerk:
(Vagy bugfixalo sorokat lehet mas hiba esellyel szamolni)

Ahogy mondod, bullshit, a valosaghoz az egvilagon semmi koze nincs. Altalaban nem minden programot fejlesztenek ugy, mint Linus a kernelet, hogy ma mar egy 2.6.5-hoz fejlesztett akarmilyen driver talan nem is mukodne - pedig csak 20 alverziot ugrottunk. Sokan igyekeznek verziokon at kompatibilisek maradni, es ha uj api van is, ahol lehet megtartjak/emulaljak a regi api-t, es szep lassan etetik meg a fejlesztokkel a valtozasokat. Szal nem rogton Linus fejlesztesi modelljebol kellene talan levezetni minden opensource projekt fejlesztesenek modelljet, mert lehet, hogy nincs igazad...

A Linuxot nem követem figyelemmel, de a FreeBSD-ben a 4-es óta az egyik leginkább piszkált terület pont ez.
Nem hiszem el, hogy az MSI, a PAE és hasonlók miatt semmi nem történt a PCI környékén a 2.0-ás verziótól fogva. Márpedig ha történt, azt sem tudom elhinni, hogy az API végig változatlan marad. Főleg a Linuxnál, ahol függvények neveződnek, tűnnek el és jelennek meg a semmiből subminor verziók között...

Enable deprecated pci_find_* API:

CONFIG_PCI_LEGACY:

Say Y here if you want to include support for the deprecated
pci_find_slot() and pci_find_device() APIs. Most drivers have
been converted over to using the proper hotplug APIs, so this
option serves to include/exclude only a few drivers that are
still using this API.

make menuconfig @ 2.6.25

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

"Valoszinuleg wines arc irta mert, olyanok a valtozo nevek benne :)"

Mert a "wines arcok" milyen változóneveket használnak szemben a !win-s arcokkal?

Jó, annyit el tudok képzelni, hogy egy normális fejlesztőkörnyezethez szokott valaki, aki eléggé használja az autocompletet, az inkább ír beszédesebb osztály, függvény és változóneveket, - merthogy úgy se kell kiírni - és kevésbé rövidít.

Visual Studio óta én is egyre inkább beszédesebb neveket használok PHP-ben.

Asszem néhány perccel lekéstelek a hírküldéssel, bra! :)

Kicsit többen használnak Debiant.
Pláne a Solarisos nyomtatóra szólt, ami megint szűkíti a kört, az az érzésem, hogy az élesben használt Solarisok 90-a (vagy még több) nem használ nyomtatót.
Ez az SSL téma jóval általánosabb, mindenkit érint

-----------------------------
Ubuntu 8.04

Sajnos ez a bug nem csak a Debian-t erinti. Mivel a security bug atcsorgott az Ubuntu-ba is: USN-612-1. Valoszinuleg a tobbi Debian leszarmazott disztro is erintett.

A masik problema, ha a rendszeredbe egy user olyan SSH key-eket, stb masolt fel ami az erintett Debian-os/Ubuntu-s verzioju OpenSSL-el generaltak akkor te is sebezheto vagy attol fuggetlenul, hogy a tobbi disztro OpenSSL megvalositasaban nem volt ilyen problema. Ezert aki megenged ilyet a usereknek annak erdemes ellenorizni a kulcsokat a bejelentesben linkel progival, mas disztrok eseten is: Debian/OpenSSL Weak Key Detector

Az OpenSSL-es fejlesztok termeszetesen kiakadtak, ha valaki nem ert valamihez akkor miert nyul hozza. Illetve miert nem komunikalnak tobbet az upstream-el, ha elkultek volna a kerdeses "security" patch-et a fejlesztonek akkor ez nem tortenhetett volna meg. A blog bejegyzes: Vendors Are Bad For Security

Az USN linkről elindulva megnéztem egy Ubuntus OpenSSL patchet. Masszív, 200kb-s, 6000 soros diff. Ez így tényleg nagyon beteg. Na jó, második ránézésre ebben sok az Ubuntu specifikus komment meg konfigurációs cucc, de a többi? Nem hiszem, hogy egy Ubuntu vagy bármi más disztró használójának olyannyira eltérő OpenSSL-re lenne szüksége. Majdcsak tanulnak belőle.

--
joco voltam szevasz

Zorp és Shell Control Box userek reszkessenek... (utóbbiak egyébként is ;)

Mennyire véletlen az a véletlen szám

http://hup.hu/node/51006

--

"No trees were destroyed in the sending of this message. However,
a large number of electrons were terribly inconvenienced."

A 0.9.8c-1 verziószámú, hibás OpenSSL 2006. 09. 17-én került bele az akkori unstable disztribúcióba és onnan került vissza az etch-be is. A sarge nem érintett ezzel a hibával.

Hiába, Az nem hibázik, aki nem dolgozik, annyiban gáz, hogy ennyi ideig "lappangott".

------------------

Nem a zsömle kicsi, a pofátok nagy...

Hmm... szvsz inkább számold újra. Azért jóval több "kritikus"-abb csomag van. Kezdheted mindjárt a libc* csomagokkal, kernellel, mielött a "hálózati" csomagokhoz, vagy a biztonsági, titkosító cuccokhoz érsz. ;-)

Ne csak azt számold, amit te használsz... ;-)

Meg aztán próbál(d/játok) egy kicsit más felhasználói szemszögből is.

Nálam pl. az openssl pár éve már nem mission critical. Finoman szólva. :-D

------------------------------

Nem a zsömle kicsi, a pofátok nagy...

Kicsit utánaolvasgattam a témának:

az látszik, hogy az openssl az entrópiát csak (vagy főként?) inicializálatlan memóriaterületből nyeri. Ezt kivették a debianosok, és akkor jól lecsökkent a kulcsok véletlenszerűsége.

kérdés: ez szerintetek jó eljárás? Amikor még programoztam, simán voltak olyan memóriaterületek, amik egy adott mintával voltak teli, amikor megkaptam. Mondjuk 55 ff 55 ff 55 ff. Ez nekem nem tűnik nagyon jó entrópia forrásnak.

Egyébként meg vicces, hogy itt mindenki fikázza őket, hogy ha nem értenek hozzá, miért javítják... közben ez a Kurt Roecx nevű gyerek még 2006-ban írt az openssl-dev listára, hogy hát itt ez a cucc, és panaszkodik a valgrind, és most akkor mi van... mert talán kivenném az egészet francba, de lecsökken akkor az entrópia

Erre meg azt írták neki, hogy voltaképp nem csinál semmit az egész, vedd ki nyugodtan. :-)

Senki nem írta, hogy eszedbe ne jusson

G

De. Írták azt is.

Meg valaki más azt írta, hogy nem is kell az, vedd ki nyugodtan.

De azt, hogy figyelj, ki ne vedd, mert az baromira kell, azt nem írta senki.

A -DPURIFY kapcsolóval ha jól értem az volt a gond, hogy nem az a csóka problémázott, aki a hibát javította, és akinek azt mondták, hogy fordítsa purify-jal, hanem ez egy hibajelentés volt, mert valaki nekilátott, és a valgrid ontotta a hibákat.

A hibajegyben ott ment a tökölés, hogy akkor mi legyen, első lehetőség: wontfix. De aztán azt írták, hogy ez így nem lesz jó, mert sokan, akik tesztelnek, itt-ott belefutnak ebbe a hibába.

Ha meg lefordítja -DPURIFY kapcsolóval, és úgy adja ki, az végülis ugyanaz, mint amit a folt csinált: kihagyja belőle ezt az utasítást.

G

NEM!

-DPURIFY-al nem lett volna semmi baj.

Olvassátok már el a kódot!

Vagy itt megpróbáltam leírni a lényeget, meg adtam még egy csomó linket:
http://www.gergely.risko.hu/debian-dsa1571.en.html

Egyébként pedig aki azt mondta, hogy kiveheti, az azt írta oda, hogy "debuggoláshoz kiveheted".

Gergő

Azt jelenti, hogy a normális működéshez nincs köze, csak ha debuggolsz, akkor segít.

De egy dolgot értsetek már meg:

Nem arról volt szó, hogy a Deb maintainert zavarta a cucc, mert ő akart debuggolni.

Hanem valami Debian felhasználó valami más program debuggolása során kapta a hibajelzéseket, és ezért egy hibajegyet nyitott.

Teljesen mindegy, hogy XY. újra tudja-e fordítani saját magának debuggoláshoz a libraryt.

Azt próbálták meg elérni, hogy kiadjanak egy libet, ami bárkinél, aki debuggol, nem fog hibákat dobálni.

A srác nem értette, OK. Megkérdezte az OpenSSL levlistán, és ott meg baromira senki nem mondta, hogy figyelj, ez rossz ötlet, nehogy kivedd...

A válaszok alapján az ő helyében simán lehet, hogy hasonlóképp döntöttem volna.

Bár ÉN biztos nem, mert persze én még kevésbé látom át, mint a maintainer, szóval én semmit nem piszkálnék bele abba a kódba :-)

G

Igen.

Vagyis?

Ha valaminek a normális működéshez nincs köze, csak ha debuggolsz, akkor segít, akkor azt gondolom ostobaság lenne debuggoláshoz kivenni. Nem?

Viszont ha normális működéshez nincs köze, akkor ha nem akarok debuggolni, vagy nincs szükségem a debuggolás közbeni segítségre, akkor kivehetem probléma nélkül.

Én így értelmezném a leírtakat.

És igen, értem, hogy valószínűleg pont fordítva van, mert pont debuggoláshoz nem kell ez a rész (sőt, segít, ha kiveszed, mert nincsenek félrevezető hibaüzenetek), és a normális működéshez meg kellene.

Csak éppen a válaszban nem ez volt. Szegény csóka meg ezek szerint úgy értelmezte a leírtakat, ahogy én is.

Vagy én értek valamit félre? Majd ha lesz időm, újra elolvasom.

G

az látszik, hogy az openssl az entrópiát csak (vagy főként?) inicializálatlan memóriaterületből nyeri.
Hibas. Az openssl rengeteg forrasbol gyujt entropiat, es az egyik ilyen forras az inicializalatlan memoriaterulet. Ha a memoriaterulet alacsony entropiaju, az nem rontja a poolt, ha magas az viszont javitja, tehat nincs vele kockazat.

Ezt kivették a debianosok, és akkor jól lecsökkent a kulcsok véletlenszerűsége.
A Debianosok nem az inicializalatlan memoriaval valo buveszkedest vettek ki, hanem magat entropia pool frissitest (ahol vegul az inicializalatlan memoria olvasasra kerult, es ezaltal a valgrind ott jelzi a problemat).

Szerintem nem kellene teljesen hulyenek nezni az OpenSSL fejlesztoket.

The second law of debian
The total entropy of any system tends to increase over time, if you don't use stupid debian patches.