A Cloudflare kijavított egy sérülékenységet, amely lehetővé tette, hogy fizetős ügyfelek a megosztott konténeres infrastruktúrán más ügyfelek után visszamaradt adatokat nyerjenek vissza.
A vállalat szeptember 24-i közlése szerint a rendelkezésére álló korábbi telemetriai adatokban nem talált rosszindulatú kihasználásra utaló bizonyítékot, és az ügyfeleknek nincs teendőjük.
A Cloudflare incidensjelentésében részletezett probléma az ügyfelek tárolt adatainak elkülönítését érintette. Az eset rámutat arra, hogy a szolgáltatói számítási környezetek biztonsága attól is függ, mi történik a tárolóval egy feladat befejezése után — a futás közbeni védelem önmagában nem elegendő.
Érzékeny fájlokhoz való hozzáférést igazoltak a kutatók
Az Accomplish beszámolójában Oren Yomtov vezető biztonsági kutató azt írta, hogy csapatuk olyan lemezelkülönítési hibát talált, amely lehetővé tette egy elkülönített futtatókörnyezet, vagyis sandbox számára más ügyfelek fájljainak olvasását.
A jelentésben szereplő adatok között az alábbiak voltak:
- könyvtárlisták;
- SQLite-adatbázisok;
- Chromium-böngészőprofilok;
- környezeti beállításokat tartalmazó
.envfájlok; - hitelesítő adatokat tartalmazó fájlok.
Az Accomplish szerint a Cloudflare Sandboxes és a Browser Run ugyanazt az érintett lemezkezelési megoldást használta. A kutatók szeptember 4-én jelentették a hibát, majd a Cloudflare-rel együttműködve készítették el a technikai magyarázatot. A felfedezésről az Accomplish kutatói beszámolója tájékoztat.
Ezek az adatkategóriák különösen fontossá teszik a megállapítást a bizalmas információkat kezelő alkalmazásokat futtató szervezetek számára. Tartalmuktól függően a konfigurációs és hitelesítési fájlok alkalmazásbeállításokat, hozzáférési kulcsokat vagy más titkos adatokat fedhetnek fel. A böngészőprofilok és adatbázisok pedig felhasználói munkamenetek vagy alkalmazásfolyamatok során keletkezett információkat tárolhatnak.
Ezek az ilyen fájlok hozzáférhetővé válásának lehetséges következményei. A fájlok jelenléte önmagában nem bizonyítja, hogy használható hitelesítő adatot loptak el vagy felhasználói fiókot törtek fel.
A kutatás az adatok bizalmasságát sértő hibát igazolta. Nem bizonyította, hogy bűnözők is megszerezték ugyanezeket az információkat.
Hogyan okozott adatkitettséget a tároló újrafelhasználása?
A Cloudflare a problémát a skip_block_zeroing beállításra vezette vissza. Ennek következtében egy 4 KiB méretű írás után a kiosztott, 64 KiB méretű tárolóblokk fennmaradó 60 KiB-os része korábbi adatokat tartalmazhatott.
A támadók nem választhattak ki konkrét áldozatot, és nem olvashattak egy másik ügyfél aktívan csatlakoztatott lemezéről. A hozzáférés attól függött, hogy a rendszer melyik gazdagépen helyezte el a munkaterhelést, és mely korábban felszabadított blokkokat osztotta ki újra.
A Linux kernel vékony tárhelykiosztásról, vagyis thin provisioningről szóló dokumentációja ismerteti az alapul szolgáló tárolási mechanizmust. A skip_block_zeroing olyan opció, amely kihagyja az újonnan kiosztott blokkok nullázását.
A thin provisioning lehetővé teszi, hogy a virtuális tárolók mögé csak szükség szerint rendeljenek fizikai kapacitást, miközben több kötet ugyanabból a közös tárolókészletből kap helyet.
Biztonsági szempontból a tárhely kiosztása és korábbi tartalmának eltávolítása két külön művelet. Amikor egy blokkot új feladathoz rendelnek, megváltozik, ki férhet hozzá. A blokk nullázása határozza meg, hogy az előző feladatból visszamaradt információ látható marad-e.
Kis mennyiségű új adat kiírása például nem írja felül automatikusan egy nagyobb tárolóblokk minden bájtját. Ha az érintetlen rész régi adatokat tartalmaz, egy későbbi olvasás olyan tartalmat is visszaadhat, amelyet az új környezet soha nem hozott létre.
A fájlrendszer által szabadnak tekintett terület és a mögöttes eszköz tényleges tartalma ezért nem ugyanaz.
A Linux dokumentációja külön konfigurálható működésként kezeli a tároló-hozzárendelések eldobását és a felszabadítási, úgynevezett discard kérések továbbítását a mögöttes eszközökhöz is.
Ez az adattörlési garanciák értékelésénél fontos: a lefoglalt terület felszabadítása, a hozzárendelés megszüntetése és a korábbi tartalom visszaállíthatatlanná tétele külön mérnöki feladat.
Miért nem old meg minden elkülönítési problémát a virtuális gép?
A Firecracker tervezési dokumentációja bemutatja, hogyan ötvözik a mikrovirtuális gépek az alacsony erőforrásigényű futtatást a virtuális gépek által biztosított elkülönítéssel.
A megoldás több védelmi rétegre épül, köztük a KVM-re, a rendszerhívások korlátozására, az erőforrás-szabályozásra és a jogosultságokat csökkentő jailer folyamatra.
A virtuális gépnek azonban a gazdagép által biztosított tárolóra is szüksége van. A Firecracker dokumentációja olyan vendégoldali blokkeszközöket ismertet, amelyek mögött a gazdagépen található fájlok állnak. Ez jól szemlélteti a virtualizációs védelem és a platform által csatlakoztatott erőforrások közötti kapcsolatot.
Az architektúrából levonható tanulság az, hogy egy futtatott alkalmazás egy egyébként szabályosan hozzárendelt erőforráson keresztül is megkaphat olyan információt, amelyhez nem lenne szabad hozzáférnie.
A gazdagép védelme a vendégkóddal szemben és annak biztosítása, hogy a vendéggép lemeze kizárólag engedélyezett adatokat tartalmazzon, két külön felelősség.
A biztonsági értékelés során ezért nem elegendő azt vizsgálni, hogy a futtatott kód ki tud-e törni a környezetéből. A tároló előkészítésének, újrafelhasználásának, pillanatképeinek és megtisztításának is az elkülönítési vizsgálat részét kell képeznie.
Ez az architektúrából és a nyilvánosságra hozott hibából következő megállapítás, nem pedig egy további sérülékenység bizonyítéka.
A javításhoz egy konfigurációs módosításnál többre volt szükség
A Cloudflare visszaállította a blokkok nullázását, valamint kivonta a használatból a javítás előtt létrehozott konténerlemezeket és gyorsítótárazott lemezkép-pillanatképeket.
A módosítások bevezetése szeptember 7-én fejeződött be, a korábbi gyorsítótárazott pillanatképek eltávolítását pedig szeptember 19-én zárták le. A kutatók megerősítették, hogy a sérülékenységet demonstráló eljárásuk a javítás után már nem működött. Az időrendet a Cloudflare hivatalos incidensjelentése részletezi.
Az új adatkitettség megakadályozása és a korábban létrejött, nem biztonságos állapot megszüntetése közötti különbségnek általános üzemeltetési jelentősége is van.
Egy konfigurációs javítás megváltoztathatja a rendszer jövőbeli működését, miközben a már meglévő erőforrásokat érintetlenül hagyja. Az incidens utáni helyreállításnak ezért a módosítás előtt létrehozott objektumokra is ki kell terjednie, beleértve az újrafelhasználható lemezképeket és a gyorsítótárazott állapotokat.
A szolgáltató válaszlépéseit értékelő felhőügyfelek számára hasznos kérdés, hogy a helyreállítás az új erőforrások létrehozását és a korábban elkészült erőforrásokat egyaránt lefedi-e.
A javítás telepítésének dátuma és a megtisztítás befejezésének időpontja a helyreállítás két külön szakaszát jelölheti.
Miért fontos ez az AI-ügynökök és fejlesztői platformok számára?
A feltárt probléma azokat a szolgáltatásokat is érinti, amelyek felhasználók nevében futtatnak kódot.
A Cloudflare Sandbox dokumentációja a felhasználási lehetőségek között említi az AI-ügynököket, az adatelemzést, az interaktív fejlesztői környezeteket és az automatizált szoftverfordítási folyamatokat. A platform parancsvégrehajtást, fájlműveleteket, háttérfolyamatokat és a futtatási állapot megőrzését is támogatja.
Ezek a képességek megmagyarázzák, miért kell a sandboxon belüli adatok bizalmasságát is védeni a kód elkülönítése mellett.
Egy fejlesztői környezet forráskódot dolgozhat fel, egy adatelemzési munkamenet üzleti nyilvántartásokat tölthet be, egy automatizált munkafolyamat pedig köztes fájlokat hozhat létre. Ezek példák az ilyen alkalmazásokban előforduló információkra, nem a kutatók által visszanyert adatok megerősített tartalmai.
Ugyanez a dokumentáció olyan kimenőforgalom-kezelési megoldást is ismertet, amely a hitelesítő adatokat egy Cloudflare Workerben tartja, és a hitelesítési fejléceket a sandboxon kívül adja hozzá a kérésekhez.
Architekturális szempontból a titkos adatok futtatókörnyezeten kívüli tárolása csökkenti azoknak a helyeknek a számát, ahol ezek az információk hozzáférhetővé válhatnak.
Ez a megközelítés nem javítja ki a szolgáltató tárolóelkülönítési hibáját. Csökkentheti viszont a nem megbízható kódot rendszeresen feldolgozó környezetekben elhelyezett érzékeny adatok mennyiségét.
Mit érdemes ellenőrizniük a biztonsági csapatoknak?
A közlemény konkrét szempontot ad a vállalati biztonsági csapatok beszállítói értékeléseihez: hogyan akadályozza meg a megosztott infrastruktúra, hogy egy erőforrás előző ügyfelének adatai a következő ügyfél számára is hozzáférhetők maradjanak?
Az adattörléssel kapcsolatos kérdéseknek az erőforrás teljes életciklusát le kell fedniük:
- Mi történik, amikor a futtatókörnyezet leáll?
- Milyen pillanatképek vagy gyorsítótárak maradnak meg?
- Mikor nullázzák az újra felhasznált tárolókapacitást?
- Hogyan tesztelik ezt olyan futtatott kóddal, amely kifejezetten visszamaradt adatokat keres?
A vizsgálat eredményeit is körültekintően kell értelmezni. Az a közlés, hogy a szolgáltató nem talált rosszindulatú kihasználásra utaló bizonyítékot, a vizsgálata eredményét írja le.
Ez nem teszi ártalmatlanná a bizonyított adatkitettséget. Ugyanakkor a hiba létezése sem bizonyítja, hogy minden ügyfelet adatvédelmi incidens ért.
Az eset átfogó tanulsága, hogy az elkülönítésnek az időben egymást követő feladatok között is fenn kell maradnia, nem csupán az egyszerre futó környezetek között.
A megosztott felhőinfrastruktúrának ugyanolyan megbízhatóan kell megakadályoznia, hogy az előző ügyfél adatai a következőhöz kerüljenek, mint ahogyan egymástól elválasztja a párhuzamosan futó alkalmazásaikat.
Az eredeti cikk címe: „Cloudflare Fixes Critical Flaw Exposing Customers’ Container Data”.
