[Frissítve] Kritikus Linux desktop biztonsági problémára figyelmeztet az Invisible Things Lab

 ( trey | 2010. augusztus 18., szerda - 7:59 )

Joanna Rutkowska, a Invisible Things Lab vezetője tegnap egy blogbejegyzést írt "Rejtett csontvázak a Linux szekrényében: a Linux desktop-od r00tolása profitért és a mulatság kedvéért" címmel. A blogbejegyzésben Joanna arról ír, hogy kollégája, Rafal Wojtczuk, miközben a Qubes-on (1, 2) dolgozott, egy érdekes, Linux-on privilégium-szint emelést lehetővé tevő támadással állt elő. Joanna szerint sikeres exploitálás esetén a támadás a felhasználót root jogokhoz juttatja.

Joanna Rutkowska

A támadás lehetővé teszi az X szerverhez hozzáférő, privilégiumok nélküli felhasználói processz számára, hogy az feltétel nélkül root szintre emelkedjen. Ráadásul úgy, hogy eközben gyakorlatilag semmilyen konkrét X szerver bugot sem használ ki.
Más szóval, ha bármely GUI-s alkalmazást (pl. egy sandbox-ba zárt PDF olvasót) sikeresen megtörnek, akkor az összes Linux-ba épített biztonsági mechanizmus megkerülhetővé válik és root jogokhoz juthat a támadó. Rutkowska szerint a támadás lehetősége évek óta jelen lehet, erősen valószínű, hogy azóta, hogy a 2.6-os kernel bemutatkozott.

A támadás pontos leírása elolvasható Rafal dokumentumában.

Joanna szerint a Qubes (1, 2) architektúra megtervezésekor az elsődleges szempontok egyike pont az ilyen támadások lehetőségének kiküszöbölése volt. Véleményük szerint a Qubes sokkal biztonságosabb a sandboxing mechanizmusoknál, mint a BSD jail vagy a SELinux-alapú sandbox megoldások).

A kernelproblémára Linus augusztus 13-án elkészítette a javítást. A Red Hat figyelmeztetőt adott ki, amelyben "high"-ra értékelte a hiba súlyosságát.

Brad Spengler úgy tűnik, hogy exploitot írt a problémára.

A blogbejegyzés itt olvasható.

Frissítés: A blogbejegyzés hozzászólásai közt Brad Spengler utal arra, hogy Linus elszabta a javítást, így a javításra a következő "stable" kiadásig várni kell, vagy git-ből ki kell szedni az adott commit-eket. A hozzászólásokban Spengler látszólag megkérdőjelezi az Invisible Things Lab fejlesztéseinek hasznosságát is.

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

+komment spengler úr kódjában

Ha úgy van, ahogy írja, akkor szégyen ez a fejlesztőkre. Ha Ted Ts'o nem adta tovább a hibajelzést, akkor rá pedig kiváltképp.

--
trey @ gépház

Reménykedik hogy ha megint nem javít hibákat majd jót tesz vele (lásd ext3 ami hiba miatt lett "használható" fs).

+spengler úr kommentje a hivatkozott blogban

Most akkor 2x-esen szégyen rájuk. Vagy 4x-esen.

--
trey @ gépház

Lesz ez még durvább is megérzésem szerint. Főleg ha figyelembe veszem Linus security-hez való viszonyát.. Én mindenesetre készítem a pop-corn-t..
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Továbbra sem a kernel hibákban látom a legfőbb problémát. Desktop-on sokkal jobban aggasztanak engem az alkalmazások biztonsági hibái. Azokkal kellene valamit kezdeni. Leszarom ha root lesz a gépemen valaki, ha már minden adatomhoz hozzáfért egy böngésző bugon keresztül. Ez az egész szoftverfejlesztés a mai színvonalon, fejlettségi fokon egy vicc. Az egészről a toldozás-foltozás és a barkácsolás jut eszembe.

--
trey @ gépház

Azért vegyük külön a szerver és a desktop alkalmazást pls. Desktopon valóban igazad van, mert ott a root csak az alap adminisztrációs tevékenységekhez kell, amúgy meg nem használod, így szinte minden személyes cuccod a saját userID-d birtokában van, ergo persze hogy az azonos privilégiummal futó app simán hozzáfér az adatokhoz.

Egyedül akkor okoz ez neked problémát, ha a gépen több user is van, mert akkor egy ilyen (akár böngészőn keresztül indított ) exploiton keresztül aztán hozzáfér a támadó mindenhez ( az összes user személyi adatához, ami több useres gép esetén viccesebb )

Szerver esetén viszont a dolgok kicsit másként mennek - A manapság elterjedt támadási vektorok nem játszanak, vagy ha még is annyi esze volt az adminnak, hogy felrakott egy X-et, meg mondjuk egy firefox-ot a szerverre, akkor se fogja tudni kompromittálni a szervert egy általad említett hiba esetén, mivel minden fontos a root-nál van, vagy más applikációs userID alatt.. Egy ilyen hiba esetén viszont az egész mindenség nyitva áll a támadó előtt, szóval ott az ilyen fajta támadások különösen veszélyesek tudnak lenni.

Amúgy már párszor elmondtam, de ahogy nézem még mindig áll az, hogy amíg Linus nem figyel oda normálisabban a security-re, addig hiába "bazár elv", meg "open source", meg "több szem többet lát" - xart se fog érni, pont azért mert akinek van is annyi tudása, hogy átlássa és meg is értse a kódot, plusz tudja hogy mit érdemes auditálni az általában az ilyen kis finom hibákat meg is tartja magának, és csak a ritkább esetekben teszik közkincsé (Csak nézd meg azt, hogy ezt a hibát mikor fedezték fel). Innentől a többi ember meg max bugfixeket ír funkcionális hibákra, oszt csókolom: a normális auditing és programozási irányelvek nélkül az egész "Linux security nevű moslékot" le lehet húzni a WC-n.

Mondjuk egy dolgot még hozzá kell tegyek a teljes körképhez: Azoknál a szervereknél, ahol tényleg fontos is, hogy valami security szerűség is legyen, ott nem vanilla kernelt futtatnak, hanem agyon-security-patchelt kernelt, bár ez se garantál egyáltalán teljes biztonsági szintet.
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

"Azoknál a szervereknél, ahol tényleg fontos is, hogy valami security szerűség is legyen, ott nem vanilla kernelt futtatnak, hanem agyon-security-patchelt kernelt, bár ez se garantál egyáltalán teljes biztonsági szintet."

Enterspajz kornyezetben ez not supported, de ha az lenne, lehet, hogy megnehezitene adott szoftver uzemelteteset, vagy lehetetlenne is tenne.

Nézd majd meg egy Redhat Enterprise server kerneljét... Az már by default agyon van patchelve..
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Sorry, dupla post..
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Nem azt írtam, hogy nem tartom problémának, hanem azt, hogy nem ezt tartom a legfontosabb problémának. Ég és föld a különbség a kettő közt.

"Azért vegyük külön a szerver és a desktop alkalmazást pls."

Természetesen különvettem. Ezért kezdtem úgy, hogy "Desktop-on sokkal jobban ..."

--
trey @ gépház

Jogos.. Ezen valahogy átsikolottam.. Viszont ha csak ennyi bajod van akkor egy apparmor bőven elég neked az adatok védelmére :)
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Mármint kikre?

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

Kedvelem ezt a Brad-gyereket. Nem fél kihúzni a dugót a f*startályból, pedig rá is fröcsög belőle utána. :))

--
Wir sind erfaßt, sind infiziert,
Jedes Gespräch wird kontrolliert.

Csak verik a port...

Azert jo latni, hogy a BOSS( Linus :P) , figyel es kodol, ha szukseges :P

Made my day. :)

"(...)they make such a big deal about concentrating on security(...)"
- Linus

dpkg --remove *

jujj, ez a nicknév... déja vu
--
Dropbox tárhely igénylés: https://www.dropbox.com/referrals/NTMwMDYwODE5

EPIC


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Ha jól látom a bug csak a 32/64 bites multilib-es rendszereket érinti?
-------------------------------------------------------------------------------
Az életben csak egy dolog a szép, de az épp nem jut eszembe.

Slackware Linux 13.1 | 2.6.34.1-janos

nem

Az exploitban ez áll:

/* known for over a year, fixed in grsec
   bug is due to a bad limit on the max size of the stack for 32bit apps
   on a 64bit OS.   Instead of them being limited to 1/4th of a 32bit 
   address space, they're limited to 1/4th of a 64bit address space -- oops!
   ...
*/

Értelmezésem szerint tisztán 32 és 64 bites rendszereknél a fent leírt dolog nem jöhet elő.
-------------------------------------------------------------------------------
Az életben csak egy dolog a szép, de az épp nem jut eszembe.

Slackware Linux 13.1 | 2.6.34.1-janos


[csuhi@csuhainote temp]$ gcc 64bit_dos.c -o 64bit_dos
[csuhi@csuhainote temp]$ ./64bit_dos
execve failed
[csuhi@csuhainote temp]$ uname -r
2.6.33.6-147.2.4.fc13.x86_64
[csuhi@csuhainote temp]$ cat /etc/redhat-release
Fedora release 13 (Goddard)

Elrontottam valamit, vagy ilyen sz@r ez a linux hogy má rendes exploitot se bírnak rá írni? ;)

--
http://csuhai.hu
http://sys-admin.hu

Nálam se megy:

aron@deb-aron:/tmp$ gcc 64bit_dos.c 
aron@deb-aron:/tmp$ ./a.out 
execve failed
aron@deb-aron:/tmp$ uname -a
Linux deb-aron 2.6.32-5-amd64 #1 SMP Sat Jul 24 01:47:24 UTC 2010 x86_64 GNU/Linux
aron@deb-aron:/tmp$ cat /etc/debian_version
squeeze/sid
aron@deb-aron:/tmp$ 

+1

ulimit -s unlimited után sem működik az exploit.

ulimit -s unlimited
./64bit_dos

Így próbáld.

Nem csinál semmit csak megtekeri a CPU-t, megeszik pár GB memóriát és hihány 262156 db A betűt az stderr-re.
Ugyanúgy korlátozott user maradtam.

# uname -a
Linux gaia2 2.6.32-24-server #39-Ubuntu SMP Wed Jul 28 06:21:40 UTC 2010 x86_64 GNU/Linux
--
\\-- blog --//

És szerinted mit kellene csinálnia? Nyilván nem fognak olyan exploitot kiadni, amit Pistike is használhat módosítás nélkül apuci szerverén. :)

Szóval ide kattints: http://dawn.royalcomp.hu/~raas/lc.html

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

a proof of concept-nek nem ez a lényege? :)

sikeresen futtattam az exploit-ot amúgy sysresccd 1.5.5-ös live CD-vel, 2.6.32.14-std155-i386 kernel-lel.

ulimit -s unlimited
adduser guest
su guest
gcc *.c
./a.out

a végén ott figyelt a root prompt. gondolom hogy sikeres lehet, mert nem dobta az 'A' karaktereket stderr-re.

kieg.: ugyanez arch-on nem működött.

szerk.: azt hiszem, hogy csak a dos működhetett és az miatt omolhat össze az adott shell session a guest user-rel, és ezért kaphatom vissza a root login-t sysresccd alatt. számomra továbbra is nyitott a kérdés a privilégium szint emelés lehetőségének ellenőrzésére. a fenti kód csak a dos szemléltetésére elegendő ezek szerint?

értelmezésem szerint az "execv("/bin/sh", args);" hívással egy újabb shell-t nyitna, és innét már nem térne vissza a printf-re. csakhogy ez nem jön össze.

mivel ez egy DoS...

Ha nem menne, akkor valami ilyesmit írna ki:

janos@virtual-void:~$/e.bin
execve failed
janos@virtual-void:~$ uname -a
Linux virtual-void 2.6.32-24-generic #39-Ubuntu SMP Wed Jul 28 06:07:29 UTC 2010 i686 GNU/Linux
janos@virtual-void:~$

Mondjuk fura, hogy kiírja az A-betűket, mert ha a /bin/sh-nak adjuk paraméterként a sok A-t, hibaüzenetet is kellene látnod, hogy nem tudja megnyitni "A...A"-t.
Minden esetre, ha kiírja neked az A betűket, akkor sebezhető a géped.

-------------------------------------------------------------------------------
Az életben csak egy dolog a szép, de az épp nem jut eszembe.

Slackware Linux 13.1 | 2.6.34.1-janos

Köszönöm a korrekt választ.

dap írta:
mivel ez egy DoS...

valóban, valamiért ott ragadtam le, hogy 'privileg escalation'...
lásd anno: jessica_biel_naked_in_my_bed.c
--
\\-- blog --//

"bug is due to a bad limit on the max size of the stack for 32bit apps on a 64bit OS."

Szóval fordítsd le 32 bitre.

Erre próbáltam reflektálni másutt, hogy 32 bites OS-en 32 bites programként nem kellene működnie, valamint olyan 64 bites gépen sem, ahol nincs 32 bites programok futtatására mód, mert nincsenek feltelepítve a 32 bites lib-ek.
Persze lehet, hogy más is meghúzódik a háttérben.
-------------------------------------------------------------------------------
Az életben csak egy dolog a szép, de az épp nem jut eszembe.

Slackware Linux 13.1 | 2.6.34.1-janos

Elolvastam.

Leirom zanzaban.

Van egy regota letezo problema a linux kernel gondolkodasmodjaban. Ez alig zavart valakit, hiszen leginkabb alkalmazas eleses lehet belole, nem feltores. A hibaval csak olyan alkalmazas felett lehet atvenni a hatalmat, ami eleg nagy mertekig ugy is a tamado kontrollja alatt van.

Azonban a legtobb mai disztribucioban az X (a grafikat ado komponens) root-kent, teljes privilegizalt modban fut. Az X eleg bonyolult ahoz, hogy a felhasznalo igen nagy kontrolt kapjon hozza. A fenti kernel koncepciohiba es az X szokasos root futtatasa egyutt kombinalva egy szinte minden disztribucioban mukodo user -> root jogosultsagszint novelest tesz lehetove a tamado szamara.

A hiba x86_32 architekturan probalva, kiaknazhato.
A hiba x86_64 architekturan probalva, kiaknazhato.
Mas architekturan varhatoan kiaknazhato (nem probalva).

A kernel koncepciohiba reszletesebb leirasa
A programok tobb adatteruletet hasznalhatnak adataik tarolasara, az egyik neve stack. (azonkivul heap, shm) A stack felulrol lefele novekszik. A kernel koncepciohibaja az, hogy lehetseges egy olyan shared memory szegmenst allokalni, amibe bele tud noni (felulrol) a stack. Amennyiben a ket adatterulet osszeer, ugy lehetoseg van a shared memory szegmensen keresztul modositani a stack tartalmat. A stack tartalmanak megfelelo modositasaval tetszoleges kod futtathato az adott program kornyezeteben.
Mi kell hozza? Egy program, ami elegge kezbentarthato (shared memory letrehozasra kell kenyszeriteni, valamint a stack hasznalatat is ki kell kenyszeriteni)
Mit ad: programfuttatast a fenti tulajdonsagu program kornyezeteben

A hiba kihasznalasa az X segitsegevel
Az X egy nagyon bonyolult rendszer. Lehetoseget ad a felhasznalonak shared memory allokalasra, valamint rekurziv (stackzabalo) fuggvenyek hivasara is. Ez lehetoseget ad a tamadonak arra, hogy a fenti hibaval e ket teruletet osszeeressze, es az X stackjat modositva az X futtato user neveben futtasson barmit. A problema az, hogy az X az root neveben fut a legtobb disztribucioban.

(ez a bejegyzes nem a velemenyemet tukrozi, csak a megadott pdf magyarazo tomoritese)

Köszi, hasznos!

Köszi.

És ennek ellenére nem láttunk még működő exploitos kódot.

Spengler kódja egy vicc. Nálam se hozza az bizonyítékot csak ígéret maradt.

A csajszi meg valami koncepciókról ír.

WTF! Hol a kód?

--
GPLv3-as hozzászólás.

Én úgy érzem, a csajszi a cégét meg a Qubest reklámozza...

Igen.

Ugy tunik (es ez a sajat velemeny) hogy van egy biztonsagtechnikaval foglalkozo szubkultura, ahonnan 'nem jonnek ki' (nem lesznek altalanosan ismertek) az kideritett hibak. Az Invisible Things Lab bedolgozta magat ide, es a szubkultura altal regota ismert (tipikusan 4-5 eves) sebezhetosegekbol publikal egy cirkalmasat. Persze keves hozzaadott ertekkel.
Ez nem azt jelenti, hogy ne dolgoznanak az Invisible T.L. -nel nalamnal jobb, esetleg sokkal jobb biztonsagi szakemberek, mert dolgozhatnak epp. Csak eppen nem a sajat munkajuk gyomolcseit elvezik, hanem egy kicsit vitetik magukat.

Az megint egy masik szal, hogy mi a velemenyem arrol, hogy egy igen jelentos agyi osszkapacitasi kozosseg nem publikalja a megtalalt hibakat. Kicsit cinkosan egyuttmukodnek a nagy cegekkel, akiket szinten nem zavar, ha nehany(szaz) rosszindulatu egyen torogeti az programjaikat, csak ne deruljon ki, ne legyen belole arcvesztes.

innentol mar hosszu lenne. Nem vagyok biztonsagtechnikai szakember, es nem veletlenul nem vagyok. Undorodom az "en tudom, es nem mondom meg, bibibeee" jellegu hozzaallastol, akar harombetus ceg csinalja, akar 12 eves kiskamasz, akar civil felnott.

"Undorodom az "en tudom, es nem mondom meg, bibibeee" jellegu hozzaallastol"

Azért nem ilyen egyszerű az ügy szerintem. Valszeg van ilyen is, de azért az is bejátszhat amikor közlik az emberrel, hogy "túl sokat aggódik az ember a biztonságért", vagy a fejlesztő cég azt mondja, hogy amit találtál, az nem is security hiba, esetleg beismerik a hibát, de azt mondják, hogy nem lehet kihasználni, esetleg nem is válaszolnak, hiába jelentik a hibát.. Nagyon sok minden közbejátszhat, ami miatt azt mondja valaki, hogy "baxátok meg, akkor fulladjatok meg". Innentől meg már külön szál, hogy open-disclosure, exploit fejlesztés, vagy mi lesz belőle.
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Na most oké, szubkultúra ide vagy oda.

Most a csaj publikált egy nagy kupac, gőzölgőt. (cikket úgy értem. :D) Hatalmas körívekben beszélt a stack overflow típusú támadásokról érintve az X-et meg egy-két dolgot.

Na most sztem valakinek fel kellene nyitnia a szemét, hogy mióta a homo sapiens elkezdett programozni Logo-ban, azóta vannak stack overflow típusú hibákon alapuló támadások rendszerek ellen.

Kódot nem virított, és Linus aug 13-án pusholta a patchet.

--
GPLv3-as hozzászólás.

a fő bajom az ezzel a cikkel, hogy van egy kernel bug. az én eszem szerint a kernelt kell megpatkolni ahhoz, hogy a bug megjavuljon. ő meg mindenféle kacatot reklámoz, hogyha felteszed az ő virtualizációs agymenését, akkor ugyan a bug marad, de nem lehet majd kihasználni vagy valami ilyesmi.

Van igazsag a virtualizacios agymenesben.
Feleheto, hogy ilyen hibabol a kernelben, barmiben van meg masfelezer. Ha talalunk egy megoldast, ami a hiba kijavitasa nelkul lehtetlenne teszi a hiba kiaknazasat, akkor egycsapasra masfelezer hibat javitottunk.

Es van hazugsag abban, amit allit, hiszen a virtualizacios agymenes az csak bizonyos hibak ellen ved, azon az aron, hogy behoz nehany ujabb potencialis hibat. Volt pl a VMware-ben, hogy hibasan emulalta a CPU-t, es deklaraltan ki lehetett jutni a VM userebol a VM kernelebe. Azt sem tartjuk lehetetlennek, hogy a VM kernelbol a fizikai kernelbe ki lehessen jutni. MInt ahogy ring0 -> ring-2 kijutast is lattunk mar procihibabol kifolyoloag.

"profitért és a mulatság kedvéért"

Ugye, hogy mennyire jobban hangzik ez angolul? :)

iPhone 4 nyeremenyjatek: http://koponyeg.hu/jatek/ca9d4cbc (koszi!)

Kozben rajottem, hogy azt kellene irni, hogy 'for FAP'

rootkent futo X ami eleve vicc mar nagyon reg ota

elvileg nincs messze a user-mode X

Ahogy a linux desktop éve sem :)
--
ez ugye csak valami vicc

:)

a gond az, hogy tenyleg megoldhato lenne (openbsdsek dobhatnak a threadbe vigyort) csak leszarjak

Nekem úgy tűnik, hogy nem leszarják, hanem dolgoznak rajta.

--
trey @ gépház

hiszem, ha majd látom ;) egyrészről ez jó hír, másfelől viszont vicces, hogy 2010-ben ez még probléma.

A blueprint szerint a Maverick alpha3 a cél, az Ubuntu 10.10-ben pedig már benne kellene lennie. Őszre kiderül, hogy sikerült-e megoldani.

--
trey @ gépház

Nem éppen azért sz.r mert ezt nem tudja.

Ez egy másik gondolatmenet lesz? Mert nem bírom követni az ilyen éles váltásokat. Mármint micsoda? Olvastad azt, hogy miről beszéltünk?

--
trey @ gépház

"Ahogy a linux desktop éve sem :)"

Nem pont a root nélküli X lesz a megváltó a grafikus felülettel kapcsolatban.

Ja, mi arról beszélgettünk, hogy lesz-e rootless X vagy sem. A desktop évéről és annak eljöveteléről / el nem jöveteléről mások beszélgettek. Azt hiszem eltévesztetted a szálat.

--
trey @ gépház

Én úgy látom a szálat w4rp tévesztette el.

--
ez ugye csak valami vicc

ez ugye csak valami vicc ;)
(a humorizalasodon tullepve folytattam a szalat, masnak egyertelmu volt, shikinek nem)

Fúha mi lesz itt?!?!
(Tényleg szörnyű dolgok folynak mostanság errefele.)

A melodráma szakkör mindig is népszerű volt, nem új dolog ez.

-

-

Segítek... erre kellett volna válaszolnod. Tudom, nehéz, de bele lehet jönni.
--
ez ugye csak valami vicc

Nem szeretem megtörni a szálat. Meg hülyén néz ki ha magamnak válaszolok. Ne drámázz már ennyit.
(Amugy minek törölted az előzőt? Akkor már én is, nem tudtam, mit akarsz)

Elírtam valamit, és javítani akartam, de remekül belekommenteltél egy értelmeset. A linket pedig nézd meg jobban, nem magadnak kellett volna válaszolnod.
(Igen, az előző kommentben ezt rontottam el, de már mint látod nem tudtam javítani)

:) /a thread még mindig a non-root X-ről szól/

A szál - amibe beletrollantottál - itt kezdődik és a rootless X-ről szól. HTH

--
trey @ gépház

"In an email to The H, Joanna Rutowska clarifies that Spengler's exploit targets "some unrelated vulnerability" and her reference to it was in relation to guesses made by Spengler noted in the source code comments."

A fentiek szerint Spengler kódjának nincs köze ehhez a sebezhetőséghez.

--
trey @ gépház

köszi.

A H-online frissítette a cikkét:

Update - As Marcus Meissner from the SUSE security team explained to heise Security, SUSE maintainer Andrea Arcangeli provided a fix for the problem in September 2004, but for unknown reasons this fix was not included in the Linux kernel. SUSE itself has the fix and SUSE Linux Enterprise 9, 10 and 11 as well as openSUSE 11.1 through 11.3 do not exhibit this vulnerability.

Vagyis a Heise Online értesülései szerint már 2004-ben készített egy javítást az ominózus problémára a SUSE egyik fejlesztője. Nem került be a javítás a kernel-be. A SUSE (Novell) a SLES9, SLES10, SLES11 és openSUSE 11.1-11.3 verziókban szállítja is a kernel fixet. Hmmmm. Aranyos...

A forrás itt található.

Szerintem benne volt már az korábbi rendszerekbe is, most megnéztem 11.0-n, azon is ugyanúgy execve failed. 10.3 már nincs, nem tudom megnézni...
--
Discover It - Have a lot of fun!

6év? Lassan MS magasságokba emelkedik a foltozási idő.