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

 ( bra | 2008. május 13., kedd - 15:44 )

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

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.

Sajnos nem pontosan ugy van, a CVE-2008-0166 konkretan a debian-specifikus bugrol szol. Maga a problema 2006-os, ez okoz komoly fejfajast az etch/lenny/sid hasznaloknak.

Jogos, legalabb az evszam feltunhetett volna a CVE szamozasban :)
A masodik tippem a changelogot olvasva az, hogy a 363516-os bug javitasat sikerult ennyire lelkesen vegezni.

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ő

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

Nem kellett volna, főleg, hogy fekete a kalapod... :P

Valóban, javítottam a címet, remélem jobb lett. :)

Nem követtem ezt az egészet, mert tegnap dolgom volt, de ha csak a debianos OpenSSL-t érinti, akkor a cikk címének talán jobb lenne a

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

cím, hacsak a debianos patch nem érinti az upstream-et is. :)

--
trey @ gépház

So-so, mert az Ubuntut is érinti, viszont nem tudni még pontosan, hogy kik vették- és kik nem vették át a nem-hiba javítását.

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

A mai (tegnapi?) frissítés, amiben valami 2×93000 kulcsot blacklisteltek az ezzel kapcsolatos?

szerk: igen, az ismert sebezhető kulcsokat tartalmazza.

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

De ezek elavult GnuPG kulcsok, amik amúgy sem érintettek. Csak az ssh-k. Szóval szerintem nem egyről beszélünk.

Jah. Azért mondtam, hogy "de ha csak a debianos OpenSSL-t érinti", mert elsőre ez volt az infó.

--
trey @ gépház

Azt, ami a Debianból származik, de nem tudtam rájönni, hogy lehetne szépen, szóismétlés (debianos) nélkül megfogalmazni ezt.

Miért? "Elpecselte a Debian az OpenSSL-t" vagy "Félrepecselt OpenSSL Debianéknál" :)

Mondj egy disztribúciót ami naprakész, ellenőrzött és ritkábban fordul elő benne ilyen baklövés.
--
the tide is turning

FreeBSD :)


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

Naprakész, ritkábban (sokkal, mert nem pancsolnak ennyit a forrással) fordul elő ilyen. Viszont a Debiannal szemben nem ellenőrzött, hiszen abban minden port kőkeményen nyomon van követve, a hibás részeket a """"fejlesztő"""" újraírja a saját ízlése szerint, stb.

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.

Azért a kettőt ne hasonlítsd össze, teljesen más.

a junior sheep admin allast meg a kulccseret?

igazad van, az elso nyugisabb :)

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

A velemenyem nem egyezik a Tieddel.

:)

tompos

Ez persze megengedett, de pontosan mivel nem értesz egyet?

Idézet:
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)

Ha tőlem kérdezed, nem tudom.

Tőled kérdezem, felvetetted a problémát, de ha szinte senki se csinálja máshogy, akkor mégse olyan triviális az általad javasolt megoldás...

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.

Nem Debian jelenség. Az OpenBSD licenc okokból még mindig 1.x-es saját Apache fork-ot terjeszt.

--
trey @ gépház

http://hup.hu/cikkek/20080513/biztonsagi_hiba_az_openssl-ben_egy_debian-os_patch_miatt#comment-556193

Amúgy meg az OpenBSD-ben sem túl gyakori eset ez, ennél azért több nagyságrenddel más a Debian.

Az OpenBSD-ben pl az openssl 0.9.7 -es masszív 0.9.8 patch hegyekkel....

Nyilván nem újdonság neked, hogy:
- az OpenBSD-sek szeretnek ilyet csinálni (sőt, átvenni, és folytatni a maguk szakállára)
- az alaprendszerben sűrűbben előfordulnak ilyenek

Lehetne még sorolni ezeket, mindenesetre én a magam részéről az elvet tartom rossznak.

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

"A Debian meg tudtommal nem éppen a forkjairól, vagy rewrite-jairól híres (mint OpenSSH, OpenCVS, meg kitudja még mi)."

Nem az OpenBSD-sek?

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

debianosok ugyan ezt csinálják"

Nem, nem ugyanazt csinálják.

de sokkal kisebb az esélye, mivel obsd-t használnak 10--en, akkor debiant 1000-en
(nem valós adatok, mielött bárki belekötne :P )


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

Szerintem itt kár "maszatolni" stb. Ez nagy debian/ubuntu bukta, tény.
Vannak olyan disztrók amik arra törekednek, hogy minél kevesebbet patcheljenek, ami általában működik is.

Természetesen ez nagy probléma. Nem állítottam az ellenkezőjét. Pláne nem beszéltem disztrókról. Az OpenBSD házon belüli forkjáról tettem említést.

--
trey @ gépház

É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

Szerintem a rendszer hibás. :)

szerintem is. túl nagy a kísértés, hogy ilyen és hasonló ismert bakik ismétlődjenek.

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

"Debian GNU/Linux provides more than a pure OS: it comes with __over 18733 packages__, precompiled software bundled up in a nice format for easy installation on your machine."

debian.org kezőoldal ;)


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

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

Tehat a BSD-k kockazata a legalacsonyabb.

nem nem :)
ott a Debian GNU/kFreeBSD is


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

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)

1. az alaprendszert ők fejlesztik, tehát alaprendszer hibáit ők tudják legjobban kijavítani
2. a 3rd party csomagokból általában upstream által karbantartott verzió van

Az alaprendszer hány százaléka (pld. kódsorban) a saját, és hány a külső program?

Ha az upstream=a fejlesztő(k), erre adhatnál valami hivatkozást is, konkrétan a FreeBSD portoknál nem tapasztalom ezt (érzésre).

mennyi lehet, 25-30%?

--
Segmentation violation -- Core dumped blues

BSD változattól függ.

http://distrowatch.com/table.php?distribution=freebsd
Distrowatch szerint eleg friss a -STABLE ág.

a patcheles elegge gyakori es nem mindig kuldik el es ez neha a karbantartok hibaja.
viszont van, amikor az upstream egyszeruen nem hajlando elfogadni a valtozasokat, es ez a legrosszabb eset.

--
Segmentation violation -- Core dumped blues

Ha jól látom ez a portokról szól, amelyeknek nem sok közük van egy-egy release-hez.

Egyet ertek.
De mi lesz igy az instabil API bullshittel ?

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.

Szerintem (lenyegeben) nem.
De trolljaink maskep gondoljak. :)

Projectol fugg, de altalabn igaz szerintem, hogy az uj verzio kevesebb uj hibat hoz, mint amennyit befoltoz + uj feature-k.

Ezek szerint akkor az int main (){} kódban van a legtöbb hiba, a következő verziók már mind jobbak ebből a szempontból?

Nem. Akartam Project korosztalyokrol beszelni.., de vegul meggondoltam magam, mert kiveteleket en is tudnek mondani igy is - ugy is, de nagyabol en igy tapasztalom.

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)

bugos amit irtal: nincs return

Csak azért, hogy a következő kiadásban legyen mit javítani.

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

Pld. OpenLDAP, ha használja valaki...

Most irtam at egy (merokartya) drivert ami 2.2-hez fejlesztettek , valami 6 sor diszeleg 2.4-re valo atallas miatt, most ujabb 6 sorral hoszabb lett (hogy 2.6.9 felett is mukodjon), es uj Makefilet -kapott.

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

Ezek szerint vannak még olyan részei a Linuxnak, amelyekhez évek óta nem nyúlt senki.

(Nem a kernel ressze ez a driver , nehogy valaki felre ertse )

PCI busz nem valtozik :)

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

kvazi egy fuggveny atnevezes es egy eltolas.
Ez volt benne ketszer, a maradek par sor meg a makrok (if verzio).

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

http://www.ussg.iu.edu/hypermail/linux/kernel/0409.3/0374.html

Memoria kezeles valtozott, igy az eszkozok memoriajanak user fele mapolasa is.
(Kesobb el is tavolitottak deprecated reszt, 6 lepesben fokozatosan..)

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

p,dw,i,w -vel kezdodes, wines kodokban szoktam latni.
(Egy idoben en is atvettem, de szerintem csak meg rondabb lett kod tole..)

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

érdekes, debianos bakira mindenki jön, mint szarra a legyek :) de solarisos remote bugra senki :P


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

A vilag mar csak ilyen.:)

ez még érdekesebb akkor lehetne, ha lenne mellette valós (utópia) adat arról, hogy melyik milyen felhasználási gyakoriságú és súlyú :)

--
xterm

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

Itt: szar=Debian, legyek=mi?

jaja, de szar helyére bármit be lehetne rakni .... solaris, bsd, ...


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

Figyeld! Már védekezeik :DDDD

--
Aki falra szerelt tehennel vitatkozik, olyan mint vonat kerek nelkul, nem jut sehova.

Mert azon senki nem lepodik meg :)

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

atcsorgott az Ubuntu-ba is: USN-612-1.

Öröm a bajban, hogy ezek szerint a 6.06.2 LTS nem érintett.

init();

Viszont máris van javítás.
--
the tide is turning

Ja a javitas is kulon szep volt. Egy hettel ezelott commitoltak, gondolom kozben valakinek szemet szurt, hogy ez egy biztonsagi hiba, es igy most kiadtak egy security advisory-t.

Mit kellett volna tenniük?
--
the tide is turning

hogy magának is Nagyapa imitátornak tetszik lenni?

Időnként igen, de csak viccbül. Most viszont abszolúte nem értem miért tetszik ilyet pofázni.
--
the tide is turning

sot, ha debianon generaltal kulcsot es azt hasznalod barmilyen mas oprendszeren akkoris szivas van. de gondolom a hardcore debian userek mindig puttyal generalnak kulcsot :) (hapedig azis csutortokon mond, jon a frugalware install)

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

Nézz meg egy redhatos kernel patchet. Lassan nagyobb, mint maga a kernel.
Ja persze az nem ér, mert a Red Hat ért hozzá, hiszen ott dolgoznak a kernelhackerek.

Ez este mindenkepp bekerul az overlaybe...

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

orgyilkos

http://weho.st
never happen if you never try

A ZORP nem érintett mivel Sarge alapú (az openssl egyébként 0.9.8a benne Balabitos patchekkel)

A Balabit elvileg kiad egy Advisory-t, hogy nem értintett, viszont felhívja a figyelmet a problémára.

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

Hogy is volt az a signo? "Barki, aki aritmetikai modszerekkel akar veletlenszamot eloallitani, a bun allapotaban leledzik" vagy valami ilyesmi...

volt egy ilyesmi is:

int rand()
{
  int Veletlen_szam=3; //garantaltan veletlen, most dobtam ki 6 oldalu dobokockaval
  return Veletlen_szam;
}

tevedsz, a szabvany veletlen szam a 4: http://xkcd.com/221/

(tudomasom szerint a fenti oldal az eredeti forrasa ennek a viccnek)

az egy idezet Neumann Janostol:

"Anyone who considers arithmetical methods of producing random digits is, of course, in a state of sin."

(lsd. pl. http://en.wikipedia.org/wiki/Pseudorandom_number_generator ahol meg a forras is meg van adva)

egy perl progi, amivel lehet detektálni a rossz key-eket
(a lista még nem teljes a program üzenete szerint ...)

http://security.debian.org/project/extra/dowkd/dowkd.pl.gz


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

legalabb a repo-ba belerakhattak volna...:]

openssh-blacklist - list of blacklisted OpenSSH RSA and DSA keys

igaz nem a script, csak a rossz kulcsok ide-je

szerk.:
man ssh-vulnkey
ssh-vulnkey


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

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

annyiban gáz, hogy ennyi ideig "lappangott"

manyeyeballs úr mégse dolgozik elég hatékonyan?

hát ha megnézed hány csomag van, és arra mennyi karbantartó+fejlesztő jut, lehet a "many"-t törölnöd is kéne ;-)

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

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

"hát ha megnézed hány csomag van (...)"
OpenSSL szintu? Haat, 20 alatt.

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

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

"Hmm... szvsz inkább számold újra."
Szamolasrol itt szo sem volt, az ertek hasrautessel jott, de irhattam volna 120-at is, a lenyegen nem valtoztat.

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

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

Felettébb ciki. :)

Nem azt irtak neki, hogy forditsa -DPURIFY-al?

http://www.openssl.org/support/faq.html#PROG14
http://wiki.debian.org/SSLkeys / A bit more detail

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ő

"az azt írta oda, hogy "debuggoláshoz kiveheted"."

Pontosabban azt írta, hogy "If it helps with debugging", ez pedig nem azt jelenti, hogy "debuggoláshoz kiveheted".

hát mit jelent?

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

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

a debuggolás ideje alatt, és csakis addig

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

ennyi erővel akár kiadhatott volna egy libsslfoo-dbg csomagot is, de akkor lehet, hogy még most sem tudnáknk róla, igaz szinte senki nem használná


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

"a debuggolás ideje alatt, és csakis addig"

Ezt az @openssl.org-os emailcímű emberke írta? (;

ha úgy kérdezed, hogy szájába rágta-e silentfixer barátunknak, hogy a következő napokban milyen billentyűket nyomjon le, és milyen ütemben vegye a levegőt, akkor nem

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.

Honnan szerez initcializalatlan memoriat ?
Ujabban divat kinullazni minden lapott, mielott a processe lenne.

1. és? akkor nem hoz be plusz entrópiát, de ettől nem romlik el az algoritmus.
2. "újabban", de nem minden rendszer új ám
3. még ha ki is nullázódik az első hozzáférés előtt, a processz futása közben már mindenféle szemét lesz mindenütt

--
joco voltam szevasz

3. szemet az lesz, de entropia nem lesz belole igy.

csak most akkor ugye miért kell azt a púpozott raklap kulcsot lecserélni, és emberemlékezetig visszamenőleg mindent kompromittáltnak tekinteni

ezt mondta v is itt feletted, nem értettem miért pont a memóriaterülettel van gondod az eset kapcsán, de most már értem mire akartál kilyukadni

(Valoban , nem olvastam ujra a szalat mielott valszoltam)
Nem az eset kapacsan, de az a bajom, hogy szerintem rossz entropia forras.

én sem voltam elég körültekintő, elnézést

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