Beveilingsonderzoekers vinden 21 kwetsbaarheden in e-mailserversoftware Exim

Beveiligingsonderzoekers van Qualys hebben een serie kwetsbaarheden gevonden in e-mailserversoftware Exim. Het gaat om 21 kwetsbaarheden die samen bekend staan als 21Nails. Die kunnen zowel lokaal als van een afstand worden ingezet.

Van de 21 bugs in Exim kunnen er elf lokaal worden uitgebuit, maar tien ook van een afstand. In sommige gevallen gaat het om een Lokaal privilege escalation, maar in andere gevallen om de mogelijkheid om bestanden aan te maken of juist te verwijderen. Qualys waarschuwt dat de verschillende bugs aan elkaar kunnen worden gekoppeld om een volledige, ongeauthenticeerde remote code execution op afstand uit te voeren.

Sommige van de bugs zijn al vrij oud. Zo is er een bug, CVE-2020-28017, die uit een Exim-versie uit 2014 komt. Volgens Qualys treffen de kwetsbaarheden alle Exim-versies vóór 4.94.1. Het bedrijf heeft in oktober al contact opgenomen met de beheerders van Exim. Dat heeft inmiddels patches uitgebracht, en raadt beheerders aan die zo snel mogelijk door te voeren.

Exim is populaire software om mailservers te beheren. De software draait naar schatting op 3,6 miljoen servers. In 2019 werden kwetsbare servers al aangevallen door een lek dat root-toegang via ssh gaf.

CVE-2020-28007	Link-aanval in Exims log directory	Lokaal
CVE-2020-28008	Aanval in spool directory	Lokaal
CVE-2020-28014	Willekeurige bestandsaanpassing	Lokaal
CVE-2021-27216	Willekeurige bestandsverwijdering	Lokaal
CVE-2020-28011	Heap buffer overflow in queue_run()	Lokaal
CVE-2020-28010	Heap out-of-bounds write in main()	Lokaal
CVE-2020-28013	Heap buffer overflow in parse_fix_phrase()	Lokaal
CVE-2020-28016	Heap out-of-bounds write in parse_fix_phrase()	Lokaal
CVE-2020-28015	Nieuwe-regelinjectie in spool header file	Lokaal
CVE-2020-28012	Ontbrekende close-on-exec flag	Lokaal
CVE-2020-28009	Integer overflow in get_stdinput()	Lokaal
CVE-2020-28017	Integer overflow in receive_add_recipient()	Remote
CVE-2020-28020	Integer overflow in receive_msg()	Remote
CVE-2020-28023	Out-of-bounds read in smtp_setup_msg()	Remote
CVE-2020-28021	Nieuwe-regelinjectie in spool header file	Remote
CVE-2020-28022	Heap out-of-bounds read and write in extract_option()	Remote
CVE-2020-28026	Line truncation and injection in spool_read_header()	Remote
CVE-2020-28019	Ontbrekende Function pointer-reset na BDAT error	Remote
CVE-2020-28024	Heap buffer underflow in smtp_ungetc()	Remote
CVE-2020-28018	Use-after-free in tls-openssl.c	Remote
CVE-2020-28025	Heap out-of-bounds read in pdkim_finish_bodyhash()	Remote

Reacties (16)

Zijn er eigenlijk mensen die Exim gebruiken op een manier dat deze toegankelijk is vanaf het internet? Voor lokaal op je Debian is het een leuke lichtgewicht mailserver, maar heb al al te vaak gelezen dat je deze beter niet gebruikt voor extern te mailen.

Zijn er eigenlijk mensen die Exim gebruiken op een manier dat deze toegankelijk is vanaf het internet? Voor lokaal op je Debian is het een leuke lichtgewicht mailserver, maar heb al al te vaak gelezen dat je deze beter niet gebruikt voor extern te mailen.

Exim is zo'n beetje standaard bij de grotere partijen (zo'n 60% van alle mailservers zijn Exim) en is extreem feature-rijk. Je moet natuurlijk wel weten waar je mee bezig bent.

Ben dus wel benieuwd waar jij 'maar al te vaak' gelezen hebt om deze niet als MTA te gebruiken?!?

[Reactie gewijzigd door blaatenator op 6 mei 2021 18:36]

EXIM is veelvuldig in het nieuws geweest met exploits, recentelijk ook nog.
Postfix bijvoorbeeld, is voor het laatst ergens in 2006 voor het laatst in het nieuws geweest omtrent een "exploit".
Dan snap ik zijn reactie wel, je kan met postfix ook een heleboel doen wat Exim kan.

[Reactie gewijzigd door Power2All op 7 mei 2021 08:06]

Er hangen ongeveer 200.000 exim servers alleen in Nederland al aan het internet als je een simpele Shodan query draait.

Volgens mij gebruiken de bekende, commerciele hostingpanelen het standaard; dus Plesk, cPanel en DirectAdmin.

DirectAdmin en cPanel gebruiken Exim standaard. ISPConfig en Plesk gebruiken standaard Postfix - bij Plesk kun je dit volgens mij omzetten naar een andere MTA, zoals Exim.

Bij Plesk kun je kiezen uit qmail en postfix. Niet uit Exim.

Volgens mij is Postfix de default bij Plesk. Tenminste dat is wat ik de afgelopen 10 jaar gezien heb.

Hier staat wat info over de MTA's: https://mailtrap.io/blog/postfix-sendmail-exim/

Ik ben ook bekend met die term dat exim niet aan te raden is als mailserver, maar er staat me iets bij van een relay waar dat dan niet voor geld (anyway no proof); exim is nogal vaak lek (alles is uiteraard lek alleen exim wat vaker)

Exim is een voor de hand liggende keuze voor hosters door de flexibiteit. Het is een goede zaak dat er audits worden uitgevoerd op Exim. Daar wordt het alleen maar beter van. Het is misschien niet slim om na een security update over te stappen naar een andere mail server die de audit niet heeft gehad. Exim is nu juist veiliger geworden door de patches. De manier van programmeren in C kan wel structureel beter.

Postfix is gemaakt door een securityspecialist (Wietse Venema), dus daar ligt de nadruk wat meer op. Zoals hierboven gezegd is Exim een veel gebruikte keuze voor hosters.

Postfix is wel nog steeds een Sendmail volger. Dat wat Sendmail fout c.q. eigenzinnig doet, zoals bodies en headers aanpassen, doet Postfix ook. Iets minder asociaal, maar toch kun je op Postfix niet vertrouwen dat die de content van berichten met rust laat. Bij Exim kun je dat soort fratsen uitschakelen.

Gebruiken een Gmail en Microsoft Outlook ook deze software?

Google heeft zijn eigen MTA software en Microsoft gebruikt Exchange

De mailclient (Outlook) gebruikt eender welke SMTP server je em mee laat praten.

Relevante Debian pagina: https://www.debian.org/security/2021/dsa-4912

4.94.1, gelukkig is die al een poosje oude dus als je netjes update, zou het veilig zijn?

Alle kwetsbaarheden zijn juist gedicht in 4.94.2, welke recent is uitkomen. In de eerdere versie (4.94.1) waren alleen enkele kwetsbaarheden gepacht.

Zie https://lists.exim.org/lu...4.134007.ce022df3.en.html