Masszív sebezhetőség a UNIX-rendszerekben
Szerveres operációs rendszereket tesz sebezhetővé az új Stack Clash problémacsokor. Frissíteni (és újraindítani) kötelező, de elvben van ideiglenes elhárításra is lehetőség.
"Ha a heap felfelé növekszik, a stack viszont lefelé terjeszkedik, akkor mi történik, ha összeérnek? És kihasználható-e ez támadáshoz? Hogyan?" - így kezdődik a Qualys új beszámolója a Stack Clash névre keresztelt sebezhetőségcsomag kapcsán. A problémát már legalább 12 éve kutatják különböző csapatok, elsősorban kernel-space szintjén, a Qualys-csapat azonban most néhány komoly hibára talált rá a user-space-ben is.
Halom? Verem!
Nagy vonalakban a heap és a stack elválasztására egy stacket védő őrlapot (guard page) használnak a szoftverek. Ennek implementációja azonban sokszor sebezhető, amire általános kihasználási módszereket tudtak készíteni a kutatók. Az egyik ilyen módszer az "ütközés", amelyben addig növeljük a stack méretét, míg elér egy másik memóriaterületet (vagy amíg egy másik memóriaterület éri el a stacket). Egy másik az "ugrás" a guard page fölött, ebben a halom mutatóját valamilyen más memóriaterületre irányítjuk át, az őrlap megkerülésével. A harmadik ilyen általános módszer a "rombolás", amelyben a stacket egy másik memóriafoglalással felül lehet írni (vagy fordítva).
Az AI és a nagy full-full-stack trend Az AI farvizén számos új informatikai munkakör születik, vagy már ismert munkák kapnak új nevet és vele extra elvárásokat is.
A következmények meglehetősen kemények, a kutatók szerint a sebezhetőség legfontosabb kihasználási módja jogosultságemelésre ad lehetőséget: ha a támadó képes user kontextusban kódot futtatni, akkor elérhetővé válik számára a legmagasabb szintű, root jogosultság is, ezzel gyakorlatilag teljesen átvéve a gép fölött az irányítást. A fenti kitétel miatt a Stack Clash elsősorban más sebezhetőséggel kombinálva lehet veszélyes: ha a támadó kódfuttatási lehetőséget szerez a szerveren, akkor azt a Stack Clash segítségével root szintre tudja emelni.
A sebezhetőség lokális támadásra ad lehetőséget, távoli kihasználása jelenleg nem ismert. Elvben azonban ez sem zárható ki, az ilyen támadások azonban szükségképpen alkalmazásspecifikusak, ezeket pedig nem vizsgálta széles körűen a kutatócsapat.
Védekezni lehet, de nagyon macerás
Amennyiben a szervezet nem akarja valamiért azonnal frissíteni a szervereket (ez újraindítással jár), akkor érdemes megfontolni egy ideiglenes jellegű védekezést. Az RLIMIT_STACK és RLIMIT_AS paraméterek beállításával korlátozhatóak a helyi és távoli felhasználók által befoglalható erőforrások. Itt azonban tekintettettel kell lenni az egyes alkalmazások igényeire, a túl szűkre szabott korlátok ugyanis a teljesítménybe és a stabilitásba is alaposan beleharaphatnak. Külön probléma, hogy nem minden esetben használható ez a védekezés, bizonyos forgatókönyvekben hiába az alacsony küszöb, a hiba úgy is kihasználható marad.
A biztos megoldás ezért az érintett rendszerek gyors ütemű frissítése. A Qualys már május óta együtt dolgozik a legtöbb szoftverházzal a javítások dolgában, mára ezek a legtöbb érintett és támogatott rendszerhez el is érhetőek például a Red Hat, a Debian, a Canonical mellett a BSD-család (OpenBSD, NetBSD, FreeBSD) és Solaris rendszerhez is. Ugyan a Qualys csak x86-os környezetben végezte el a vizsgálatot, úgy tűnik a hibát sikerült az Oracle-nek SPARC-on is reprodukálni, így azok a Solarisok is újraindítást-frissítést kívánnak.