A Dell biztonsági frissítéseket adott ki a Container Storage Modules (CSM) szoftverhez, miután olyan sérülékenységeket hozott nyilvánosságra, amelyek lehetővé tehetik a Kubernetes-alkalmazásokat vállalati tárolórendszerekkel összekapcsoló infrastruktúra kompromittálását.
Két hiba a maximális, 10,0 pontos CVSS-besorolást kapta. Ezek a tárolóhozzáférés szabályozásáért felelős CSM Authorization modult érintik. További kritikus sérülékenységek a Kubernetes-fürtök jogosultságait, a hitelesítési tokeneket és az érzékeny hozzáférési adatokat veszélyeztetik.
A Dell október 1-jén tette közzé a biztonsági közleményt. Az eredeti cikk megjelenésekor a vállalat nem jelezte, hogy a hibákat aktívan kihasználnák. Ez lényeges különbség: a közzétett információk súlyos támadási lehetőségeket írnak le, de önmagukban nem bizonyítják, hogy ügyfelek rendszereit már támadás érte.
A lehetséges következmények túlmutatnak az infrastruktúrát üzemeltető csapatok feladatain. A tárolószolgáltatások az üzleti alkalmazások rendelkezésre állásának és adatintegritásának alapját képezik. A hozzáférésüket szabályozó rendszer hibája egyszerre több alkalmazást is érinthet, ezért a telepítés kiterjedése legalább olyan fontos a válaszintézkedések meghatározásakor, mint a súlyossági pontszám.
Milyen környezeteket érintenek a Dell CSM-hibák?
A CSM nyílt forráskódú, Kuberneteshez készült tárolókomponensek gyűjteménye. A Dell projektje a PowerStore, PowerScale, PowerFlex, PowerMax és Unity rendszerekhez kínál illesztőprogramokat, valamint jogosultságkezelési, megfigyelhetőségi, replikációs és hibatűrési modulokat.
Az üzemeltetőknek az ezeket a környezeteket összekapcsoló és kezelő szoftvereket kell felmérniük. Önmagában egy Dell tárolóeszköz használata még nem jelenti azt, hogy a szervezet érintett.
A Dell dokumentációja szerint az Authorization modul egy proxyt helyez a Container Storage Interface, vagyis CSI-illesztőprogram és a tárolórendszer közé. Az adminisztrátorok ezen keresztül érvényesíthetik a szerepköralapú jogosultságokat és a tárolási kvótákat. A megoldás lehetővé teszi, hogy az elkülönített felhasználói környezetek igénybe vegyék az erőforrásokat anélkül, hogy megkapnák a tárolórendszer adminisztrátori hitelesítési adatait. Dell: CSM Authorization dokumentáció
Ez az architektúra magyarázza a sérülékenységek jelentőségét. A komponens feladata éppen az alkalmazások felhasználói és a kiemelt jogosultságú tárolókezelés közötti határ fenntartása. A kockázatértékelés során ezért azt is vizsgálni kell, milyen erőforrások felett rendelkezik, és milyen hozzáférési adatokat kezel.
Két sérülékenység is 10 pontos besorolást kapott
A két legsúlyosabb hiba eltérő módon veszélyezteti ezt a biztonsági határt.
A CVE-2026-63688 egy hitelesítést nélkülöző gRPC-szolgáltatáson keresztül hozzáférhetővé teheti a regisztrált tárolórendszerek adminisztrátori hitelesítési adatait. A CVE-2026-63692 szintén hiányzó hitelesítéshez kapcsolódik, és jogosultságkiterjesztést tehet lehetővé.
További négy kritikus sérülékenység szélesíti a kockázatot:
| Sérülékenység | CVSS-pontszám | Fő kockázat |
|---|---|---|
| CVE-2026-63688 | 10,0 | Tárolórendszerek adminisztrátori hitelesítési adatainak jogosulatlan elérése |
| CVE-2026-63692 | 10,0 | Hiányzó hitelesítésből eredő jogosultságkiterjesztés |
| CVE-2026-67269 | 9,9 | Alacsony jogosultságú támadó root szintű hozzáférést szerezhet a fürt csomópontjain |
| CVE-2026-54472 | 9,8 | Beégetett hitelesítési adatokból eredő információkiszivárgás |
| CVE-2026-61421 | 9,8 | Beégetett hitelesítési adatokkal összefüggő jogosultságkiterjesztés |
| CVE-2026-67273 | 9,6 | Sablonfeldolgozási hibából eredő jogosultságkiterjesztés |
A pontszámokat és a hibák aktuális gyártói besorolását a Dell DSA-2026-448 biztonsági közleménye tartalmazza.
Az eredeti beszámoló részletesebben is ismerteti egyes hibák lehetséges következményeit. A CVE-2026-67273 esetében fürtszintű Secret-olvasást és RBAC-erőforrások létrehozását említi, a beégetett hitelesítési adatokkal kapcsolatos hibáknál pedig adminisztrátori tokenek hamisításának kockázatát.
A frissítés mellett a hitelesítési adatokat is kezelni kell
Az eredeti közleményről szóló beszámoló a CVE-2026-54472 kapcsán a JWT-tokenek aláírásához használt titok azonnali cseréjét emelte ki. A korábbi karavi-authorization megoldásnál külön kockázatot jelenthet, ha egy telepítés a dokumentációban szereplő aláírási titkot használja.
Ez a hitelesítési adatok kezelését önálló üzemeltetési feladattá teszi. A sérülékeny szoftver lecserélése általában nem érvényteleníti automatikusan azokat a hozzáférési adatokat, amelyeket más rendszerek továbbra is elfogadnak.
Az érintettséget vizsgáló csapatoknak meg kell állapítaniuk, mely rendszerek használják az egyes hitelesítési adatokat, hogyan jutnak el hozzájuk az új értékek, és szükséges-e a korábban kiadott tokenek érvénytelenítése.
Ezek incidenskezelési szempontok, és nem bizonyítják, hogy ebben az esetben hitelesítési adatokat loptak el.
Miért jelent különösen nagy kockázatot a Kubernetes Secrets elérése?
A Kubernetes Secret objektumai többek között jelszavakat, OAuth-tokeneket és SSH-kulcsokat tárolhatnak. Egy megszerzett hitelesítési adat értékét az határozza meg, milyen erőforráshoz biztosít hozzáférést. Az adatszivárgás következménye ezért túlterjedhet azon az alkalmazáson, amely eredetileg tárolta.
A Kubernetes biztonsági útmutatója a Secrets-adatok tárolás közbeni titkosítását és az olvasási jogosultságok korlátozását javasolja. Arra is figyelmeztet, hogy a Secret objektumok listázására jogosult felhasználó azok tartalmához is hozzáférhet. Aki pedig létrehozhat egy Secretet felhasználó podot, közvetve szintén megszerezheti annak értékét.
Az ajánlások között szerepel a rövid élettartamú titkok használata és olyan auditálási szabályok kialakítása is, amelyek segítenek felismerni például több Secret egy felhasználó általi párhuzamos olvasását. Kubernetes: a Secrets biztonságos kezelésének gyakorlatai
Az incidenskezelők számára ebből a függőségek feltérképezésének szükségessége következik. Jogosulatlan hozzáférésre utaló bizonyíték esetén meg kell állapítani, milyen hitelesítési adatok voltak elérhetők, és mely szolgáltatások fogadták el azokat.
Egy alkalmazás újraindítása önmagában nem ad választ arra, hogy egy külső fiók vagy tárolórendszer továbbra is hozzáférhető maradt-e a támadó számára.
A belső hálózat és az alacsony jogosultság sem jelent automatikus védelmet
A hitelesítés nélkül, illetve alacsony jogosultsággal kihasználható hibák közötti különbség a prioritásokat is befolyásolja.
A szervezeteknek egyszerre kell áttekinteniük a tárolókezelési szolgáltatások hálózati elérhetőségét és a fürtön belüli felhasználóknak, illetve automatizmusoknak adott jogosultságokat. Egy belső telepítés is veszélyeztetett lehet, ha kevésbé megbízható alkalmazások vagy fiókok elérhetik a kiemelt jogosultságú komponenseket.
A Kubernetes RBAC-útmutatója a szükséges minimumra korlátozott hozzáférést, lehetőség szerint névtérszintű jogosultságokat, valamint a helyettesítő karakterekkel megadott, túl tág engedélyek kerülését javasolja. Emellett korlátozni kell a nagy jogosultságú szolgáltatásfiókok tokenjeinek használatát, és el kell különíteni a privilegizált alkalmazásokat a nem megbízható vagy nyilvánosan elérhető feladatoktól. Kubernetes: RBAC biztonsági gyakorlatok
Ezek az elvek az érintett környezet felülvizsgálatához is használhatók. Az adminisztrátoroknak érdemes ellenőrizniük, ki hozhat létre erőforrásokat, mely szolgáltatásfiókok rendelkeznek széles körű hozzáféréssel, és szükség van-e még a régebbi telepítésekhez megadott engedélyekre.
A jogosultságok felülvizsgálata kiegészíti a javítást, de nem szünteti meg a sérülékeny kód hibáját.
A hálózati elkülönítést ténylegesen ellenőrizni kell
A hálózati szegmentáció szintén figyelmet igényel. A Kubernetes több-bérlős környezetekről szóló dokumentációja szerint a podok alapértelmezésben kommunikálhatnak egymással.
Szigorú elkülönítést igénylő környezetben korlátozó hálózati szabályzatokból célszerű kiindulni, majd kifejezetten engedélyezni a szükséges kapcsolatokat. Ehhez olyan hálózati bővítmény szükséges, amely ténylegesen támogatja a szabályok érvényesítését. Kubernetes: több-bérlős környezetek biztonsága
A tárolóinfrastruktúrára alkalmazva ez azt jelenti, hogy a csapatoknak a valós elérhetőséget kell ellenőrizniük. Meg kell vizsgálni, mely alkalmazások léphetnek kapcsolatba a kezelési szolgáltatásokkal, és ezek az útvonalak megfelelnek-e a tervezett biztonsági határoknak.
Az ideiglenes hozzáférési korlátozásokat a szabályos tárolóműveletekkel együtt kell tesztelni, hogy a védekezés ne okozzon szükségtelen szolgáltatáskiesést.
Melyik Dell CSM-verzió tartalmazza a javítást?
A Dell aktualizált közleménye alapján az érintettség és a javítás a következő:
| Termék | Érintett kiadások | Javított kiadások |
|---|---|---|
| Dell Container Storage Modules | Az 1.18.0 előtti verziók | 1.18.0 vagy újabb |
Az október 2-i eredeti beszámoló még eltérést jelzett az érintett verziók táblázata és az egyes hibaleírások között. A Dell október 5-én módosította a verzióleírásokat; a jelenlegi közlemény már egységesen az 1.18.0 előtti kiadásokat nevezi meg érintettként. Dell: érintett termékek, javítás és módosítási előzmények
Az eredeti tájékoztatás nem adott meg kerülőmegoldást. Az üzemeltetőknek ezért a gyártó által javított kiadásra történő frissítést kell megtervezniük, a hozzáférési korlátozásokat pedig kiegészítő intézkedésként kezelniük.
A rendezett válaszlépések alapja a telepített modulok, komponensverziók és kapcsolódó tárolóerőforrások pontos leltára. A Kubernetes-platform és a tárolórendszerek adminisztrátorainak össze kell hangolniuk a frissítést, a hitelesítési adatok cseréjét és az alkalmazások hozzáférésének ellenőrzését.
Ha kompromittálódás gyanúja merül fel, a biztonsági csapatoknak meg kell őrizniük a releváns naplókat és nyilvántartásokat, valamint ki kell vizsgálniuk a megmagyarázhatatlan adminisztrációs változtatásokat.
A maximális súlyosság sürgős intézkedést indokol
A 10 pontos CVSS-besorolás erős jelzés a javítási sorrend meghatározásakor, de nem azt becsüli meg, mekkora eséllyel támadnak meg egy konkrét szervezetet. Az alappontszám a sérülékenység jellemzőit írja le; a tényleges kockázat megítéléséhez a kitettséget, a fenyegetési információkat és a helyi környezetet is figyelembe kell venni.
A döntéshozóknak ezért négy konkrét kérdésre kell választ kapniuk: hol fut az érintett szoftver, milyen erőforrásokat kezel, kik érhetik el, és milyen gyorsan telepíthető a javítás?
Ezek alapján a védekezés azokra a telepítésekre összpontosíthat, ahol egy sikeres támadás a legsúlyosabb üzleti következményekkel járna. A sürgős frissítés indokolt, miközben a rendelkezésre álló információk alapján továbbra sem szabad bizonyítottnak tekinteni egy folyamatban lévő támadási kampányt.
Az eredeti angol cikk címe: Dell Issues Emergency Update For Maximum-Severity Flaws
