A Qualys cég két sebezhetőséget észlelt az apport (CVE-2025-5054) és a systemd-coredump (CVE-2025-4598) eszközökben, amelyek a folyamatok kényszerített leállása után generált core-fájlok kezelésére szolgálnak. A sebezhetőségek hozzáférést biztosítanak a kényszerített leállítás után megőrzött core-fájlokhoz, amelyekben suid-alkalmazások vagy bizonyos rendszerszintű háttérfolyamatok tárolt hitelesítő adatai vagy titkosítási kulcsai találhatóak. Az apport segédeszköz automatikusan aktiválódik a core-dumpok mentésére Ubuntu alatt, míg a systemd-coredump a Red Hat Enterprise Linux 9+, Fedora és sok más Linux-disztribúcióban.
Egy támadási technikát mutattak be, amelynek során a unix_chkpwd suid-alkalmazás kényszerített leállításának feltételeit hozták létre, lehetővé téve ezzel a core-fájlhoz való hozzáférést a hiba következtében. A megőrzött core-dumpban a rendszer felhasználóinak jelszóhash-ei voltak megtalálhatók, amelyek a hiba után a megszakadt folyamat memóriájában maradtak az /etc/shadow tartalmának betöltése után. A sebezhetőségek kihasználásának lehetőségeit az Ubuntu 24.04 és a Fedora 40/41 verzióiban mutatták be, azonban vélhetően más disztribúciók is hasonló támadásoknak vannak kitéve.
Mindkét sebezhetőséget egy versenyhelyzet okozza, amely lehetővé teszi, hogy a kényszerített leállás után, de a felhasználói térben a folyamat paramétereinek /proc/pid/files általi ellenőrzése előtt az elhalt suid-folyamatot egy másik folyamatra cseréljék ki. Az apport és a systemd-coredump hívása a következő módon történik: a kernel a folyamat leállásával kapcsolatos információk megszerzése után a /proc/sys/kernel/core_pattern fájlban megadott kezelőt hívja, majd átadja neki a core-dump tartalmát a bemeneti folyamán.
A core-dump generálása és a kezelő futtatása nem valósul meg azonnal, és van elegendő idő a befejeződött suid-folyamat normál felhasználói folyamattá való átkonvertálására. Ha kicserélik, a futó core-dump kezelő azt fogja hinni, hogy a hiba nem a suid-folyamatban, hanem egy normál felhasználói alkalmazásban történt, és ennek megfelelően a core-fájlt normál felhasználói hozzáféréssel, nem csupán adminisztrátori jogosultsággal menti el.
Az apport elleni támadás a következő lépésekből áll:
- Egy új folyamatot indítanak, és végrehajtják az execve() funkciót egy suid-program, például a unix_chkpwd indításához.
- Megengedett az idő, amely szükséges a suid-program által bizalmas adatok memóriába való betöltésére (unix_chkpwd esetén a rendszer összes felhasználójának jelszavának hash-ét a /etc/shadow fájlból várják).
- A parancs végrehajtásának befejezése előtt a folyamat SIGSEGV vagy SIGSYS jelet kap a kényszerített leállításhoz.
- A kényszerített leállításra reagálva a kernel core-dump-ot generál és elindítja az apport folyamatot a core-dump feldolgozására felhasználói térben.
- Miután az apport elindult, de a hibásan leállt folyamat elemzése előtt SIGKILL jelet küldenek a folyamatnak, és a folyamatot egy másikkal helyettesítik suid zászló nélkül. Az apport ellenőrzéseinek megkerülése érdekében az új folyamatokat külön névtérben (user, pid és mount namespace) hozzák létre.
- Az apport csatlakozik a /run/apport.socket unix socket-hez az új folyamat kötetnézeteiben, és elküldi a fájl leíróját a core-dump eléréséhez.
Annak érdekében, hogy az új folyamat megkapja a kívánt azonosítót, amely megegyezik a suid-folyamat azonosítójával, a SIGSEGV jel elküldése előtt a suid-folyamatot a SIGSTOP jellel leállítják, és a leállás közben folyamatosan új folyamatokat indítanak, amíg egy PID-t nem kapnak, amely megelőző számú és közel áll a felcserélhető suid-folyamathoz. A PID számolásának eltolása után a suid-folyamatnak SIGSEGV és SIGCONT jeleket küldenek, majd SIGKILL jelet, és folyamatosan új folyamatokat indítanak a suid-folyamattal azonos PID eléréséhez.
Ami a systemd-coredump-ot illeti, egyrészt könnyebb támadni, mivel nincs szükség a suid-folyamat helyettesítésére egy külön felhasználói térbeli folyamattal, és elegendő az AT_UID és AT_EUID megegyezése. Másrészt a systemd-coredump C nyelven íródott és elég gyorsan elindul, ami kevesebb időt ad a felcseréléshez, szemben az apporttal, amely Python nyelven készült, és inicializálás közben különféle pyc fájlokat tölt be. Az ilyen jellegű probléma mesterséges lassítással orvosolható – a suid-fájl hívásakor nagyon nagy számú parancssori argumentumot adnak át, ami a /proc/pid/cmdline elemzése közben szükséges késleltetést okoz.
A sebezhetőségek elemzése során a kutatók azt is megállapították, hogy a systemd-coredump a hívás beállításakor nem jelöli a «%d» zászlót a /proc/sys/kernel/core_pattern fájlban, ami lehetővé teszi a támadó számára a háttérfolyamatok kényszerített leállítását, amelyek root jogosultságokkal futnak, és más folyamatokat indítanak el a támadás alatt használatban lévő nem privilégizált felhasználói azonosítóval. Ez a lehetőség lehetővé teszi a támadást nemcsak a setuid alkalmazások, hanem olyan folyamatok, mint az sshd-session (OpenSSH), sd-pam (systemd) és cron ellen is, hogy hozzáférjenek az emlékezetükben rekedt bizalmas adatokhoz, például titkos kulcsokhoz, a /etc/shadow fájlból származó jelszó hash-ekhez, canary jelöléshez a veremben, és az address space randomization (ASLR) megkerüléséhez szükséges adatokhoz.
A csomagfrissítések közzétételének nyomon követése a disztribúciókban a következő oldalakon lehetséges: Debian, Ubuntu, RHEL, openSUSE, Fedora, Gentoo, Arch. A sebezhetőségek blokkolásának alternatívájaként javasolják, hogy kapcsolják ki a core-dumpok mentését a suid programok és az engedélyek csökkentését végző folyamatok esetén, a /proc/sys/fs/suid_dumpable paraméter 0-ra állításával. A probléma teljes körű megszüntetéséhez változtatásokat kell végezni a Linux kernelen, amely lehetővé teszi az információk átadása a meghiúsult folyamatról a pidfd mechanizmus révén (a pidfd konkrét folyamatokhoz kötődik, és ellentétben a pid-del, nem rendelhető újra).
Forrás: opennet.ru
