Sebezhetőség az OpenSSH-ban, amely lehetővé teszi a távoli kódvégrehajtást root jogosultságokkal a Glibc-val rendelkező szervereken

A Qualys felfedezett egy kritikus sebezhetőséget (CVE-2024-6387) az OpenSSH-ban, amely lehetővé teszi a távoli kódvégrehajtást root jogosultságokkal, hitelesítés megkerülésével. A 'regreSSHion' kódnévvel illetett sebezhetőség az OpenSSH 8.5-ös verziójától kezdődően, alapértelmezett konfigurációban jelentkezik Glibc standard könyvtárral rendelkező rendszereken.

A támadás lehetőségét egy 32 bites Glibc-szel rendelkező rendszeren, ASLR (címterület véletlenítés) védelemmel demonstrálták. A laboratóriumi körülmények között a támadás sikeres megvalósításához 6-8 órás folyamatos kapcsolódás volt szükséges a sshd konfiguráció maximális intenzitásával. szerverrel A támadás lefolytatása egyszerűbb, és kevesebb időt igényel az ASLR nélküli rendszereken, vagy olyan disztribúciókban, amelyek módosított OpenSSH-t használnak, ahol le van tiltva az ASLR újra véletlenítése minden egyes kapcsolatra. A sebezhetőség mindenhol történő orvoslásáig nem kerül nyilvánosságra a munkacsoport prototípusa, de elérhető egy elég részletes leírás a sebezhetőségről, amely lehetővé teszi harmadik fél exploitjainak megjelenését.

Nem zárható ki a támadás lehetősége 64 bites rendszereken sem, de az ilyen rendszerekhez működő exploittal jelenleg nem rendelkezünk. Feltételezhető, hogy a támadás végrehajtása 64 bites rendszereken sokkal több időt vesz igénybe, de nem haladhatja meg az egy hetet. Az OpenSSH az OpenBSD-ben nem érintett, ugyanis ezen a rendszeren 2001 óta alkalmaznak egy védelmi mechanizmust, amely blokkolja az ilyen típusú támadásokat. Más, a Glibc-tól eltérő standard könyvtárakat használó rendszereken elméletileg lehetséges a módszer alkalmazásának adaptálása a támadás végrehajtásához (ezzel a kérdéssel a Qualys eddig nem foglalkozott).

A sebezhetőséget kijavították a ma közzétett OpenSSH 9.8-as kiadásban (javítás). A csomagfrissítések publikációját a következő disztribúciók oldalain lehet nyomon követni: Debian, Ubuntu, RHEL, SUSE/openSUSE, Fedora, ROSA, Gentoo, ALT Linux, Arch és FreeBSD. A sebezhetőség sshd_config-ban való blokkolásának alternatív megoldásaként beállítható a 'LoginGraceTime=0' paraméter, azonban a timeout letiltása megkönnyíti a szolgáltatásmegtagadás kezdeményezését, ha a kapcsolatok száma a MaxStartups paraméter által megadott határokat meghaladja.
Az egyik jele a támadási kísérleteknek a naplóban megjelenő nagy számú "Timeout before authentication" bejegyzés.

A sérülékenység egy regresszív változás következményeként alakult ki, amely az OpenSSH 8.5 verzió részét képezte, és versenyhelyzetet okoz a sshd jelzéskezelő kódjában. A regresszió a régi CVE-2006-5051 sérülékenység elleni védelmet megszüntette, amely a 4.4-es verzió előtt (2006) jelentkezett, és elméleti jellegű volt.
Az OpenSSH 8.5 fejlesztése során véletlenül eltávolították a sigdie() függvényből a "#ifdef DO_LOG_SAFE_IN_SIGHAND" blokkot, amely közvetlenül a SIGALRM kezelőjéből hívódik meg.

A SIGALRM kezelője az sshd-ben aszinkron módon hívódik meg, ha a kliens nem hajtotta végre az azonosítást a csatlakozási időkeret alatt (LoginGraceTime, alapértelmezés szerint 120 másodperc). A támadás arra épít, hogy a jelzők kezelője aszinkron jelkezelés mellett nem biztonságos függvényeket hív, mint például a syslog(). A syslog() függvény a Glibc-ban nem alkalmas aszinkron jelkezelő függvényekben való használatra, mivel malloc() és free() függvényeket hív. A SIGALRM jelzés aktiválása, amely megszakítja egy adott kód működését az sshd-ben, állapotmegsértéshez vezethet, és a kihasználás célja a megfelelő kód megszakításának feltételeinek megteremtése a szükséges végrehajtási időpontban. A sérülékenység nem érinti az OpenBSD-t, mivel ott a syslog() helyett a SIGALRM jelzéskezelőből a syslog_r() függvény hívódik meg, amelyet kifejezetten aszinkron végrehajtásra terveztek.

Forrás: opennet.ru

Megbízható hosting vásárlása weboldalak számára, DDoS védelemmel, VPS VDS szerverek. 🔥 Megbízható webtárhely vásárlása DDoS védelemmel, VPS VDS szerverek | ProHoster