Sió-Informatika Rendszerház

Az Anthropic kutatói egy Linux-kernelhiba kihasználásával távolról, hitelesítés nélkül futtattak általuk választott parancsot egy tesztszerveren, root jogosultsággal. A bemutatott támadáshoz olyan elérhető szolgáltatás kellett, amely Multipath TCP- (MPTCP-) kapcsolatokat fogadott. A CVE-2026-98432 azonosítójú hiba azonban az általános IPv4 TCP-kapcsolatkezelésben található. Az MPTCP hiánya ezért nem bizonyítja, hogy a gép védett. Az Anthropic kutatói beszámolója · A Go biztonsági csapatának figyelmeztetése

Az Ubuntu a sérülékenységhez 9,8-as, kritikus CVSS-pontszámot közöl, miközben saját javítási prioritását High, azaz magas szintre sorolja. A két besorolás mást mér. Az üzemeltető szempontjából a döntő kérdés az, hogy melyik kernel dolgozza fel a beérkező kapcsolatokat, és tartalmazza-e a javítást. Ezt a webalkalmazás vagy a webszerver verziószáma nem árulja el. Az Ubuntu CVE-adatlapja

Hogyan használhat a kernel már felszabadított memóriát?

Amikor egy TCP-kapcsolat létrejön, a Linux kernel a függőben lévő kapcsolódási kéréshez tartozó IPv4-opciókat átadja az új kapcsolatot képviselő socketnek. Eközben egy másik processzormag még ugyanannak a kapcsolódási kérésnek az újraküldött példányát dolgozhatja fel: a válasz előkészítéséhez továbbra is olvassa ezeket az opciókat.

A hiba akkor jelentkezhet, ha az új socket időközben megszűnik, és a kernel felszabadítja az opciókat tároló memóriát, mielőtt a másik processzormag befejezné az olvasást. Ez felszabadítás utáni memóriahasználat (use-after-free). A hibát a párhuzamos műveletek sorrendje váltja ki, ezért nevezik versenyhelyzetnek. A sérülékenység leírása a függőben lévő kapcsolódási kérések áthelyezésekor fellépő, rokon versenyhelyzetet is azonosít. A kernelhibát ismertető CVE-rekord

A javítás lényege, hogy a kernel nem szabadítja fel azonnal ezt a memóriát. A read-copy-update (RCU) mechanizmus türelmi ideje alatt a már folyamatban lévő olvasások befejeződhetnek, mielőtt a memóriaterületet a rendszer újra felhasználná. A hiba egy Linux 4.4-ben bevezetett változtatásig vezethető vissza. A verzióhatár önmagában mégsem elegendő a helyi állapot megítéléséhez: a disztribúciók a javítást régebbi verziószámú kernelcsomagokba is átültethetik. A Debian biztonsági adatlapja és a javítás leírása

Mit bizonyított az Anthropic, és mit jelent a közel egyórás futási idő?

Október 27-i beszámolója szerint az Anthropic egy nyilvánosan nem elérhető, belső Claude-kutatómodellt használt. A modell a kezdeti utasítások után működő kihasználási módszert készített. A demonstráció első szakaszában sikerült kiolvasni egy kernelmemória-címet, amellyel megkerülték a kernel címterének véletlenszerű elrendezését biztosító KASLR-védelmet. Ezt követően eltérítették a kernel végrehajtását, és root jogosultsággal futtattak egy választott parancsot. Az Anthropic eredeti demonstrációja

A tesztben mintegy 48 perc kellett a kernelcím megszerzéséhez, majd további öt perc a parancs futtatásához. Ez a már elkészült támadás végrehajtási ideje volt. Nem azt mérték, mennyi idő alatt találta meg a modell a hibát vagy fejlesztette ki a módszert.

A kutatók szerint a tesztelt versenyhelyzet sikertelen kiváltásakor meghiúsulhatott a TCP-kézfogás anélkül, hogy a teljes rendszer összeomlott volna. Így volt lehetőség újabb próbálkozásokra. Az eredmény igazolja a távoli kódfuttatást a vizsgált konfigurációban, de nem ad általános időbecslést más szerverekre: a hardver, a kernel összeállítása, a hálózati körülmények és a szolgáltatás beállításai is eltérhetnek.

Miért érdemes a Go-alapú szolgáltatásokat külön is ellenőrizni?

Az MPTCP lehetővé teszi, hogy egy kapcsolat több hálózati útvonalat használjon. A szerveren ehhez MPTCP-kapcsolatokat fogadó socket működhet. Ilyen socket akkor is létrejöhet, ha az üzemeltető tudatosan soha nem állított be többútvonalas hálózatot: a Go 1.24-től a net.ListenConfig alapértelmezésben MPTCP-t használ ott, ahol az operációs rendszer támogatja. A változás bevezetésekor ez a Linuxot jelentette. A Go 1.24 kiadási jegyzéke

A GODEBUG=multipathtcp=0 beállítással a Go-programoknál alapértelmezésben kikapcsolható az MPTCP a kimenő és a bejövő kapcsolatokhoz. Az alkalmazás azonban a hálózati programozási felületen kifejezetten felülbírálhatja ezt az alapértéket. A beállítás átírása után ezért a futó szolgáltatás tényleges socketjeit is ellenőrizni kell. A Go biztonsági csapatának útmutatója

A Go biztonsági csapata két okból sem tekinti teljes védelemnek a programonkénti kikapcsolást. Egyetlen kihagyott, elérhető MPTCP-szolgáltatás is megőrizheti a bemutatott támadási útvonalat. Ezenfelül a sérülékenység az IPv4 TCP-kódban van, így más kihasználási módszer MPTCP nélkül is lehetséges lehet. A Red Hat külön hangsúlyozza, hogy a RHEL alapértelmezésben kikapcsolt MPTCP mellett is érintett. Az MPTCP-vizsgálat tehát a javítási sorrend felállításában segít; a sérülékeny kernel kijavítását nem helyettesíti. A Red Hat műszaki közleménye

Hol érhető el javított kernel?

Az upstream javítás bekerült a karbantartott stabil kernelágakba, de ettől még nem frissült automatikusan minden disztribúciós csomag, felhős gépkép vagy működő szerver. A november 4-én ellenőrzött szállítói nyilvántartások alapján a következő különbségek fontosak:

A táblázat a csomagok elérhetőségét mutatja, nem a telepített gépek állapotát. Egy frissítés például már letölthető lehet a biztonsági tárolóból úgy, hogy a kiszolgáló még a korábbi kernellel fut. Ugyanezért egy régebbinek látszó upstream verziószám sem bizonyítja önmagában a sérülékenységet: a szállító által visszaültetett javítást a teljes csomagazonosító alapján lehet igazolni.

A működő demonstráció nem azonos egy észlelt támadási kampánnyal

Az Anthropic közlése bizonyítja, hogy a hiba megfelelő körülmények között távoli, root szintű parancsvégrehajtásra használható. Az itt hivatkozott elsődleges közleményekből viszont nem következik, hogy azonosított támadócsoport használná ezt a módszert, zsarolóprogramot terjesztenének vele, vagy széles körű sikeres behatolás történt volna. Ezekhez külön incidensbizonyíték szükséges. Az Anthropic kutatási eredményei · Az AWS biztonsági tájékoztatója

A javítást ettől függetlenül indokolt előrevenni. A kernel hálózaton elérhető kódja sérülékeny, a legsúlyosabb hatást tesztben igazolták, és egyes csomagágaknál a javítás még készül. Az ismert demonstráció feltételei segítenek a sorrend meghatározásában, de nem jelölik ki a kockázat teljes határát.

Mit ellenőrizzenek most az üzemeltetők?

1. A futó kernelt és a hozzá tartozó csomagot azonosítsák. A uname -r megmutatja az aktív kernel kiadását. Ezt az adott disztribúció teljes csomagazonosítójával és biztonsági közleményével kell összevetni, a felhős és egyedi kernelváltozatokat is beleértve.
2. A kívülről elérhető és üzletileg kritikus szervereket vegyék előre. Térképezzék fel, mely IPv4 TCP-szolgáltatások érhetők el nem megbízható hálózatból. Az ss -Mlnp segíthet megtalálni az MPTCP-kapcsolatokat fogadó szolgáltatásokat. Az üres találati lista nem igazolja, hogy a kernel védett. A Red Hat magyarázata az MPTCP-ellenőrzés korlátairól
3. A javítást aktiválják is. Telepítsék a szállító megfelelő csomagját, szükség esetén indítsák újra a gépet, majd ellenőrizzék a futó kernelt és a fontos szolgáltatások működését. A csomagkezelő sikeres visszajelzése nem bizonyítja, hogy az új kernel már átvette a beérkező kapcsolatok feldolgozását.
4. A még nem javítható gépeknél szűkítsék a hálózati elérést. Tiltsák le a szükségtelenül elérhető szolgáltatásokat, és ahol lehetséges, korlátozzák, honnan fogadhatók kapcsolatok. A konkrét forgalomszűrésnél kövessék a szállító útmutatóját: a szűrés legitim forgalmat is érinthet. Az ideiglenes intézkedéshez tartozzon felelős és következő ellenőrzési időpont. A Red Hat átmeneti intézkedései
5. A gyanús eseményeket külön vizsgálják ki. A váratlan kernelösszeomlásokat, szokatlan hálózati aktivitást és jogosulatlan emelt szintű parancsvégrehajtást érdemes időben összevetni. Ezek vizsgálati támpontok, nem a CVE-2026-98432 egyedi bizonyítékai. Az összeomlás hiánya sem zárja ki a próbálkozást: a kutatói tesztben egy sikertelen kísérlet csupán a kézfogás meghiúsulásával járhatott.

Ennél a hibánál a helyreállítás döntő bizonyítéka az, hogy a beérkező TCP-kapcsolatokat már igazoltan javított kernel kezeli. Egy alkalmazásfrissítés, egy eltűnt MPTCP-listener vagy egy ideiglenes tűzfalszabály önmagában ezt nem igazolja.

Eredeti cím: Critical Linux Kernel Flaw Enables Remote Root Attacks