În procesul de investigare a vulnerabilității critice descoperite săptămâna trecută în OpenSSH, a fost identificată o altă vulnerabilitate similară (CVE-2024-6409) care permite execuția de cod de la distanță fără a necesita autentificare. Noua vulnerabilitate nu este atât de periculoasă ca cea precedentă, deoarece se manifestă după resetarea privilegiilor în procesul fiu al serverului SSH. Vulnerabilitatea este prezentă în pachetele openssh din distribuția Red Hat Enterprise Linux 9, bazate pe versiunea OpenSSH 8.7 publicată în 2021. Problema afectează de asemenea pachetele pentru Fedora Linux 36 și 37, bazate pe versiunile OpenSSH 8.7 și 8.8.
Ca esență, vulnerabilitatea este similară cu problema anterioară și este cauzată de o condiție de competiție în handler-ul de întrerupere SIGALRM, care apare din cauza apelării unor funcții neconcepute pentru a fi apelate în mod asincron din handler-urile de semnal. Handler-ul se activează atunci când expira timpul definit prin parametrul LoginGraceTime și întrerupe execuția curentă a codului. Utilizarea în handler-urile de întrerupere a funcțiilor neîntocmite pentru execuția asincronă, care implică alocarea dinamică a memoriei, cum ar fi syslog(), poate duce la coruperea structurilor interne malloc atunci când SIGALRM se declanșează în timpul execuției unui cod specific.
Noua vulnerabilitate se distinge prin faptul că condiția de competiție apare din apelul din handler-ul de semnal grace_alarm_handler() al funcției cleanup_exit(). În baza principală de cod OpenSSH, această funcție poate fi utilizată în codul executat asincron, dar în pachetele pentru RHEL 9 și Fedora a fost aplicat un patch suplimentar care include în cleanup_exit() un apel pentru generarea de evenimente de audit, conceput pentru a fi utilizat în handler-urile de semnal.
Acest patch a fost utilizat în RHEL 9 și în distribuțiile derivate în pachetele bazate pe OpenSSH 8.7p1. În versiunile actuale ale Fedora, problema nu se manifestă, deoarece începând cu Fedora 38, distribuția a trecut la o versiune mai nouă de OpenSSH fără a modifica cleanup_exit(). Spre deosebire de vulnerabilitatea anterioară, pentru a bloca noua problemă nu funcționează soluția alternativă de protecție bazată pe utilizarea opțiunii „-e” în sshd, care dezactivează logarea prin syslog. Totuși, pentru a bloca vulnerabilitatea în sshd_config, se poate seta parametru „LoginGraceTime=0”.
Sursa: opennet.ro
