Exim corrige une faille critique “Dead.Letter” qui expose certains serveurs mail à une exécution de code à distance

Selon FOSS Force, toutes les versions d’Exim allant de 4.97 à 4.99.2 sont concernées, mais uniquement lorsque le logiciel utilise le backend TLS GnuTLS. Les builds reposant sur OpenSSL ou d’autres bibliothèques TLS ne sont pas affectés par cette vulnérabilité précise. La version corrigée est Exim 4.99.3.

Une faille dans la gestion de BDAT et TLS

Dead.Letter est une vulnérabilité de type use-after-free. En clair, Exim peut continuer à utiliser une zone mémoire qui a déjà été libérée, ce qui ouvre la porte à une corruption mémoire.

Le problème apparaît dans un scénario assez spécifique, mais exploitable à distance : un client SMTP démarre une connexion TLS, utilise l’extension CHUNKING / BDAT pour transférer le corps d’un message, puis envoie une notification TLS close_notify avant la fin du transfert. En ajoutant ensuite un dernier octet en clair sur la même connexion TCP, l’attaquant peut déclencher une écriture dans une zone mémoire libérée.

Le NVD décrit cette faille comme pouvant mener à une exécution de code arbitraire par un attaquant réseau non authentifié.

Pourquoi les administrateurs doivent réagir vite

Le point le plus inquiétant est que l’exploitation ne nécessite pas de compte utilisateur ni d’accès préalable au serveur. Il suffit à l’attaquant de pouvoir établir une connexion TLS et d’utiliser l’extension SMTP CHUNKING / BDAT.

Les serveurs mail exposés sur Internet sont donc les plus à risque, notamment lorsqu’ils utilisent Exim avec GnuTLS et annoncent les extensions STARTTLS et CHUNKING.

Le CERT-FR a également publié un avis sur cette vulnérabilité, en renvoyant vers le bulletin de sécurité officiel d’Exim et la référence CVE associée. Debian suit aussi la faille dans son tracker de sécurité, avec la même description technique : Exim avant la version 4.99.3 est vulnérable dans certaines configurations GnuTLS.

Pas de vrai contournement : il faut mettre à jour

La recommandation principale est simple : mettre à jour Exim vers la version 4.99.3 ou appliquer le correctif fourni par sa distribution Linux. Il n’existe pas de mitigation officielle équivalente à un correctif complet.

Pour les administrateurs, les vérifications prioritaires sont les suivantes :

• identifier les serveurs Exim exposés à Internet ;
• vérifier la version installée avec exim -bV ;
• confirmer si Exim est compilé avec GnuTLS ou OpenSSL ;
• appliquer Exim 4.99.3 ou le paquet corrigé de la distribution ;
• redémarrer le service après mise à jour.

Certaines sources de veille évoquent la désactivation temporaire de l’annonce de CHUNKING comme mesure d’atténuation, mais cela doit rester un palliatif testé avec prudence, car cela peut avoir un impact sur certains flux SMTP. La correction logicielle reste la solution propre.

Une nouvelle alerte sur la sécurité des briques open source critiques

Dead.Letter rappelle à quel point les composants d’infrastructure “invisibles” restent des cibles sensibles. Un serveur mail est rarement sous les projecteurs, mais il traite des données critiques, reste exposé en permanence et peut devenir un point d’entrée redoutable en cas de compromission.

Pour les particuliers auto-hébergés comme pour les entreprises, le message est donc clair : si Exim est utilisé, surtout sur Debian, Ubuntu ou une distribution dérivée, il faut vérifier rapidement la version et le backend TLS. Dans ce cas précis, attendre revient à laisser une porte ouverte sur un service généralement accessible depuis Internet.