A Project Zero kifejlesztett egy módszert a Linux sebezhetőségeinek kihasználására

Linux

Null hivatkozások kihasználása a Linux kernelben

Nemrég jelentették be, hogy a Google Project Zero csapatának kutatói kifejlesztettek egy módszert a Linux kernel sebezhetőségeinek kihasználására, amelyeket a NULL mutató dereferenciálása okoz.

Eddig a NULL pointer dereferenciával kapcsolatos kernelproblémák nem kaptak kellő figyelmet , mivel irreálisnak tartották ezeket a problémákat olyan támadásokká alakítani, amelyek privilégiumok eszkalációjához vagy saját kód végrehajtásához vezetnek (tilos a nem privilégiumozott folyamatoknak a címtartomány alsó régiójába való leképezése).

Általános szabályként az ilyen hibák a kernel oops figyelmeztetéseinek generálásához vezetnek , amely után a problémás feladatok befejeződnek, és az állapot visszaáll a rendszer leállítása nélkül.

Az új támadási módszer az „oops” állapotok kezelésén alapul , amelyek a referenciaszámláló (recount) értékének növekedését eredményezhetik, ami viszont a számláló túlcsordulását és a recounthoz tartozó memória felszabadítását okozhatja.

Ebben az esetben a kihasználás a használat utáni támadásokra jellemző manipulációkra redukálódik (előfordul olyan helyzet, hogy az objektum referenciaszáma nullává válik, a memória felszabadul, de valójában működnek a felszabadult memóriára mutató hivatkozások).

Jelenleg, amikor a Linux kernel egy folyamatkörnyezetből null dereferencia-üzenetet vált ki, egy oops jelet generál , ami különbözik a kernel pániktól. Pánik akkor következik be, amikor a kernel úgy ítéli meg, hogy nincs biztonságos módja a végrehajtás folytatásának, és ezért le kell állítania az összes végrehajtást. A kernel azonban nem állítja le az összes végrehajtást egy oops alatt; ehelyett megpróbálja a lehető legjobban helyreállítani a folyamatot, és folytatja a végrehajtást.

A NULL mutató hivatkozásának megszüntetése itt a "hoppá" állapot irányított módon történő generálására szolgál. A probléma az, hogy körülbelül 232 "hoppá" állapothívásra van szükség ahhoz, hogy elérjük a 32 bites visszaszámlálási túlcsordulást.

Gyakorlati szempontból körülbelül nyolc nap folyamatos OOP (helyen kívüli) állapotgenerálás szükséges egy javasolt kihasználható támadás végrehajtásához. Siker esetén a kihasználható sérülékenység lehetővé teszi a kód kernel szintű végrehajtását.

A kihasználás során használt NULL mutató hivatkozást októberben kijavították, de mivel a hasonló problémák nem ritkák, és korábban hibaként, nem sebezhetőségként kezelték őket, a fejlesztők általános védelmet adnak a Linux kernelnek, hogy megakadályozzák az "hoppá" generálását manipuláló támadásokat. ."

 Egy feladat esetében ez azt jelenti, hogy el kell vetni a meglévő kernelvermet, és közvetlenül a make_task_dead-hez kell menni, amely meghívja a do_exit-et. A kernel egy "összeomlási" naplót és egy kernelkövetést is elküld a dmesg-be, amely megmutatja, hogy a kernel milyen állapotban volt a hiba bekövetkeztekor. Ez furcsa választásnak tűnhet, ha egyértelműen memóriasérülés történt; mindazonáltal a cél az, hogy a kernelhibákat könnyebben észleljék és naplózzák, az a filozófia szerint, hogy egy futó rendszert sokkal könnyebb hibakeresni, mint egy nem működő rendszert.

A 6.2-es kernel különösen olyan változtatásokat tartalmaz, amelyek korlátozzák az „oops”-ok maximális számát . A korlát elérése után, amely alapértelmezés szerint 10 000 oops-ra van beállítva (ezt az oops_limit paraméterrel módosíthatja, ha szükséges), a kernel „pánik” állapotba kerül, majd újraindul, ami nem engedélyezi a recount nullázásához szükséges iterációk számát.

A tervek szerint a korlátozás átkerül a korábban kiadott, de még támogatott kernelágakra, valamint a népszerű disztribúciók kernelcsomagjaira is.

Végül, ha többet szeretnél megtudni erről , a részleteket az alábbi linken találod.


Hozzáadás előnyben részesített forrásként a Google-ben