O vulnerabilitate în OpenSSH permite execuția de cod de la distanță cu privilegii de root pe servere cu Glibc.

Compania Qualys a identificat o vulnerabilitate critică (CVE-2024-6387) în OpenSSH, care permite executarea de cod de la distanță cu drepturi de root fără autentificare. Vulnerabilitatea, cunoscută sub numele de regreSSHion, se manifestă în configurația implicită începând cu versiunea OpenSSH 8.5 pe sistemele cu biblioteca standard Glibc.

Posibilitatea de a efectua un atac a fost demonstrată pe un sistem de 32 de biți cu Glibc cu protecția ASLR (randomizarea spațiului de adresare) activată. Pentru un atac de succes în condiții de laborator, a fost necesară o perioadă de 6-8 ore, timp în care s serverul au stabilit continuu conexiuni cu intensitatea maximă permisă în configurația sshd. Efectuarea atacului este simplificată și necesită mai puțin timp pe sistemele fără ASLR sau în distribuitivele care folosesc OpenSSH modificat, în care re-randomizarea ASLR a fost dezactivată pentru fiecare conexiune. Prototipul funcțional al exploit-ului nu va fi publicat public până la eliminarea generalizată a vulnerabilității, dar este disponibil un document suficient de detaliat care descrie natura vulnerabilității, ceea ce face ca apariția exploit-urilor externe să fie o chestiune de timp.

Nu este exclusă posibilitatea efectuării atacului și pe sistemele de 64 de biți, dar un exploit funcțional pentru aceste sisteme nu este încă disponibil. Se presupune că efectuarea unui atac asupra sistemelor de 64 de biți va dura mult mai mult, dar nu mai mult de o săptămână. OpenSSH în OpenBSD nu este vulnerabil, deoarece în acest sistem din 2001 este aplicat un mecanism de protecție care blochează astfel de clase de atacuri. În alte sisteme bazate pe biblioteci standard, diferite de Glibc, teoretic este posibilă adaptarea metodei pentru a efectua un atac (partea aceasta nu a fost încă cercetată de către Qualys).

Vulnerabilitatea a fost remediată în versiunea publicată astăzi a OpenSSH 9.8 (patch). Actualizările pachetelor în distribuitive pot fi urmărite pe paginile: Debian, Ubuntu, RHEL, SUSE/openSUSE, Fedora, ROSA, Gentoo, ALT Linux, Arch și FreeBSD. Ca o soluție alternativă pentru blocarea vulnerabilității în sshd_config, se poate seta parametrul „LoginGraceTime=0”, totuși dezactivarea timeout-ului va simplifica inițierea unui atac de refuz de serviciu prin stabilirea unui număr mare de conexiuni, care depășesc limitele stabilite prin parametrul MaxStartups.
Unul dintre semnele încercărilor de atac este apariția în jurnal a unui număr mare de înregistrări „Timeout before authentication”.

Vulnerabilitatea a apărut ca urmare a unei modificări regresive incluse în versiunea OpenSSH 8.5, care conduce la o stare de competiție în codul de gestionare a semnalelor în sshd. Regresia a dus la pierderea protecției împotriva unei vechi vulnerabilități CVE-2006-5051, care se manifesta până la versiunea OpenSSH 4.4 (anul 2006) și avea caracter teoretic.
În timpul dezvoltării OpenSSH 8.5, din greșeală a fost eliminat blocul „#ifdef DO_LOG_SAFE_IN_SIGHAND” din funcția sigdie(), care este apelată direct din gestiune SIGALRM.

Gestiunea SIGALRM este apelată în sshd în mod asincron, dacă clientul nu s-a autentificat în intervalul de timp limitat de timeout-ul de conectare (LoginGraceTime, implicit 120 sec). Atacul se bazează pe faptul că gestiunea semnalului apelează funcții nesigure în timpul gestionării asincrone a semnalelor, precum syslog(). Funcția syslog() din Glibc nu este proiectată pentru utilizare în gestiuni de semnale executate asincron, deoarece apelează funcții malloc() și free(). Activarea semnalului SIGALRM, care întrerupe execuția unui anumit cod în sshd, poate duce la o perturbare a stării de execuție, iar scopul exploit-ului este de a crea condiții pentru a întrerupe codul necesar în momentul corespunzător al execuției sale. Vulnerabilitatea nu afectează OpenBSD, deoarece acolo, în loc de syslog() din gestiunea semnalului SIGALRM, se apelează funcția syslog_r(), creată special pentru execuția asincronă.

Sursa: opennet.ro

Cumpără un hosting fiabil pentru site-uri cu protecție DDoS, servere VPS VDS 🔥 Cumpără un hosting fiabil pentru site-uri cu protecție DDoS, servere VPS VDS | ProHoster