Végre Linus Torvalds elismerte, hogy ugyanazt a játékot űzi, mint a Microsoft

Már az LWN is ilyet ír:

"The fix was made by Linus Torvalds and went into the mainline on January 17, though with a commit message that obfuscated the security implications—something that didn't sit well with some."

Évek óta ezt csinálják, többedmagammal ez ellen már sokszor szót is emeltünk miatta, de itt már annyira kilógott a lóláb, hogy nem lehet letagadni vagy félremagyarázni...

Linus Torvalds úgy tűnik elismeri, hogy szándékosan rejtenek el biztonsági hibajavítást ártatlannak látszó commitokba:

"So I just ignore the idiots, and go "fix things asap, but try not to help black hats". No games, no crap, just get the damn work done and don't make a circus out of it.
Both the security camps hate me. The full disclosure people think I try to hide things (which is true), while the embargo people think I despise their corrupt arses (which is also true)."

A probléma a gondolatmenetével az, hogy azt feltételezi a disztribúció készítők és karbantartók okosabbak a blackhateknél.

Hozzászólások

Security people are leeches, vagy hogy is van az arany klasszikus? :)))

--
Java apps are nothing more than sophisticated XML-to-exception converters.

Én attól félek, hogy a nagy hírportálok ezt szépen el fogják hallgatni. Szerintem az lwn-t leginkább újságírók olvassák (mivel ugye fizetős a tartalom ha frissen kell), és ők válogatják ki ebből azt, ami nekik tetszik. Ez pedig valószínűleg nem fog tetszeni nekik.

#define újságíró

Nyilván végzettséged szerint nem vagy az, de mégis azzal (is) foglalkozol.

Oké, pontosítom: nyilván mindenféle emberek olvassák, de az átlagfelhasználó "tömegek"-nek nem éri meg előfizetni, mert ami érdekes azt úgyis lehozzák a különböző hírportálok is. Vagyis végső soron mégiscsak az lwn-t olvasó újságírókon (lásd fent) múlik, hogy ez a hír eljut-e a linux felhasználók, illetve a linuxos hírek után érdeklődők nagy részéhez.

Inkább arra reagálj, hogy szerinted mennyire reális az, hogy a szakmai hírportálok kevésbé (vagy akár semennyire) hoznak le olyan híreket, amik rossz színben tüntetik fel a linuxot. Persze itt elsősorban nem biztonsági hibákra és egyéb bugokra gondolok, mert bár azok is kellemetlenek, de azokat kijavítják és megy az élet tovább.

"Nyilván végzettséged szerint nem vagy az, de mégis azzal (is) foglalkozol."

Én a szakmám és a hobbim miatt olvasok LWN-t. Az oldal is ebből indult és nem abból, hogy újságíró akartam lenni. Én troll blogger vagyok, nem újságíró. Semmilyen újságot sem írok, vagy szerkesztek.

"Oké, pontosítom: nyilván mindenféle emberek olvassák, de az átlagfelhasználó "tömegek"-nek nem éri meg előfizetni, mert ami érdekes azt úgyis lehozzák a különböző hírportálok is. Vagyis végső soron mégiscsak az lwn-t olvasó újságírókon (lásd fent) múlik, hogy ez a hír eljut-e a linux felhasználók, illetve a linuxos hírek után érdeklődők nagy részéhez."

Az átlag felhasználói tömegeket ez, amiről itt szó van, nem érdekli. Egyrészt nem is értik miről van szó, másrészt elmondom neked, hogy a szakma több mint 90%-át sem érdekli és a szakma nagy része nem is érti.

Az LWN egy rétegoldal. Az olvasótábor nagy része Debian fejlesztő (nekik ingyen van full accountjuk), Linux developer a többi meg érdeklődő vagy olyan szakmabeli, akit érdekel ez a téma. Az LWN-t szerintem újságíró nem olvassa, én még az elmúlt 10 évben nem nagyon láttam mainstream oldalt az LWN-re hivatkozni. A HUP rétegoldal, itt van szó ilyesmiről. Mint ahogy arról is, hogy mi van a DragonFly BSD-ben. Szerintem a HUP egyike annak a _kettő_ oldalnak az egész világon, aki egyáltalán ilyesmivel foglalkozik. Ebből a HUP a legnagyobb.

"Inkább arra reagálj, hogy szerinted mennyire reális az, hogy a szakmai hírportálok kevésbé (vagy akár semennyire) hoznak le olyan híreket, amik rossz színben tüntetik fel a linuxot. Persze itt elsősorban nem biztonsági hibákra és egyéb bugokra gondolok, mert bár azok is kellemetlenek, de azokat kijavítják és megy az élet tovább."

Erre én nem tudok neked mit mondani. Lefizette őket Linus Torvalds? Vagy mire gondolsz? Én amiről tudok, arról írok. Hogy más oldalak miért nem írnak, azt én honnan tudjam?

Írd meg ezt a cikket és én kiteszem. Vagy várd meg, amíg lesz rá időm, aztán megírom én. Én jelenleg még nem tudom miről van szó, mert nem volt időm beleolvasni. Most komolyan tőlem kérdezed, hogy a CNN meg a ZDNet miért nem írja meg?

--
trey @ gépház

"Az átlag felhasználói tömegeket ez, amiről itt szó van, nem érdekli. Egyrészt nem is értik miről van szó, másrészt elmondom neked, hogy a szakma több mint 90%-át sem érdekli és a szakma nagy része nem is érti."

Azért feltételezem, hogy egy átlagos linux felhasználó sokkal szakmaibb beállítottságú, mint más dekstop operációs rendszerek átlagfelhasználói. Ma még a linux desktop nem tart ott, hogy nyugodt szívvel bárki kezébe lehessen adni egy linux telepítőt.

Akit pedig kicsit is érdekel a téma, azt valószínűleg érdekli, hogy az általa használt rendszer mennyire biztonságos valójában. Ez a hír pedig közvetve erről szól. Egy átlagos linux felhasználót szerintem igenis érdekel az ilyesmi.

"Erre én nem tudok neked mit mondani. Lefizette őket Linus Torvalds? Vagy mire gondolsz? Én amiről tudok, arról írok. Hogy más oldalak miért nem írnak, azt én honnan tudjam?"

"Írd meg ezt a cikket és én kiteszem. Vagy várd meg, amíg lesz rá időm, aztán megírom én. Én jelenleg még nem tudom miről van szó, mert nem volt időm beleolvasni. Most komolyan tőlem kérdezed, hogy a CNN meg a ZDNet miért nem írja meg?"

Nem a miért érdekel, arra van egy elméletem. Egyszerű: az újságírók (és itt még mindig nem mint szakmára, hanem mint tevékenységre gondolok) szubjektívek, és ez például abban mutatkozhat meg, hogy egyes (számukra negatív, látszólag jelentéktelen) hírekről egyszerűen nem írnak. Nyilván nem csak a linux részesülhet pozitív diszkriminációban, viszont bizonyos okok miatt (pl. ki ne szeretne egy opensource projectet, aminek fejlesztői önként és ingyen adják oda bárkinek munkájuk eredményét) szerintem nagyobb arányban részesül ebben, mint más projectek, szoftverek.

Engem az érdekel, hogy szerinted létezik-e ez a jelenség, vagy csak én képzelem be magamnak az egészet. (Azért annyit hozzátennék, hogy én nem utálom a linuxot se mint projectet, se mint szoftvert. De vannak dolgok, amiket nem tartok jónak, és furcsállom, hogy másoknak ezek a dolgok elfogadhatóak.)

"Én attól félek, hogy a nagy hírportálok ezt szépen el fogják hallgatni."

A nagy hírportáloknak mi az érdeke abban, hogy ezt elhallgassák? A nagy hírportálok pénzből élnek. A pénz pedig a látogatottság után jön. Nekik a balhé mindig látogatottságot jelent. Ha ez olyan nagy sztori lenne, akkor írnának róla.

Én nem hiszem azt, hogy a nagy hírportálok (melyekre is gondolsz te itt most?) elhallgatnák ezt. Mondjuk, hogy mi az "ez", az még nekem is rejtély, mert beleolvastam a cikkbe, de olyan nagy szenzációt egyelőre nem látok.

Hunger is vigyázott azért arra, hogy óvatosan fogalmazzon és a biztonságos "úgy tűnik elismeri"-t használta. Most elismeri, vagy csak _úgy tűnik_ elismeri? Én még nem tudom, mert az LWN cikke helyett szeretném elolvasni az eredeti szövegkörnyezeteket. Sajnos az LWN cikke nem linkeli ezeket a beszélgetéseket, csak szövegkörnyezetükből kiragadva idézi, így egy kicsit hosszabb munka lesz, amíg megkeresem és elolvasom az összes párbeszédet.

--
trey @ gépház

"A nagy hírportáloknak mi az érdeke abban, hogy ezt elhallgassák? A nagy hírportálok pénzből élnek. A pénz pedig a látogatottság után jön. Nekik a balhé mindig látogatottságot jelent. Ha ez olyan nagy sztori lenne, akkor írnának róla."

Itt nem "szándékos" elhallgatásra gondoltam, hanem olyanra, hogy pl. jelentéktelennek gondolják, és ezért nem írnak róla.

"(melyekre is gondolsz te itt most?)"

Pl. slashdot. (Oké, nem nagyon ismerek nagy oldalakat, fogalmam sincs ezeken kik a célközönség, simán előfordulhat, hogy ez nekik nem hír. Ez nálam kimeríti az elhallgatás fogalmát, még akkor is, ha nem azért nem írnak róla, mert kellemetlen lenne.)

"Mondjuk, hogy mi az "ez", az még nekem is rejtély, mert beleolvastam a cikkbe, de olyan nagy szenzációt egyelőre nem látok."

Amikor más, nagy cégekről derül ki, hogy úgy próbáltak kiadni egy biztonsági frissítést, hogy elhallgatták annak biztonsági frissítés mivoltát, utána mindig nagy botrányok törtek ki bizonyos körökben. Most Linus ismerte be ugyanezt, és érdekes módon sehol a botrány, te is jelentéktelen kijelentésnek tekinted (egyelőre).

"Hunger is vigyázott azért arra, hogy óvatosan fogalmazzon és a biztonságos "úgy tűnik elismeri"-t használta. Most elismeri, vagy csak _úgy tűnik_ elismeri? Én még nem tudom, mert az LWN cikke helyett szeretném elolvasni az eredeti szövegkörnyezeteket. Sajnos az LWN cikke nem linkeli ezeket a beszélgetéseket, csak szövegkörnyezetükből kiragadva idézi, így egy kicsit hosszabb munka lesz, amíg megkeresem és elolvasom az összes párbeszédet."

Nekem a kiragadott mondatok elég konkrétnak tűnnek, nem hiszem, hogy a szövegkörnyezet sokat változtatna a mondanivalójukon. De igazad van, én nem jártam jobban utána, és mivel szubjektív vagyok, ezért előfordulhat, hogy én nem azt olvasom ki a mondatokból, amit Linus eredetileg gondolt. De ezt nem tartom valószínűnek.

Ott hibádzik a párhuzam, hogy a commit != release. Amire az a javítás eljut a felhasználók _tömegéhez_, addig _legjobb esetben is_ hosszú napok telnek el, mert idő amíg a disztribútorok át tudják venni. A zárt forráskód itt másképp működik - kb akkor lehetne párhuzamot vonni, ha a zárt forráskódú szoftver gyártója az előtt publikálná részletesen a sebezhetőséget, mielőtt kiadja a javítást.

A kiragadott mondatok lótúró. Óriási a különbség a között, hogy pár napig titkolja el vagy megpróbálja örökre - erről pedig nem tudtunk meg semmit.

> Most Linus ismerte be ugyanezt, és érdekes módon sehol a botrány, te is jelentéktelen kijelentésnek tekinted (egyelőre).

Az ellentmondásokban az a jó, hogy a felismerésük alkalmat ad az elgondolkodásra és helyes következtetés levonására.

Tehát: ellenmondást érzékeltél, és ebből arra következtetsz, hogy ...

"Nekem a kiragadott mondatok elég konkrétnak tűnnek, nem hiszem, hogy a szövegkörnyezet sokat változtatna a mondanivalójukon. De igazad van, én nem jártam jobban utána, és mivel szubjektív vagyok, ezért előfordulhat, hogy én nem azt olvasom ki a mondatokból, amit Linus eredetileg gondolt. De ezt nem tartom valószínűnek."

Nekem 10 éve az az elvem, hogy a lehető legközelebbi forrásra hivatkozok azután, hogy valóban elolvastam és legjobb tudomásom szerint meg is értettem azt, amiről szó van. Az LWN-es cikket nem corbet - aki szerintem hiteles, bár volt már, hogy ő is hibázott (hiszen ember) - írta, ráadásul született néhány komment a cikk alatt, ami nekem elég ahhoz, hogy majd azután üssek össze egy cikket, ha elolvastam mi is történt valójában. Ez nem jelenti azt, hogy az LWN-es cikk valótlant állítana, hanem azt jelenti, hogy alapos szoktam lenni. Szóval ha megengeded, előbb majd utánanézek, hogy mi is ez a história.

--
trey @ gépház

A probléma az, hogy az eloszlása a hibáknak nem egyenletes. Aztán ha 1 hónapig minden nap hatalmas javításokat csinálsz, annak hírértéke van.

"Ebben a hónapban Linus a 30. hatalmas hibát javítja és még nincs hóvége..."

Néha jobb kussolni. Ha nem látod, nem idegeskedsz feleslegesen. Ha egy nap 3 egyest kaptam én is csak elosztva vallottam be.

Volt már olyan ügyfeled, aki a legapróbb hiba bejelentése után ugrálni kezd és másodpercenként telefonál?

- mikor lesz javítás?
- mik a következményei a hibának?
- miért nem ellenőrizted le?
- mi garantálja, hogy legközelebb nem fordul majd elő?
...

Utána a főnöke is felhív és ugyanezeket megkérdezi, meg az ő főnöke is. :)

Tudod a tapasztalatok alapján nem minden ügyfélnél jó, ha mindent tud. Vannak, akiknél kussolni kell.

Azt ugye könnyű belátni, hogy ha a commit message minden esetben tartalmazza, hogy "ez egy baszott nagy sechole fixe", akkor lesz egy időablak amíg a felhasználók védtelenek, ami nyilván nem lehet a jó megoldás a felhasználók szemszögéből. Néha ez persze elkerülhetetlen, de szándékosan nem kell gerjeszteni, szerintem.

Linus az arany középutat keresi ami az átlagos felhasználók érdeke.

Ha viszont tényleg javítanak úgy hibákat, hogy azt soha nem jelzik kifelé, az már necces és már azt se lehet ráfogni, hogy a felhasználó érdeke; épp ezért vagyok szkeptikus azzal kapcsolatban, hogy ezt megteszik.

Szerencsére ez egy olyan dolog, amire nagyon könnyű konkrétumot szolgáltatni -ha valóban így történik-, a tényekkel pedig nehéz vitatkozni, szóval lássunk pár példát arról, hogy miket javítottak amikhez aztán csak hónapokkal később lett CVE. so?

Mindenkinek kulonbozik a humorerzeke. Van, amin en nevetek, trey szerint meg nem vicces. Van, ami mellett en siman elmennek, de mas ajanlja. Ezeket az ajanlasokat be szoktam tenni, mert ha masnak tetszik, lehet, hogy csak en nem tudok rajta nevetni.

--
The Wikipedia blackout is over. At last we can now find out what SOPA is.

> ha a commit message minden esetben tartalmazza, hogy "ez egy baszott nagy sechole fixe", akkor lesz egy időablak amíg a felhasználók védtelenek

szemmel lathatolag ez rohadtul nem mukodott ennel a javitasnal (meg maskor se), napokon belul fel tucat exploit irodott legalabb, mielott a disztrok ki tudtak volna jonni a javitasokkal. aztan mi van az olyan dolgokkal, mint http://seclists.org/fulldisclosure/2010/Sep/268 (ismered a 0-day fogalmat remelem ;)?

> Ha viszont tényleg javítanak úgy hibákat, hogy azt soha nem jelzik kifelé

pontosan ezt a filozofiat koveti Linus meg a tobbi kernel fejleszto. olvasd el az LWN-es cikket meg par regebbi flamewart ezzel kapcsolatban az lkml-en.

"Néha ez persze elkerülhetetlen".

Igazából annyira nem foglalkoztat a kérdés, hogy sokat olvasgassak utána, tényleg csak egy-két ilyen iskolapélda érdekelne, hogy "tessék gyerekek, itt volt ez a sunyi commit, majd rá fél évre jött messziről egy szemfüles bácsi aki felfedezte, hogy a commit előtt vót ottan egy csúfos biztonsági probléma; GOTCHA!"

Minek vitatkozni arról hogy mennyi 2+2 ha ki is lehet számolni.

A fenti példánál ugye 8 nap telt el a sunyi commit és a leleplezés között ami még nem győzött még, még rá lehet fogni, hogy publikálni akarták amint kipörgött a sunyi patch a fő disztrókba, sunyin.
Ha ilyenből van egy olyan, ahol eltelt 2-3 hónap, az már egyértelmű lenne - azt nem mondom, hogy annyira meglepődnék, de elkussolnék. :)

ize, nem igazan vilagos mit varsz el. ennel a /proc/pid/mem hibanal pontosan azt csinalta Linus, amit mar annyiszor elotte: ugy javitotta ki a privatban bejelentett biztonsagi hibat (exploit is volt hozza mellekelve, tehat ketseg nem fert a hiba jelentosegehez), hogy a commit uzenetbol lehetoleg semmi se utaljon arra, hogy ez bizony sulyos biztonsagi hiba. nem veletlenul tortent ez, hanem szandekosan, ezt mar nyilvanosan is nem egyszer beismerte, hogy nala bizony igy mukodnek a dolgok. az adott esetben azonban nagyobbat is borult a bili, mivel a szokasoktol elteroen nem ertesitettek a zart linux-distros listat (vendor-sec utodja a tavalyi feltores utan). az egyetlen nyom, ami a hiba jellegere utalt, az a CVE azonosito keres volt a publikus oss-sec listan (ill. nem sokkal utana a Red Hat bugzillaban is lett rola bejegyzes, l. a timeline-t az LWN-es hozzaszolasomban). mivel en is meg spender is azonnal kiszurtuk ezt a commit-ot, par nappal kesobb rakerdeztunk Kees Cook-nal, hogy megis mi az abra (o Ubuntu security contact volt, azota meg ChromeOS security-t csinal). na ez inditotta el az igazi lavinat, mert mint utolag kiderult, egy arva ganyi kukkot nem szolt senki a distro-knak, es Kees szerint ez igy is maradt volna, ha o nem kerdez ra (amit meg ugye en inditottam el valahol). tehat ha en nem pattogok a mult heten, akkor most jo esellyel nagyon sok linux felhasznalo meg mindig csak pislogna, hogy hirtelen mitol lett zombie a szerverebol (androidosoknak meg eggyel kevesebb rootolasi lehetoseguk lenne, az erem ket oldala ugyebar ;).

amugy volt pelda 2-3 honapos csuszasra is. 2003 szeptembereben javitottak az azota do_brk neven elhiresult hibat, amit maga Andrew Morton minositett biztonsagi hibanak, de teljesen eltussoltak (igen, nem mai ez a problema). ennek a vege az lett, hogy kb. senki sem backportolta a javitast. aztan jott november es a debian fo szerverein egy hibasan mukodo rootkitet talaltak (nem volt smp-re jol megirva, azert buktak le), es utana megtalaltak es visszafejtettek a helyi privilegium szintet emelo exploitot is. talald ki, melyik hibat hasznalta ki ;).

nem ertesitettek a zart linux-distros listat (vendor-sec utodja a tavalyi feltores utan)

Ha jól értem, ebben van egy olyan állítás, hogy a vendor-sec elavult lista, szerepét átvette a linux-distros. (Nem tudok a háttérről semmit, csak megpróbálom kiemelni, ami fontos lehet a hozzászólásomban.)

az egyetlen nyom, ami a hiba jellegere utalt, az a CVE azonosito keres volt a publikus oss-sec listan

Ezt az állítást nem cáfolja ez a hozzászólás? (Nem, nem a "tagadja" szót akarom használni, valóban cáfolatra gondolok; aki fel van iratkozva a vendor-sec-re, az ellenőrizheti.) Reagáltál ott is:

you're saying that something else happened between 2 and 3 on linux-distros?

A fentiek szerint valóban történhetett valami a (2) és a (3) között, csak nem az "új" linux-distros listán, hanem a "régi" vendor-sec listán.

evidence wants to be seen

A vendor-sec lista zárt (gondolom legalábbis az olvasottak alapján), úgyhogy publikus linket senki sem tud adni, ha (már) nem vagy feliratkozva.

i'm also wondering how Eugene had gotten wind of the security related impact of the commit before anyone else did

Nem lehetetlen, hogy hozzátok hasonlóan Eugene vagy egy kollégája kiszúrta. Az is elképzelhető (mondom teljesen látatlanban, spekulációként), hogy az eredeti bejelentő Fedora-t vagy RHEL-t használt, és szólt külön.

> Ha jól értem, ebben van egy olyan állítás, hogy a vendor-sec elavult lista, szerepét átvette a linux-distros.

pontosan, azzal kiegeszitve, hogy nem 'elavult', hanem siman megszunt letezni, miutan a hosztolo gepet feltortek tavaly es a regi adminok nem akartak ujrakezdeni. szerintem tuti volt rola itt is hir.

> Ezt az állítást nem cáfolja ez a hozzászólás?

cafolni cafolna, ha igaz lenne ;). direkt azert szedtem ossze a timeline-t es kerdeztem ra, hogy mi hibadzik. nem veletlen, hogy nincs ra valasz, sot azt is tudom (es tudtam mar elotte is), hogy nem is lesz ra valasz, mivel Kurt baratunk nagyon ocsmany modon behazudott egy nagyot.

> hanem a "régi" vendor-sec listán.

ilyen allat mar nincs ;). es megegyszer mondom, nem tortent semmi mas a vendorok iranyaban, ma direkt rakerdeztem Kees-nel erre, hogy ha en mult heten nem hivom fel a figyelmet erre a commit-ra/CVE-re, akkor vajon mikor ertesitettek volna a vendorokat. idezem a valaszat:

kees: when it was too late
kees: it would have just been the CVE request
kees: and eventually distros would have picked it up
kees: I'm extremely glad you guys called it to my attention

> A vendor-sec lista zárt (gondolom legalábbis az olvasottak alapján),
> úgyhogy publikus linket senki sem tud adni, ha (már) nem vagy feliratkozva.

linux-distros-ra atforditva (mivel vendor-sec nincs), valoban a lista zart, viszont semmibe nem kerul kijelentenie, hogy ki mikor es mit irt be, en utana le tudom ellenorizni (megkerdezem Kees-t, akiben Kurt-tal ellentetben megbizok). de mint mondtam, a linux-distros-ra *semmi* nem ment, azutan kezdtek el rola beszelgetni, hogy Kees kiverte a balhet. a timeline-bol az is vilagos, hogy a Red Hat alkalmazottak kepesek voltak a sajat hazuk tajan aznap reagalni, tehat semmi racionalis magyarazat nincs ra, hogy miert vartak a tobbiek ertesitesevel.

> Nem lehetetlen, hogy hozzátok hasonlóan Eugene vagy egy kollégája kiszúrta.

persze, hogy nem lehetetlen (bar ismerve az ott dolgozok eddig demonstralt kepessegeit ezt erosen ketlem), csak en kivancsi vagyok ra, hogy Eugene is a kernel security listarol kapta-e az informaciot, vagy sem. mert az elobbi esetben meg cifrabb lenne a dolog, hiszen olyan informaciobol kovacsolt elonyt a Red Hat-nek, amihez a tobbieknek szemmel lathatoan nem volt hozzaferesuk. szoval van itt egy par potencialisan csunya dolog a hatterben, kivancsi vagyok, mi fog kiderulni belole.

> Az is elképzelhető (mondom teljesen látatlanban, spekulációként),
> hogy az eredeti bejelentő Fedora-t vagy RHEL-t használt, és szólt külön.

az eredeti bejelentes a kernel security listara ment, nem vendornak.

Eugene is a kernel security listarol kapta-e az informaciot, vagy sem. mert az elobbi esetben meg cifrabb lenne a dolog, hiszen olyan informaciobol kovacsolt elonyt a Red Hat-nek, amihez a tobbieknek szemmel lathatoan nem volt hozzaferesuk

Mindkét esetben szerintem... Akár úgy, hogy Eugene fenn van a kernelsec listán közvetlenül (anélkül hogy kerneldev lenne), akár úgy, hogy egy kerneldev kollégája van fenn és az továbbította neki a levelet házon belül.

Nyilvánvalóan valaki visszaélt a pozíciójával, ezért tudott a Fedora _sokkal_ előbb kijönni a frissítésekkel, mint bármelyik másik disztribúció. Linus pedig közvetetten ennek a disztribúciónak kedvezett azzal, hogy ráadásul megpróbálta eltitkolni a többi disztribúció elől a hiba javításának biztonsági vonzatát.

Fedorára a foltozott kernel fordítása Mon, 23 Jan 2012 17:26:20 UTC-kor fejeződött be. Ezt megelőzően a hiba hónapokig szabad lábon volt. Nem tudom, a többi disztribúcióba mikor érkeztek a javítások, de gyanítom, nem sokkal később. A vanillába január 17-én commitolták, s a 3.2.2-es január 26-án lett kiadva. Persze értem, hogy 3 nap sok, ha ismertté, nyilvánossá válik egy hiba. Nem tudom, a többi disztribúcióhoz mikor érkezett a javítás. Azért a Fedora javításához is csak a szemfülesek férnek hozzá hamar - aki lesi a buid szervert, mint én -, a hivatalos update repókban minimum még néhány óra a megjelenés.

Az eljárás elvileg nem korrekt, az okot sem igazán értem, ugyanakkor nem voltak sokáig védtelenek a Fedorán kívüli disztribúciók sem.

tr [:lower:] [:upper:] <<<locsemege
LOCSEMEGE

Meglehet - helyesebben szólva látom -, de a Fedora 17 fejlesztés alatt - tehát nem létezik -, szóval gyakorlati jelentősége csak a Fedora 16, Fedora 15 kerneleknek van, hiszen ez a kettő aktív, úgy értem, támogatott release.

tr [:lower:] [:upper:] <<<locsemege
LOCSEMEGE

Irreleváns, hogy mikor lett a kernel fordítva, a legtöbb disztribúciónak erre külön bejáratott ütemterve van, amely sok tényezőtől függ... Ami számít jelen esetben az az, hogy a hiba javítását mikor emelték be a forrásfájukba és az Fedoránál korábban volt (Wed, 18 Jan 2012 15:08:53 +0000 (10:08 -0500)), mint a többi disztribúciónál és korábban volt, mint Kees Cook levele a linux-distros listára, sőt, mint Kees Cook levele az oss-sec-re (lásd PaXTeam által összeállított timeline az LWN-en), amelyben egyáltalán rákérdezett, hogy mi a probléma. Addig nem is lehetett tudni, hogy kritikus, privilégium emelésre alkalmas biztonsági hibáról van szó, ergó a többi disztribúció nem is nagyon kezdett el vele addig foglalkozni. Fedoránál akkor már benn volt a fix.

Most nézem, azért Fedoránál is sunnyogtak. Ez van a changelog-ban:

* Mon Jan 23 13:00:00 2012 Josh Boyer 3.2.1-3
- Fix oops in iwlwifi/iwlagn driver (rhbz 766071)
- Fix NULL pointer dereference in sym53c8xx module (rhbz 781625)

* Fri Jan 20 13:00:00 2012 Dave Jones
- net: reintroduce missing rcu_assign_pointer() calls

* Fri Jan 20 13:00:00 2012 Josh Boyer
- Add mac80211 deauth fix pointed out by Stanislaw Gruszka

Aztán van egy ilyen patch, direkt ezért letöltöttem ezt a kernel forrást:

proc-clean-up-and-fix-proc-pid-mem-handling.patch

Aztán innen kiderül, ez a változat már valóban javítja a hibát.

Ejnye, no!

tr [:lower:] [:upper:] <<<locsemege
LOCSEMEGE

Köszi, hogy összefoglalod a történéseket. A magamfajtának, akik nem vagyunk ennyire otthon a kernel security témában, így lesz kerek és érthető az egész. A sztori érdekes, jó belátni a színfalak mögé.

Az egy tény, hogy a kernel fejlesztők időnként álcázzák a hibajavításokat, elismerem. Ahogy Linus is írta: van, aki ezt elítéli, de speciel én, mint felhasználó, bizonyos cél érdekében ezt el tudom fogadni, akár helyeslem is.

I.,
Ami számomra elfogadhatatlan eljárás az az, hogy a biztonsági hibajavítások hosszú idő után sem kapnak CVE-t. Itt ugye erről nincs szó, hiszen CVE-t kértek rá azok, akiknek (állítólag) lehetőségük lett volna tovább titkolni a dolgot - nyilvánvalóan ez nem volt céljuk.

A 2003-as do_brk esetben -ha jól értem- a 2.4.23-as kernelbe jött egy sunyi javítás. A disztókészítők és a nagyvilág erről láthatóan nem lett értesítve. Viszont itt is muszáj kérdeznem: nem csak azért nem lettek értesítve, mert a javító nem gondolta, hogy biztonsági rést javít? Ez persze szakmai hiba lenne, de hibát mindenki ejthet. Véleményed szerint kizárt, hogy csak erről van szó?

II.,
Én mint felhasználó, akkor tudom elfogadni a hibajavítások átmeneti álcázását (a kernel repoban és a disztrók changelogjában), ha közben a disztróm ezerrel dolgozik azon, hogy mire kijön a CVE, elérhető legyen a javítás is.

Ha Kurt tényleg hazudott -ahogy Kees és te állítod- azaz valójában csak a RedHat lett értesítve a hibáról és a javításról, az elég nagy disznóság. Azt elfogadom, hogy csak egy egész szűk kör lehet jelen egy efféle fórumon (másképp több lenne a blackhat mint a disztrók küldöttje), de hogy legalább egy Debian, SUSE, Ubuntu küldött ne értesüljön - az nincs rendben.

Ebben az esetben azonban a fenti disztróknak kéne kiverni a balhét, de miért nem teszik? Egy SUSE Enterpriset nem zavar az, hogy emiatt -vagy az ehhez hasonló eljárás miatt- komoly üzleti hátrányba került/kerülhet? Szóval nem lehet, hogy mégis eljutott hozzájuk valami számunkra láthatatlan csatornán az infó..? - Ja, ezt persze nem tőled kéne kérdeznem, de kompetensebb embert nem tudok.
Azt tudom, hogy Keeshez nem jutott el semmi - de a ChromeOS jelenleg egy jelentéktelen Linux. Rá lehet mondani, hogy emiatt "így járt".

PaXTeam, azt azért lásd, hogy igazából nem vitatkozni akarod veled hanem tanulni tőled, viszont ehhez fel kell tennem ilyen kötözködő/dilettáns kérdéseket is. Jogodban áll ignorálni.

(Az LWN cikket még nem látom, bocs.)

1. az a baj CVE keressel, hogy Linus ezt a reszet is nagy ivben leszarja. egyreszt gyakran meg se varja, hogy a bug kapjon egyet (eleve nem is ertesiti azokat, akik CVE-t osztanak ki), masreszt ha megis idoben (commit elott) lesz CVE, akkor tojik ezt beletenni a commit uzenetbe. mindezt ugye azon 'nemes cel' erdekeben, hogy nehogy mar a rossz fiuk elonyt kapjanak exploit irashoz. na ehhez kepest en hamarabb kiszurtam, hogy vmi gazos ezzel a commit-tal, mint ahogy Eugene CVE-t kert es kapott ra. szerinted akkor az erre specializalodott cegek/emberek, akik 24 oraban kepesek ezeket a dolgokat monitorozni, hol alltak? megmondom: szettortek mindent, ahol addig csak sima user jogaik voltak. akkor meg Linus megis mi a francot ert el ezzel a fene nagy titkolozassal? nem beszelve arrol, hogy a disztroknak igy is sok napba tellett frissiteni (es akkor az meg semmit sem er, ha a felhasznalok nem azonnal frissitenek), mikozben amatorok is kepesek voltak egesz jol mukodo exploitokat produkalni. es ez az eset meg a jobbik fajtabol valo volt, maskor csak a profik szurjak ki a commit valodi biztonsagi vonatkozasait, az amatorok (beleertve a distrok embereit is) nem. ilyenkor sokszorosan visszaut a titkolozas (volt mar pelda, hogy pl. 'buffer overflow' helyett az volt a commit-ban, hogy 'copying overly long strings' vagy valami hasonlo, maskor meg ment a rizsa, hogy az adott hiba mennyire nem jo masra, csak DoS, stb).

2. a 2003-as do_brk-rol alljon itt minden kommentar nelkul egy szosszenet a nehai vendor-sec listarol (2003.09.25):

<arja> there's a security hole found by akpm
<arjan> that also hits your kernels
<arjan> Subject: [PATCH] do_brk() bounds checking
<arjan> that patch you want
<arjan> agreement is to put it in silently (eg no changelog)
<davej> ok
<arjan> it's not exactly public stuff either
<arjan> linus committed it with a non-security comment
<arjan> so should we
<davej> ok

3. az atmeneti alcazas a fentiek miatt ertelmetlen dolog. ha ennyire fontos a disztro felhasznalok vedelme, akkor arra a megoldas a disztrok kozotti koordinalas, az embargo. errol meg ugye Linus kifejtette a velemenyet parszor mar, google segiteni fog (negybetus szavak suru hasznalata szokta kiserni, ha esetleg nem vilagos, mire akarok utalni).

4. Kurt tovabbra sem valaszol (nem meglepo mondjuk), es igen, a linux-distros lista van erre a koordinaciora kitalalva (ahova jo par disztro delegalt tagot, Kees is rajta van az Ubuntus kora ota), es pont ezt a listat 'felejtettek el' idoben ertesiteni. ez nem velemeny kerdese, ez tortent (persze nem kell nyilvan nekem elhinni, irhat mindenki nyugodtan a sajat disztrojanal felelos embereknek es rakerdezhet). balhe annyi volt belole a listan, hogy mindenkinek rohamtempoban kellett dolgoznia a backportokon, hiszen jobbra-balra szulettek a mukodo exploitok.

5. LWN cikket mar napok ota elolvashattad volna, mivel Hunger feljebb mar reg belinkelte.

"A probléma a gondolatmenetével az, hogy azt feltételezi a disztribúció készítők és karbantartók okosabbak a blackhateknél".
ezért sem mindegy melyik disztribúciót és mire használsz:) de az tény, csodák valóban nincsenek;)