Exim, RCE non autenticata su server GnuTLS: patch 4.99.3

CVE-2026-45185 consente RCE non autenticata su Exim con GnuTLS tramite BDAT. Nessuna mitigazione alternativa: l'unica difesa è l'upgrade immediato a 4.99.3

Contenuto

Exim, RCE non autenticata su server GnuTLS: patch 4.99.3
Exim, RCE non autenticata su server GnuTLS: patch 4.99.3

Exim ha pubblicato il 12 maggio 2026 la versione 4.99.3 per chiudere CVE-2026-45185, una vulnerabilità use-after-free che consente esecuzione remota di codice non autenticata sui server compilati con GnuTLS. La falla si innesca durante il trasferimento BDAT se un client interrompe la sessione TLS con un close_notify e invia un byte in chiaro sulla stessa connessione TCP. Non esistono mitigazioni alternative: l'upgrade è l'unica difesa possibile per gli amministratori che gestiscono il mail transfer agent più diffuso su sistemi Unix-like.

Punti chiave
  • CVE-2026-45185 è una use-after-free nel parser BDAT di Exim quando la connessione TLS è gestita da GnuTLS.
  • Il trigger richiede un TLS close_notify durante il trasferimento BDAT seguito da un byte in cleartext finale sulla stessa connessione TCP.
  • Le versioni interessate sono quelle dalla 4.97 alla 4.99.2 compilate con USE_GNUTLS=yes; le build con OpenSSL non sono colpite.
  • L'advisory Exim conferma l'assenza di workaround: solo l'aggiornamento alla versione 4.99.3 risolve la vulnerabilità.

La sequenza del trigger: TLS shutdown e BDAT in collisione

Il protocollo ESMTP BDAT consente il trasferimento di porzioni binarie del corpo del messaggio. Durante questa fase, il server si aspetta che la sessione TLS gestita da GnuTLS resti stabile fino al completamento del trasferimento. Se il client invia invece un alert close_notify prima che il body transfer sia completo, e poi trasmette un ultimo byte in cleartext sullo stesso socket TCP, Exim entra in uno stato di gestione anomala.

Secondo l’advisory ufficiale: "The vulnerability is triggered during BDAT message body handling when a client sends a TLS close_notify alert before the body transfer is complete, and then follows up with a final byte in cleartext on the same TCP connection". Questa sequenza non richiede autenticazione e non dipende da una configurazione esotica del server.

Il comando BDAT è parte dell’estensione SMTP CHUNKING e consente di spedire porzioni esatte di dati binari senza codifica Base64, riducendo l’overhead sui server ad alto volume. La sua integrazione con il layer TLS è però gestita da un wrapper interno che non prevede la ricezione di dati in chiaro dopo un close_notify, creando la condizione di race sfruttabile.

Root cause: ungetc() scrive su memoria già rilasciata

L’errore non risiede in GnuTLS, ma nel modo in cui Exim gestisce il proprio buffer di trasferimento durante il teardown della sessione crittografica. Quando GnuTLS segnala la chiusura del canale sicuro, Exim libera la struttura xfer_buffer per pulire lo stato della connessione. Tuttavia, il wrapper di ricezione BDAT rimane attivo e può ancora accettare byte in ingresso. In questa condizione, una chiamata a ungetc() riversa un carattere '\n' in una regione di memoria già deallocata.

Come riporta l’analisi di Federico Kirschbaum di XBOW: "During TLS shutdown, Exim frees its TLS transfer buffer — but a nested BDAT receive wrapper can still process incoming bytes and end up calling ungetc(), which writes a single character (\n) into the freed region". La scrittura sovrascrive i metadati dell’allocatore heap, aprendo la strada a primitive di exploit per l’esecuzione di codice remoto.

"one of the highest-caliber bugs discovered in Exim to date" — XBOW

Il perimetro di attacco: solo le build con GnuTLS

La vulnerabilità non interessa l’intero parco installato di Exim, ma solo le release dalla 4.97 alla 4.99.2 compilate con il flag USE_GNUTLS=yes. Le build realizzate con OpenSSL seguono un percorso di pulizia della sessione TLS diverso e non sono colpite. Molte distribuzioni Linux mantengono pacchetti Exim con GnuTLS come dipendenza predefinita, ma non è possibile stabilire con certezza quante installazioni in produzione soddisfino esattamente i requisiti del trigger.

L’assenza di dati indipendenti sul numero di server esposti rende il perimetro di attacco teoricamente ampio, specialmente per ISP e provider di hosting che gestiscono posta su piattaforme Unix-like. Per gli operatori di rete, la criticità risiede nel ruolo di Exim come MTA predefinito su innumerevoli sistemi Linux e BSD. Una RCE non autenticata su un servizio esposto pubblicamente sulla porta 25 o 587 rappresenta un vettore di compromissione totale del server, con possibile escalation verso la rete interna e i contenuti delle cassette postali.

Nessuna mitigazione temporanea: l'upgrade a 4.99.3 è obbligatorio

L’advisory ufficiale è categorico: non esistono contromisure alternative per ridurre il rischio se non l’applicazione della patch. Exim ha corretto la gestione del buffer durante lo shutdown TLS nella release 4.99.3, disponibile dal 12 maggio 2026. Non è previsto alcun workaround di configurazione, né filtri a livello di firewall in grado di distinguere in modo affidabile il pacchetto malevolo da un legittimo teardown di sessione senza bloccare il traffico SMTP-TLS.

La gravità è accentuata dall’assenza di barriere di accesso: l’attaccante non necessita di credenziali valide né di una configurazione server particolare. Come ricorda XBOW, "triggering this bug requires almost no special configuration on the server", il che amplifica la superficie di attacco a qualsiasi installazione vulnerabile raggiungibile via Internet. Per gli amministratori, questo significa che il ciclo di manutenzione deve considerare l’upgrade come intervento critico e non differibile.

Cosa fare adesso

  1. Verificare la build: Controllare se l’istanza Exim in produzione è stata compilata con USE_GNUTLS=yes e se la versione rientra nell’intervallo 4.97-4.99.2. In caso affermativo, il server è vulnerabile.
  2. Pianificare l’upgrade immediato a 4.99.3: L’advisory conferma che la versione 4.99.3 corregge il difetto. L’installazione deve essere pianificata come intervento di sicurezza critico, senza attendere workaround futuri.
  3. Monitorare i canali della distribuzione: Se l’ambiente utilizza pacchetti gestiti da Debian, Ubuntu, RHEL o altre distribuzioni, verificare la disponibilità dell’aggiornamento nel repository di sicurezza ufficiale prima di procedere a una compilazione manuale.
  4. Valutare la compilazione da sorgente se necessario: Nel caso in cui il vendor della distribuzione non abbia ancora pubblicato il pacchetto aggiornato, preparare una build pulita dalla fonte ufficiale Exim per ridurre la finestra di esposizione.

Il caso CVE-2026-45185 mostra come la complessità della gestione I/O in un software maturo possa generare falle di composizione tra protocolli apparentemente distinti. La sovrapposizione tra teardown TLS e parser BDAT ha prodotto una condizione zero-click che non richiede configurazioni speciali, rendendo la patch non solo consigliata, ma l’unico baluardo disponibile. Per le infrastrutture di posta, la scadenza è oggi.

Domande frequenti

Perché la vulnerabilità colpisce solo le build con GnuTLS?

Il teardown della sessione TLS in GnuTLS innesca un percorso di pulizia del buffer xfer_buffer che interagisce in modo difettoso con il wrapper di ricezione BDAT di Exim. Le build compilate con OpenSSL non attraversano quel percorso specifico e risultano immuni, come confermano l’advisory Exim e l’analisi XBOW.

È possibile mitigare la vulnerabilità senza aggiornare Exim?

No. L’advisory ufficiale specifica esplicitamente che non esistono mitigazioni alternative. Nessuna regola di firewall o opzione di configurazione può risolvere la use-after-free nel parser BDAT: l’unica contromisura è l’upgrade alla versione 4.99.3.

La catena di exploit fino a RCE è stata dimostrata pubblicamente?

XBOW ha affermato che la corruzione dei metadati dell’allocatore heap apre a primitive di exploit per l’esecuzione di codice, ma la completezza della catena fino a RCE non è stata verificata indipendentemente da terzi al momento della pubblicazione. Non è inoltre documentato alcun sfruttamento attivo in-the-wild.

Fonti

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.

Fonti

Link utili

Apri l'articolo su DeafNews