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

Bug

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.

( nevergone v | 2017. 02. 22., sze – 21:32 )

grsec megfogja?

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

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

( locsemege v | 2017. 02. 23., cs – 20:16 )

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

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

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.

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.

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

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.

( szegecs | 2017. 02. 25., szo – 07:24 )

$ grep DCCP 2_4_37_11.txt
$

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