A Linux biztonsága újabb kihívással néz szembe a CVE-2026-31431 sebezhetőség felfedezését követően , amelyet az Xint Code kutatói „Másolási hiba”-nak neveztek el . Ez a tervezési probléma messze nem elméleti hiba, hanem lehetővé teszi egy privilégiumokkal nem rendelkező helyi felhasználó számára, hogy előre láthatóan és csendben eszkalálja jogosultságait, és teljes superuser hozzáférést szerezzen .
A kutatók megemlítik, hogy ezt a hibát sikeresen kihasználták olyan vezető disztribúciókban, mint az Ubuntu, az Amazon Linux, a RHEL és a SUSE, megerősítve, hogy minden olyan rendszer, amely a 4.14-es verziónál újabb kernelt futtat, és továbbra is támogatja az AF_ALG socketeket, potenciálisan sebezhető a támadással szemben.
Helyi műveletek és az oldal gyorsítótárának túlcsordulása
A sebezhetőséget illetően megemlítik, hogy az egy 2017-ben a kernel kriptográfiai API-jában (AF_ALG) bevezetett optimalizálásra vezethető vissza. A módosítás célja a felesleges pufferelés kiküszöbölése volt azáltal, hogy hitelesített titkosítási műveleteket (AEAD) hajtottak végre közvetlenül ugyanabban a memóriaterületen, ezeket „helybeni” műveleteknek nevezik.
A kritikus probléma akkor merül fel, amikor ezt az optimalizálást a splice() függvénnyel kombináljuk, amely a fájlleírók közötti adatátvitelt a kernel oldal gyorsítótárába történő közvetlen hivatkozások átvitelével végzi, ahelyett, hogy fizikailag másolja az adatokat. A visszafejtés kérésekor a memóriaszerkezetet úgy konfigurálták, hogy a célpuffer, amelynek a felhasználó számára ideiglenes területnek kellett volna lennie, közvetlenül a rendszerfájl-adatokat tartalmazó gyorsítótár-oldalakhoz kapcsolódott.
Hitelesítés és írás a memória korlátain kívül
A sebezhetőség végső kiváltó oka az authencesn algoritmus anomáliás viselkedésében rejlik. Más kriptográfiai rutinokkal ellentétben, amelyek szigorúan tiszteletben tartják a célpuffereik határait, ez a specifikus algoritmus a felhasználói memóriát ideiglenes munkaterületként (munkaterületként) használja a bájtsorozatok átrendezésére a hitelesítési címkék kiszámítása során.
Ebben a folyamatban az algoritmus négy bájttal túlra ír a kimeneti régióban meghatározott határon. A helyben optimalizálás és a splice() által létrehozott referencialánc miatt ez a látszólag ártalmatlan írási művelet átlépi a felhasználói memória határát , és közvetlenül a feldolgozott fájlhoz társított kernel gyorsítótár-oldalra kerül.
Ez a logikai hibákból álló láncolat lehetővé teszi a támadó számára, hogy tetszőlegesen felülírjon négy bájtot az oldal gyorsítótárának meghatározott pozícióiban bármely fájl esetében, amelyet be tud olvasni. Számított kérések sorozatának küldésével a támadó rosszindulatú kódot juttathat a beállított suid bittel rendelkező kritikus végrehajtható fájlok memóriában tárolt verziójába, például a felhasználóváltó eszközbe.
Mivel minden olvasási művelet először az oldal gyorsítótárát kérdezi le, a legitim segédprogram következő meghívásakor a rendszer a memóriából végrehajtja a befecskendezett kódot, azonnali root jogosultságokat biztosítva anélkül, hogy a merevlemezen lévő fizikai fájlt módosítaná. Még aggasztóbb, hogy mivel a konténer izolációja megosztja az alapul szolgáló gazdagép oldal gyorsítótárát, ez a sebezhetőség közvetlen átjáróként szolgál a virtualizált környezetekből, például a Kubernetes klaszterekből való kilépéshez és az elsődleges csomópont feltöréséhez.
Vészhelyzeti javítások és enyhítő megoldások
A hiba súlyossága miatt a karbantartó csapatok sürgősségi frissítéseket telepítettek, ahol a végleges megoldás az algif_aead.c fájlon belüli helybeni optimalizálás visszaállítása, a forrás- és célmemória-listák szigorú elkülönítése, hogy megakadályozzák a gyorsítótár-lapok írható elérési utakra kerülését.
Ezek a javítások már integrálva lettek a 6.18.22, 6.19.12 és 7.0 kernelekbe, és jelenleg visszaportolásra kerülnek a hosszú távú támogatási ágakba. Azoknak a rendszergazdáknak, akik nem tudják azonnal újraindítani vagy frissíteni a szervereiket, ajánlott letiltani az algif_aead kernel modult, ha azt külsőleg fordították, vagy szigorúan korlátozni az AF_ALG socketek létrehozását olyan biztonsági házirendek használatával, mint például a SELinux, egy olyan pajzs, amely például a jelenlegi Android-eszközöket védte ettől a fenyegetéstől.
Végül, ha további részletekre vagy kíváncsi, a következő linken megtalálod a részleteket.