Távolról kihasználható biztonsági hiba a Linux kernelben - exploit szabadon

Titkosítás, biztonság, privát szféra

Mai történetünk főszereplője a CVE-2009-0065 névre keresztelt memory corruption bug, amelyet a legtöbb disztribúció a hiba jellegét figyelmen kívül hagyva "denial of service"-ként azonosított.

Mint utóbb kiderült, hibásan: a bug nem csak hogy lehetővé teszi a ring0 kódfuttatást, hanem ez távolról is végrehajtható, ha van a célgépen egy elérhető sctp socket.
Az exploit publikálója blogbejegyzésében nem mulasztja el megemlíteni, hogy a potenciálisan kihasználható memory corruption hibák DoS-ként kezelése nem ritka dolog a Linux kernel esetében.

Exploit itt.

( trey | 2009. 04. 29., sze – 08:10 )

Az szopás, ha hibajavítás leírása nem pontos, vagy szándékosan elferdítik.

Azonban nekem úgy tűnik, hogy a disztribútorok ezt a hibát már ~ 1 hónapja javították. Jól látom?

--
trey @ gépház

itt nezz utana. tavaly karacsonykor javitottak a Linus fajaban, akkor csak "this may cause memory overflow" szerepelt, egyeb meghatarozas nelkul. aztan januar elejen lett belole CVE, es egy RHEL pl. februar elejen javitodott csak (de pl. az RHEL 4 csak marciusban). meg azon is el lehet toprengeni persze ilyenkor, hogy masnak korabban lehetett-e ra exploitja ugye. persze egy SCTP-t keves gepen hasznalnak tudatosan (ha jol remlik telekom szferaban leginkabb), de mas 'DoS' hibakra is igaz volt/lesz ez vajon?

( uid_228 | 2009. 04. 29., sze – 08:29 )

Adódik a kérdés, hogy ez mennyire jelent vajon reális veszélyt? Olyan sokan nem tudom, hogy használnák az SCTP-t.

--
"How do you work in a team situation when all the other team members are fools and idiots?"

( nevergone v | 2009. 04. 29., sze – 09:02 )

Nah, ha felébrednek a trollok, akkor ezzel szerintem elleszünk 100-200 hozzászólásig.

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

( takemeaw | 2009. 04. 29., sze – 10:48 )

ez kamu

en ugytudtam hupos informaciok alapjan h a linux a legbiztonsagosabb operacios rendszer es nem lehet privilegiumot emelni foleg nem tavolrol

csalodtam a hupban!

:)
--
.

( uid_4672 | 2009. 04. 29., sze – 11:20 )

csak azt nem értem, hogy egy experimentalnak jelzett dologban lévő bugból miért kell ekkora dolgot csinálni? amúgy meg ki használ sctp-t, főleg éles környezetben?

"csak azt nem értem, hogy egy experimentalnak jelzett dologban lévő bugból miért kell ekkora dolgot csinálni? "

Te szoktal latni az exploitokban 

if(this_feature_is_experimental) return -1;

reszeket?

"ki használ sctp-t, főleg éles környezetben?"

A sajat gepein a telco ipar, nem sajat gepein meg aki rootjogot szeretne. :)

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

A sajat gepein a telco ipar, nem sajat gepein meg aki rootjogot szeretne. :)

hát az a telco cég, aki erre pont linuxot használ, az megérdemli, pont az experimental miatt.
A rootjoghoz pedig nem elég egy linux kernel, kell egy sctp-re bindolt program is...

szóval szerintem ez egy nagyon jó flame téma, de csak ennyi.

"hát az a telco cég, aki erre pont linuxot használ, az megérdemli, pont az experimental miatt"

Hol lattad az "experimental"-t ugy definialni, mint "full of secholes"?

"A rootjoghoz pedig nem elég egy linux kernel, kell egy sctp-re bindolt program is..."

Localbol ez nem olyan bonyolult dolog.

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

Hol lattad az "experimental"-t ugy definialni, mint "full of secholes"?

idézem a kernel CONFIG_EXPERIMENTAL helpjét:

Some of the various things that Linux supports (such as nework drivers, file systems, network protocols, etc.) can be in a state of development where the functionality, stability, or the level of testing is not yet high enough for general use.

Localbol ez nem olyan bonyolult dolog.
mintha a topic címe úgy kezdődne, hogy "távolról kihasználható..."

Ertem. Tehat amig "experimental" a kod, addig szigoruan hanyagolni kell a sanity check-eket, aztan amikor atminositik "stable"-be, akkor minden developer elobanyassza a jegyzetfuzetet a fiok melyerol, es hirtelen bekerul az osszes szukseges ellenorzes.
Igy keszul az ubersecure kernel kod.

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

Akkor vilagosits fel kerlek, hogy a kod experimental volta miert jelent felmentest a gondolkodas alol, es szerinted milyen mechanizmus szerint lesz az ilyen fejlesztesi metodika mellett torvenyszeruen eloallo nagy rakas sz.rbol ertekelheto minosegu kod.

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

Tehát nem tudsz. Biztos így sikerült azt, hogy "Some of the various things that Linux supports (such as nework drivers, file systems, network protocols, etc.) can be in a state of development where the functionality, stability, or the level of testing is not yet high enough for general use." arra ferdíteni, hogy "Tehat amig "experimental" a kod, addig szigoruan hanyagolni kell a sanity check-eket".

Neked. Egyrészről elgondolkozni, hogy mennyi minden experimental a kernelben, másrészről megválaszolni azt a kérdést, hogy egy cégnek ugyan mi köze van ahhoz, hogy a Linux kernel _forráskódjában_ szerepel egy ilyen "experimental" jelző és hozzá egy leírás, amikor ő vesz egy "_kész_" terméket sok pénzért, ráadásul Red Hat ___Enterprise___ Linux néven és a benne lévő funkciókat (adott esetben SCTP támogatást) használja.

Miért lesz ettől az adott felhasználó/cég hülye, miért 'úgykellneki' és miért "megérdemli"?

Abba már bele se merek gondolni, hogy ha megjelenne egy exploit, amelyik az IP stack-ben lévő hibát használná ki távolról, akkor milyen kimagyarázás lenne belőle. Persze nem fogjuk megtudni, mert olyan értékes exploitot senki se fog publikálni.

Nekem? Ez miben kapcsolódik az utolsó néhány posthoz?

Arról volt szó, hogy a fejlesztők által odabiggyesztett experimental jelző mit jelent, nem arról, hogy mi minden más tekinthető még különféle nézőpontokból experimentalnak. Továbbá nem rémlik, hogy olyat írtam volna, hogy bárkinek is úgy kell illetve megérdemli.

Ez miben kapcsolódik az utolsó néhány posthoz?

Nem kevésbé, mint az egész történethez az adott funkció experimental mivoltja.

Arról volt szó, hogy a fejlesztők által odabiggyesztett experimental jelző mit jelent

Az mindenesetre látható, hogy a leírásban nincs se arról szó, hogy semmiképp se használd, se arról hogy ha mégis használod, akkor szanaszét törik rajta keresztül a rendszeredet.

nem arról, hogy mi minden más tekinthető még különféle nézőpontokból experimentalnak

Ahogy az egész dolog nem is arról szól, hogy a fejlesztők a forráskódokba milyen kommenteket írogatnak és melyik felhasználóknak hogyan és miképp kellene ezt értelmezniük.

Továbbá nem rémlik, hogy olyat írtam volna, hogy bárkinek is úgy kell illetve megérdemli.

Azt a troll pajtásod írta a thread elején. :)

"Az mindenesetre látható, hogy a leírásban nincs se arról szó, hogy semmiképp se használd, se arról hogy ha mégis használod, akkor szanaszét törik rajta keresztül a rendszeredet."

Én látok benne olyat, hogy még nem való általános használatra. De valóban igazad van, tényleg nem sorolták fel benne tételesen, hogy adott esetben mi minden okok miatt nem való általános használatra...

"Azt a troll pajtásod írta a thread elején."

Nem pajtásom, és nem mellesleg a kijelentésével kapcsolatban se pro, se kontra nem foglaltam állást.

gondolom te is annak a fejlesztesi metodusnak a hive vagy h "hannyunk mindent ossze eloszor aztan jelentsuk a fonoknek hogy kesz van majd a tesztelesi ido alatt megirjuk rendesen csak kozben beesik meg ket project amit hasonlokeppen kezelunk"

nos ezzel szemben egy operacios rendszert lehet h celszerubb lenne ugy fejleszteni h 1 ficsort lefejlesztek szennetesztelem aztan johet a kovetkezo es igy tovabb

--
.

Tehat szerinted azoknak az embereknek akiket elsosorban az erdekel, hogy sajat hardwerukon (arch/board/periferiak) menjen a Linux, le kellett volna allni a sajat fejlesztesukkel es stcp -t fejleszteni, mert neheny embernek az kell ?
Ill. pl. stcp fejlesztoknek, akiket kurvara nem erdekel eppen, hogy milyen fs van, be kene szalniuk fs -t fejleszteni, amikor eppen egy fs hozza adassan van a sor ? Es ha azzal meg vannak akkor dolgozhatnak talan az stcp-n, ha az kovetkezo feature ?

Szerinted egy-egy ilyen kisebb reszen 1000-10000 ember tud egyutt dolgozni ?

Ugy latom nem kapisgalod, hogy mekkora fejlesztoi tabora van es milyen igenyeik vannak a fejlesztoknek.
Ugy latom nem vagod, hogy mindenki azt fejleszti bele amire igenye vagy megbizasa van.

Es nem vagy tisztaban a kernel eletutjaval sem.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

"tény, hogy bugok mindig voltak, vannak, lesznek."

Teny. A problema nem is ezzel van.
A problema egyreszt az, hogy nem ritkan rosszul soroljak be a bugokat (remote root bugot dos-nak, mar ha besoroljak egyaltalan), masreszt a bug milyensege: ez egy tipikus amator kiszurja-az-ember-szemet hiba, raadasul meg az exploit is egy teljesen tiszta helyzet (mar amennyire egy remote kernel exploit az lehet). Az almoskonyv pedig azt mondja, hogy az ilyenek ritkan jarnak egyedul.

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

>hát az a telco cég, aki erre pont linuxot használ, az megérdemli, pont az experimental miatt.

Akkor az osszes telco ceg megerdemli. Montavista,Wind River Linux, sorolhatnam ha nem is a legutolso experimental kernel-lel, de ott van a mai telco cuccok nagy reszen, foleg a PPC alapuakon.
olvasnivalo > http://en.wikipedia.org/wiki/Carrier_Grade_Linux
Amugy meg a telco cegek valoban hasznalnak SCTP-t, de egyreszt kozel sem biztos, hogy nem egy sajat SCTP stacket, masreszt nem az end user fele, szoval max az sp backboneon levo Huawei telefonkozpontja tud ledonteni egy Nokia gatewayt ezzel az exploittal... :)

Egyfelol nincs igazad, ugyanis linuxon gazdasagosabb ilyent uzemeltetni, nem mellesleg meg ilyen feltetelek mellett is biztonsagosabb, mint windowson/doson.
Masfelol az a funkcio idetlen idok ota experimental, szoval meg csak a kifogas kategoriajaba sem esik, hogy szegeny agyonterhelt linux developereknek nem volt idejuk ranezni a kodra.
Harmadsorban, experimental vagy sem, kiadott kodba jobb helyeken nem kerul bele olyan kod, ami nincsen secu szempontbol szenne tesztelve, fuggetlen attol, hogy experimental egyebkent a kod, vagy sem. Eleg szomoru dolog, hogy a linux kernel fejlesztese nem tartozik a jobb helyek koze. Ez a patch elfogado gardat minositi.

Mondjuk megint mas kerdes az, hogy az a telco ceg, aki a frontend gepeire nem rak valami hardened megoldast, az meg is erdemli, hogy feltorjek a rendszeret.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

( synapse | 2009. 04. 29., sze – 13:12 )

Aki figyeli a bugtraq-kat annak valoszinuleg evidensse valt hogy az sctp eleg szarul van megirva, ugyanis havonta jon ra egy hasonloan sulyos hiba...

--------------------------
The OOM killer is like a surgeon that amputates the limb of a man to save his life: losing a limb is not a nice thing, but sometimes there is nothing better to do.

"Understanding the Linux Kernel" on page frame reclaiming

( anr | 2009. 04. 30., cs – 07:32 )

mar evekkel ezelott is morogtam amiatt, hogy az SCTP-ben tobb hiba van, mint a linux kernel teljes maradek reszeben. a nagy telkom cegek csinaltak, nekik is kell. ok meg zart halozaton hasznaljak...
asszem az SCTP volt az az ominuzus eset, amikor 1.5mill soros patch-et postaztak az LKML-re es hoborogttek, hogy azonnal keruljon bele a kernelbe

--
Live free, or I f'ing kill you.

( hrgy84 | 2009. 04. 30., cs – 11:44 )

Csak tajekoztatasul: van egy hitehagyott BGO bug errol #254907, szoval ovatosan ezekkel a kernelekkel, nem tudom, mi az allaspont.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

( hrgy84 | 2009. 04. 30., cs – 11:46 )


$ gcc -c sctp_houdini.c
sctp_houdini.c:32:26: error: netinet/sctp.h: Nincs ilyen fájl vagy könyvtár
sctp_houdini.c: In function ‘make_sctp_connection’:
sctp_houdini.c:710: error: storage size of ‘msg’ isn’t known
sctp_houdini.c:712: error: invalid application of ‘sizeof’ to incomplete type ‘struct sctp_initmsg’ 
sctp_houdini.c:730: error: ‘SOL_SCTP’ undeclared (first use in this function)
sctp_houdini.c:730: error: (Each undeclared identifier is reported only once
sctp_houdini.c:730: error: for each function it appears in.)
sctp_houdini.c:730: error: ‘SCTP_INITMSG’ undeclared (first use in this function
$ uname -r
2.6.27-gentoo-r8-brand-r1

-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.