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

 ( eax | 2009. április 29., szerda - 6:56 )

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.

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

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

Én is néztem.

Debian alatt pl: DSA-1749-1 linux-2.6

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?

Kösz. Nem akartam a problémát kisebbíteni, csak kíváncsi voltam, hogy van-e teendőm vele. Mivel a cikkben az a fontos információ, hogy mit érint, részletesen nem szerepelt.

--
trey @ gépház

Kíváncsi vagyok, hogy a PaX(/Grsecurity) számít-e valamit? SELinux ugyanis nem akadály neki...

Üdv:
Dw.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

A PaX kernexec elvileg megfogja (nem probaltam ki).

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

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

Tenyleg kik hasznaljak ? En nem emelekszem, hogy lattam volna ilyet barhol is.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

sőt, linuxot is kevesen használnak...

csak barátaid nincsenek.

--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.

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

-

Kár volt kiszerkesztened, de nem baj, mert majd a Minix és a mikrokernel (csak hogy meglegyen a kapcsolat a két cikk között)

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

-

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!

:)
--
.

Én viszont benned nem. :D

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.

Gabu uzeni: +1

Nemá! Mi van Gabuval? Remélem jól megvan.

Üdv:
Dw.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Gabu valószínűleg az "aki erre pont linuxot használ, az megérdemli" mondatrészre pluszegyezett és talán hozzgondolta azt is, hogy az "erre pont" szavak nélkül. :P

Jaja. OSX serverben, meg az OpenVMS-ben jobb minőségű az SCTP?

Szerencsére nekem nincs szükségem SCTP-re...

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

"Persze", hogy jobb, hiszen az nemlinugz: :D

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

"Ertem."

Pedig úgy tűnik, hogy egyáltalán nem.

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!

Te tudsz angolul?

Tehat fogalmad sincs. Koszonom, kerem a kovetkezot.

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

Kinek, miben?

Az eredeti kepen nincs rajta az a felirat.
:D


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

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.

nem takar mindent az experimental felirat :(
___
info

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

--
.

Az úgy munka, hova a szórakozás?

----------------
Lvl86 Troll

:))
modjuk ez egy hobbiproject
--
.

ezt az urban legendet honnan veszitek, hogy a linux hobbi project?
---
/* No comment */
Ketchup elementál megidézése a sajt síkra

A Troll kezikonyvekbol.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Onnan, aki hogy mission critical rendszert (azért az OS kernele szerintem ez a kategória) agile developmenttel fejleszt, az minden, csak nem profi.


"A fejlesztot azert fizetik, hogy oldja meg a problemat. Ez egy kemeny szakma." - Chain-Q

+1
--
.

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.

nem tudtam, h mar ertelmezesi gondjaid is vannak, nem csak irasiak..

egyaltalan nem errol beszelt, olvasd el meg1x.

A fejlesztő == tesztelő elmélet nem érdemel meg 1 olvasást sem.

rossz hír ez turulnak

Nem, nem az.

hát igen, csak ezt még nem tudja

Rosszul gondolod.

tény, hogy bugok mindig voltak, vannak, lesznek. épp azért mondtam, hogy egy ilyen dologból egy bugreport erejéig kell problémát csinálni, nem pedig felfújni, hogy mekkora übersecurity problem a linux kernelben és hogy reszkessetek linuksz júzerek.

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

"A sajat gepein a telco ipar,"
Na, akkor megyünk telco-t törni!
:)))

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

kettős mérce

Most nagyon troll szagúan hangzana az, hogy az egész kernel egy halom fejlesztő experimental experimentje?

----------------
Lvl86 Troll

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

:(

--
.

És ráadásul terjed is! (FreeBSD)

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.

Ja kb. a felhasznaloi tabor == feljlesztoi tabor.
Ha meg nem kerul be, akkor azert hoborognenek az emberek.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

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.

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

emerge lksctp-tools