Red Hat: una catena di falle in FreeIPA concede privilegi di amministratore a utenti anonimi

FreeIPA, il sistema open source di gestione delle identità che determina chi può accedere a un dominio Linux, contiene una catena di falle che può consentire a un client che non ha mai effettuato l'accesso di creare un'identità Kerberos a propria scelta e finire nel gruppo degli amministratori, secondo Red Hat. FreeIPA mantiene tutte le identità in un database 389 Directory Server accessibile via LDAP, e l'attacco richiede anche un secondo difetto in quel software di database. Red Hat traccia la parte FreeIPA come CVE-2026-76578 e la valuta critica con un punteggio CVSS di 9,8, pur notando che il punteggio è preliminare e soggetto a revisione. Il progetto FreeIPA ha già corretto la sua parte nella versione 4.13.4.

Il primo problema è una regola di controllo accessi chiamata ACI che FreeIPA include. Questa regola consente a un utente di gestire il proprio token one-time-password, ma non richiede che il client abbia effettuato l'accesso e non limita cosa altro possa essere scritto insieme al token. Da sola non sarebbe sufficiente. La seconda falla è in 389 Directory Server. Il suo motore di controllo accessi ha un tipo di regola pensato per consentire solo al proprietario autenticato di una voce di modificarla. Confronta il nome del client con un valore memorizzato come testo semplice. Un client che non ha effettuato l'accesso ha un nome vuoto, e quel valore vuoto corrisponde a un valore memorizzato vuoto. Di conseguenza, un client anonimo può creare una voce token con i campi di proprietà lasciati vuoti, superare il controllo di proprietà essendo nessuno e scrivere un'identità Kerberos e una password insieme ad essa.

Red Hat valuta la falla del server directory CVE-2026-76560 con un punteggio di 7,5 e afferma che Red Hat Directory Server non include una regola di quella forma per impostazione predefinita, quindi da sola la falla conta solo dove una distribuzione ha scritto tale regola. FreeIPA è esattamente una tale distribuzione perché la sua regola predefinita ha quella forma. Red Hat ha riprodotto l'intera catena due volte su un'installazione predefinita, più recentemente su una macchina senza alcun accesso, e ha anche riprodotto il difetto del server directory su una build 389-ds semplice senza componenti FreeIPA installati; un test di controllo con un valore non vuoto è stato correttamente rifiutato. Questo colloca il difetto nel motore di controllo accessi piuttosto che in qualcosa che FreeIPA fa. La tecnica segnalata inizialmente a Red Hat impersonava il vero account admin creando un nome Kerberos che corrispondeva ad esso. Una correzione precedente per CVE-2026-13097 ha bloccato quella collisione ma ha lasciato in atto la scrittura non autenticata sottostante. L'attacco ora funziona con un nome scelto dall'attaccante, che Red Hat afferma raggiunge lo stesso risultato pratico. Quella falla precedente, corretta in FreeIPA 4.13.3, era un problema diverso: il controllo che i nomi Kerberos siano unici non consentiva diversi modi di scrivere lo stesso nome, quindi un utente con accesso in scrittura poteva creare un'identità di servizio che impersonava una privilegiata esistente. I due progetti descrivono il risultato in modo diverso. Red Hat lo chiama appartenenza genuina al gruppo amministratori e credenziali di amministratore riutilizzabili. Il progetto FreeIPA afferma che l'identità iniettata non deve già esistere, che la correzione di CVE-2026-13097 impedisce la presa di controllo di account esistenti e che l'attacco può essere usato come trampolino verso privilegi amministrativi. Red Hat afferma di aver eseguito la catena contro un'immagine container FreeIPA standard che esegue la versione 4.13.1 e di aver verificato i risultati con comandi standard solo per amministratori piuttosto che fidarsi dell'output dell'exploit. Nessuna delle advisory o dei bug report descrive la falla usata in un attacco reale. Per distribuzioni che usano identificatori di sicurezza in stile Windows, Red Hat afferma che l'attaccante può anche ottenere un ticket Kerberos contenente dati di autorizzazione, estendendo l'accesso ai servizi HTTP e Dogtag del server, dove Dogtag è l'autorità di certificazione integrata di FreeIPA.

Separatamente, Red Hat ha divulgato CVE-2026-79678, una falla importante con un punteggio di 8,1 che non ha nulla a che fare con la catena. Il comando idp-add passa due valori forniti dal chiamante, un nome di organizzazione e un URL di base, in una chiamata Python eval(). Tale chiamata viene eseguita prima del controllo dei permessi pensato per limitare il comando agli amministratori del provider di identità, quindi qualsiasi account sul server può raggiungerla indipendentemente dai privilegi. La chiamata è limitata da un modello che vieta le parentesi quadre, il che impedisce la chiamata di qualsiasi funzione, e Red Hat afferma che non è possibile eseguire codice. Ciò che un attaccante può fare è leggere le variabili d'ambiente del processo del server una alla volta osservando l'errore restituito dal server e consumare la memoria del server con una breve espressione aritmetica. Quanto conta dipende da come è stato installato FreeIPA. In un'installazione normale basata su pacchetti, l'ambiente del processo contiene solo percorsi e impostazioni documentati. Nell'immagine ufficiale del server FreeIPA, le password di Directory Manager e amministratore sono spesso prese come variabili d'ambiente al primo avvio e quelle password potrebbero essere esposte se rimangono dopo il completamento della configurazione. Red Hat accredita Gia Bui di Calif per la segnalazione della catena FreeIPA e della falla del server directory, e accredita Calif che lavora con Anthropic per la falla idp-add.

La correzione è arrivata in tre posti in tre momenti diversi. Per FreeIPA dal progetto, installare FreeIPA 4.13.4, che corregge entrambe le falle FreeIPA, ma le note di rilascio non riportano data e non dicono quali versioni precedenti sono interessate. Per 389-ds-base su Red Hat Enterprise Linux e Red Hat Directory Server, usare l'advisory per la release; quattordici advisory sono state pubblicate l'8 settembre tra le 01:56 e le 05:07 UTC, e RHSA-2026:64785 copre Red Hat Enterprise Linux 10 con 389-ds-base-3.2.0-10.el10_2. Quell'advisory è valutata critica e copre altre quattro falle di 389-ds oltre a questa. Per i pacchetti ipa su Red Hat Enterprise Linux, nessuna versione corretta o advisory era elencata al momento del controllo dell'8 settembre. Su Fedora, il tracker era marcato ON_QA in quella data. Nessuna advisory per il semplice Red Hat Enterprise Linux 9 è apparsa nella lista dei quattordici, ma quello era ciò che mostrava il record del bug l'8 settembre, non una dichiarazione che la release non avrà correzioni. Fino a quando non sarà disponibile un pacchetto corretto, Red Hat fornisce due passaggi temporanei per la catena. Primo, limitare l'accesso al servizio LDAP, tipicamente porte 389 e 636, agli host di cui ti fidi usando regole firewall o segmentazione di rete. Secondo, disattivare i bind LDAP anonimi blocca questo particolare percorso, ma controlla prima che nessun'altra parte della tua distribuzione ne abbia bisogno. Per la falla idp-add non esiste tale opzione: Red Hat afferma che nessuna impostazione di configurazione tiene un account autenticato ordinario lontano da quel codice e che è richiesto un pacchetto corretto. Aggiunge che chiunque esegua installazioni container dovrebbe verificare che la password impostata al primo avvio non sia più presente nell'ambiente del processo in esecuzione. Il materiale pubblicato lascia due domande senza risposta: né Red Hat né il progetto FreeIPA dicono se gli aggiornamenti di 389-ds da soli fermano l'attacco FreeIPA su un server i cui pacchetti ipa sono ancora obsoleti, e nessuno dei due dice se applicare una correzione rimuove un'identità creata in precedenza da un attaccante o cosa un amministratore dovrebbe cercare per scoprirlo. Le advisory e i bug report non pubblicano regole di rilevamento o indicatori. Per i proprietari di siti web e i team IT, il servizio AEU Hosting di AEU Group gestisce ambienti di hosting WordPress end-to-end, ma le organizzazioni che eseguono FreeIPA da sole devono applicare gli aggiornamenti del fornitore direttamente.