Linux kernel: CVE-2017-6074: DCCP double-free vulnerability (local root)

 ( trey | 2017. február 22., szerda - 21:11 )

A hibát február 17-én javították. A legrégebbi, letesztelt kernel verzió a 2.6.18-as (2006 szeptember), ami érintett. A felfedező, a Google alkalmazásában álló Andrey Konovalov exploitot még nem publikált, ad időt a frissítésre.

Részletek 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ő.

grsec megfogja?

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

Hagy tippeljek:
A fizetos resszel, a majd publicalt expolitot nem nulla esellyel megfogja (csak kis penzt tennek ra),
de az nem teszi hibat nem kihasznalhatova (senki sem fogja bizonyitani, ido hianyaban).


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

>hagy publicalt expolit

egyet értek

melyiket?:)

Az mindegy, ilyen meg nem volt ;-)


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Őőőő nem akarlak elkeseríteni, de... :D

-pilisig-

ROTFL

Publikálta Andrey a PoC exploitját. Ubuntu 16.04 disztribúció 4.4.0-62-generic #83-Ubuntu kernelén működik, de újabb processzorok esetén elérhető SMEP/SMAP védelmek mellett hajlamos pánikba kergetni a kernelt. Ez nyilván "javítható" és stabilabbá tehető.

A jelenlegi PoC mindenesetre számos olyan módszert használ, amelyet a grsec megfog. Egyrészt a rendszerek legnagyobb részénél a hibát tartalmazó dccp_ipv6 kernel modul nincs betöltve alapból. Ennek user általi betöltésének kikényszerítését azonban a Grsecurity tiltja, ha a MODHARDEN kernel konfig be van kapcsolva:

denied kernel module auto-load of dccp_ipv6 by uid 1001

Ha ezt figyelmen kívül hagyjuk (pl. a támadó mégis ki tudja kényszeríteni a kernel modul betöltését, vagy már eleve be van töltve, esetleg a kernelbe van a DCCP funkció fordítva), akkor a következő probléma az, hogy az exploit egy unprivileged user namespaces sandbox funkcióra alapoz, amelynek user általi használatát a grsec szintén tiltja, mert nagy támadási felületet okoz:

unshare(CLONE_NEWUSER): Operation not permitted

Ez a korlátozás nem is konfigurálható külön, ilyen user namespace létrehozásához vagy CAP_SYS_ADMIN képességekkel kell rendelkezni grsec alatt, vagy az adminnak saját felelősségre módosítani kell az érintett kernel kódot, hogy a korlátozott felhasználók is képesek legyenek ilyen veszélyes üzemekre.

Szóval addig el se tudunk jutni egyszerűen, hogy a Grsecurityben lévő PaX kernel önvédelmi funkciói hány helyen nehezítenék meg a támadást és a RAP plugin megfogja-e a shinfo->destructor_arg->callback függvénypointer átírást a native_write_cr4 kódjára...

Fedorához már fordítják a javítást tartalmazó kernelt. Nagyjából éjjel 2-re lesz kész.


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

Már? Az Ubuntu tegnapelőtt javította.

--
trey @ gépház

Fedora dolgai elég újak szoktak lenni, ezek szerint kissé lemaradtak.

Szerk.: bele ne kössön valaki, hogy nem tudok UTC-ből local time-ot számolni, egész egyszerűen hülyeség az ott lévő becslés. Tapasztalat, kb. 6 óra alatt fordul le a build szerverükön.


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

Az se túl méretes e-pénisz...

2017-02-15: Bug reported to security () kernel org
2017-02-16: Patch submitted to netdev
2017-02-17: Patch committed to mainline kernel
2017-02-18: Notification sent to linux-distros
2017-02-22: Public announcement

Nem méretes, hanem példás!

--
trey @ gépház

És ahol 19-én már megvolt? Extra példás?

szerintem csak örüljünk, hogy ennyire jó arcok dolgoznak a világban, akármelyik disztrót is kedveljük.

Az oké, hogy előbb utóbb egy jó arc is észreveszi a hibát és felhívja rá a figyelmet, és javítják is gyorsában, de ennyi év alatt vajon még hányan vették észre, kevésbé jó arcok?

Ha ez ennyire nem szúrt szemet, vélhetően másnak is nehezére esett megtalálni. Meg a számítástechnikai rendszerek majd' mindegyikének sajátja ez. Most rettegni fogsz örök életedben? Vagy nem használsz számítógépet? Az utcán is elüthetnek.

Meg a lehetőség itt kettős: vagy észrevette más előttük, vagy sem. Szerintem kisebb az esélye annak, hogy nem. Többen foglalkoznak azzal, hogy ezeket mielőbb elkapják (és nagyságrendekkel többen vannak azok, akik egy véletlen folytán találnak ilyeneket), mint a másik "oldal".

Értem amúgy amit mondasz, csak én más nézőpontból közelítem meg a kérdést. Ha te vagy a fb biztonsági vezetője, persze aggódj. De ha nem, annyira ne izgasson a téma, hogy álmatlan éjszakáid legyenek.

Ha ez ennyire nem szúrt szemet, vélhetően másnak is nehezére esett megtalálni.

Ez az érvelés még manuális kódauditálás esetén is gázos lenne, de ezt a hibát ráadásul egy bárki számára szabadon elérhető és használható syscall fuzzerrel találta a jóember automatizáltan.

Többen foglalkoznak azzal, hogy ezeket mielőbb elkapják (és nagyságrendekkel többen vannak azok, akik egy véletlen folytán találnak ilyeneket), mint a másik "oldal".

Kiváncsi lennék honnan ered ez a nagyon komolynak tűnő statisztika... Hogy mást ne említsek, a közelmúltból ott van a Dirty Cow sebezhetőség, amelyet szintén nem a fehérruhás, floss hívő, manyeyeballs jedi harcosok találtak meg először, hanem már javában használták ki a hibát éles exploitokkal a "vadonban" amikorra az egyik támadásnál sikerült lesniffelni a payloadot.

>Kiváncsi lennék honnan ered ez a nagyon komolynak tűnő statisztika...

ezt a jelenséget a köz "vakhit" néven ismeri

Talan mert egyesek olyasmit terjesztenek, hogy a kijavott hibak nagy reszerol
soha senki nem nezi meg (publikalja),
hogy tenylegesen van -e, vagy nincs biztonsagi kockazata.
effective "Csendben javitjak", meg ha nem is tudnak rola.

E hirek terjesztoi azt is mondjak,
hogy nagysagrendekkel tobb ilyen `Csendben javitot` hiba van, mint
hires 'Dirty Cow' szeru hibak.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

szeg-ecs forrdiccss.!

Álmatlan éjszakáim nincsenek, csak furcsának érzem a hurrá hangulatot, hogy Canonical, Red Hat, stb. milyen gyorsan adja ki a fixált kernel csomagokat. És 11 évig merre voltak? Költői. Csak azért ne üljünk már fel a hurrá vonatra.

Bejelentés, 8 nap után javítás.

vs.

Bejelentés 90 nap után is sunnyogás. Aztán újra. Aztán ...

--
trey @ gépház

@_@

alapprobléma vs. máshol szarabb

Itt disztribútorokról és azok reakcióidejéről volt szó. A disztribútornak nem sok köze van az alapproblémához, amit te itt erőltetsz. A Google 90 napos türelmi időt állapított meg meg a felelős közlésre, iparági egyeztetések és többek közt a Microsoft rinyálása nyomán.

A fent általam idézett timeline ennek figyelembe vételével nagyon is korrekt.

--
trey @ gépház

Egy gondosan kiválasztott oldalról nézed a dolgot. A többi oldalról nem is érdekel a téma. Oké. Király! Éljen! De gyorsak! Wow! Fuck MS! Fuck Apple! 1+!

/me ásít (hehe, gondolom ez jött volna válasznak)

Próbáld meg a szálat az elejétől újraértelmezni, mert kapálódzol össze-vissza és ez rohadt szánalmas.

--
trey @ gépház

Tudom honnan indult a szál, köszi. A javítás kiadására érzett eufóriára nem lehet véleményem? Szerintem nincs ok az ujjongásra, ezt fejtettem ki. A magam rohadt szánalmas össze-vissza kapálódzásával persze. Nem lehet?

Az hogy te meg próbálod a dolgot minden erőddel az ismert javítás gyors adoptálására fókuszálni, az meg egyedi sajátosságod.

$ grep DCCP 2_4_37_11.txt
$

unstable (2.6+) kernelek használói még mindig szopnak ¯\_(ツ)_/¯

Mert úgy gondolod, hogy a 2.4-es sorozat hibátlan? Vagy abból indulsz ki, hogy annyira kiesik a fősodorból, hogy senki sem keresi és támadja a benne lévő lyukakat?


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

[butthurt systemd user thread derailing attempt detected]