Kwetsbaarheid in Exim-mailservers maakt remote code execution mogelijk

Er zit een groot lek in de mailservers van Exim. Servers waar de populaire e-mailsoftware op draait zijn kwetsbaar voor remote code executions die zelfs met root-toegang konden worden uitgevoerd. Er is inmiddels een patch beschikbaar.

De kwetsbaarheid krijgt de trackingcode CVE-2019-15846 mee. Het lek zit in Exim-versies van 4.80 tot en met 4.92.1. De kwetsbaarheid werd ontdekt door een beveiligingsonderzoeker die het doorgaf aan Exim. Inmiddels is er een patch uitgebracht, zegt het bedrijf. Ook het Nationaal Cyber Security Centrum adviseert systeembeheerders die patch door te voeren. Er zouden in Nederland minstens 183.000 systemen actief zijn waar Exim op draait.

De kwetsbaarheid bestaat uit een buffer overflow in het smtp-proces. Tijdens het opzetten van een tls-verbinding kunnen aanvallers een eigen ServerName Indication sturen, of een eigen tls-certificaat naar de server sturen. Op die manier kunnen aanvallers zowel lokaal als van een afstand code uitvoeren of programma's draaien met root-rechten. Volgens Exim zijn alle mailservers kwetsbaar die tls-verbinding accepteren. Het is daarbij niet relevant welke tls-libraries dat zijn. Zowel GnuTLS als OpenSSL zijn kwetsbaar. Tls-verbindingen staan niet standaard open in de configuratie van Exim. Systeembeheerders die om één of andere reden niet kunnen updaten kunnen er ook voor kiezen tls-verbindingen in het geheel niet meer toe te staan op de server. De makers van Exim waarschuwen echter dat dat geen perfecte oplossing is.

Exim zegt dat er tot nu toe nog geen voorbeelden bekend waarbij het lek actief wordt uitgebuit, maar er zou inmiddels wel een proof-of-concept beschikbaar zijn. Ook het NCSC waarschuwt dat misbruik 'op korte termijn' kan gebeuren nu meer details over het lek bekend zijn. De kwetsbaarheid in Exim is de tweede in korte tijd. In juni bleek er ook al een groot lek in de mailservers te zitten. Daarmee was het mogelijk root-toegang te krijgen via ssh.

Reacties (38)

[Sfynx]

Het valt me op dat Exim wel vaker dit soort dingen heeft terwijl ik in de ruim 10 jaar dat ik Postfix gebruik niet echt kan herinneren wanneer ik voor het laatst halsoverkop mijn servers moest updaten vanwege deze reden. Draai Exim wellicht wat meer dingen onnodig als root? Naast de Postfix master (die netwerkverbindingen accepteert en de andere processen start) en de lokale delivery agent (die in ieders homedir moet kunnen schrijven) is er niet echt een reden om iets als root te draaien i.i.g.

Het geeft ook wel aan dat extra maatregelen zoals SELinux of FreeBSD jails geen overbodige luxe zijn bij dit soort zichtbare services.

[kozue]

Dat ze niet gevonden worden zegt niet dat ze er niet in zitten. Voor zover ik weet worden er meer bugs gevonden in Linux dan in Windows, maar komt dit niet omdat Windows veiliger is, maar omdat niemand behalve MS de code van Windows heeft en daar dus nog veel ongepatchte lekken in zitten. Alle complexe software bevat nou eenmaal fouten en MTA's zijn daarop geen uitzondering. Je hoeft je met postfix of sendmail echt niet veiliger te voelen dan met exim, of exim af te gaan branden omdat ze nu een bug gefixed hebben (na deze fix is exim weer een stukje veiliger dan daarvoor).

[edit:] overigens draait exim niet als root op degelijke systemen. Onder debian bv draait het onder de beperkte Debian-exim gebruiker en heeft dus nergens toegang toe waar het niet bij hoort te kunnen.

[Reactie gewijzigd door kozue op 24 juli 2024 05:58]

[The Zep Man]

Het valt me op dat Exim wel vaker dit soort dingen heeft terwijl ik in de ruim 10 jaar dat ik Postfix gebruik niet echt kan herinneren wanneer ik voor het laatst halsoverkop mijn servers moest updaten vanwege deze reden.

*Kuch*

Misschien niet halsoverkop, maar heb niet de illusie dat één softwareproduct veiliger is dan de ander enkel omdat er minder kwetsbaarheden voor verschijnen.

Het geeft ook wel aan dat extra maatregelen zoals SELinux of FreeBSD jails geen overbodige luxe zijn bij dit soort zichtbare services.

Eens. Maar hou ook rekening met bijvoorbeeld IPS systemen om deze aanval vroegtijdig te herkennen (voordat de software van een update kan worden voorzien) en voor TLS offloaders die sneller geactualiseerd kunnen worden en vaak een minder groot aanvalsoppervlak hebben, die deze kwetsbaarheid ook hadden kunnen voorkomen.

[Reactie gewijzigd door The Zep Man op 24 juli 2024 05:58]

[Goldwing1973]

Een bijna 9 jaar oude *Kuch*

Maar @Sfynx heeft wel gelijk, er zijn veel vaker fouten gevonden in Exim dan in Postfix.

Lijst van Exim fouten

Lijst van Postfix fouten

[Jerie]

Lijst van Qmail fouten:

[mrmrmr]

Qmail's laatste officiele release is van 1998. Die heeft geen moderne functies zoals TLS.

[Jerie]

Hoeft ook niet: https://www.fehcom.de/ipnet/ucspi-ssl.html

[Sfynx]

Een bijna 9 jaar oude *Kuch*

En ook niet echt vergelijkbaar met deze vind ik, want dat Postfix lek was alleen uit te buiten als je bepaalde login methodes in de Cyrus SASL library gebruikte, en dan kon je eventueel als de 'postfix' user code uitvoeren en niet als root, omdat Postfix een hoop processen niet als root uitvoert omdat het simpelweg niet nodig is. Destijds was ik overigens niet vatbaar voor dat lek, ik gebruikte heel die Cyrus library niet en verbond destijds al met een Dovecot SASL socket voor mijn SMTP authenticatie.

[Reactie gewijzigd door Sfynx op 24 juli 2024 05:58]

[zenlord]

"... die zelfs met root-toegang konden worden uitgevoerd"
Er is bij mijn weten vrij weinig dat je niet kan uitvoeren met root-toegang

[sympa]

Veel servers draaien niet als root, dus een exploit dan ook niet. Helaas hebben mailservers vaak een faciliteit die nog stamt uit de tijd van inlogaccounts waar je mail in een file in je homedirectory kwam. Daarvoor moet de mailserver in alle gebruikersdirectories kunnen, en daarvoor zijn dan rootrechten nodig.
Dat maakt mailservers extra gevaarlijk bij lekken.

[wica]

Eigenlijk is de enigste reden om iets te starten als root, is als het een poort onder de 1024 nodig heeft. Zo genoemde Priviliged ports..

Maar gelukkig kunnen we de user root vandaag de dag ook erg beperken met o.a. selinux.

[Freeaqingme]

Waarom? Assign capability CAP_NET_BIND_SERVICE aan die binary, en je kan als reguliere user draaien terwijl je wel port <1024 kan binden.

[wica]

Merci, zou je graag een +3 geven.

[Rudie_V]

Dan moet je eerst beoordelen en dan pas reageren.

[The Zep Man]

Eigenlijk is de enigste reden om iets te starten als root, is als het een poort onder de 1024 nodig heeft. Zo genoemde Priviliged ports..

Wat in veel situaties niet uitmaakt, want er vindt toch een vorm van NAT of port translation plaats. Intern is voor SMTP TCP poort 1025 of 10025 net zo goed als poort 25, zolang extern maar poort 25 gebruikt wordt en deze correct wordt doorgestuurd naar de interne poort. Via het proxy protocol kan de mailserver toch weten waar de originele verbinding vandaan komt (o.a. voor logging, anti-spam, etc.).

Hetzelfde principe werkt ook voor bijvoorbeeld webservers, zoals NGINX. Die hebben ook ondersteuning voor het proxy protocol.

Het probleem wat @sympa ook noemt (proces moet iets wegschrijven in home directories van gebruikers) kan ook met extended file system permissions opgelost worden, waardoor de UNIX owner en group op naam van de gebruiker kan blijven staan voor backwards compatibility. Er zijn dan geen root rechten nodig.

[Reactie gewijzigd door The Zep Man op 24 juli 2024 05:58]

[wica]

Ik heb voor het laatst ergens begin deze eeuw. Nog een mail server op die manier opgeleverd. Daarna vooral via virtual accounts en moesten mensen het via pop of imap ophalen.

Heel simpel gezegd, het is al ruim 20 jaar niet meer nodig, om i.v.m. file rechten een mail server als root te draaien.

Ik loop vaker tegen "Priviliged ports" aan, omdat je simpel weg niet elke service op een poort > 1024 kan draaien. Zonder alles in je netwerk aan te passen.

Hetzelfde principe werkt ook voor bijvoorbeeld webservers, zoals NGINX. Die hebben ook ondersteuning voor het proxy protocol.

Dan draait je mail server niet als root, maar NGINX weer wel.

[sympa]

Poort 25 is ook prima te 'binden' waarna de applicatie de rootrechten laat vallen. En nu is er ook die capability, maar dat probleem heeft een webserver ook en daar was het ook al opgelost.
Alleen een mailserver houdt die rootrechten om die lokale mail te kunnen droppen.
Echt niet van deze tijd, mail in directories van users droppen. Alleen handig voor mensen die hun mail uitsluitend van een shellaccount lezen.

[Reactie gewijzigd door sympa op 24 juli 2024 05:58]

[The Zep Man]

Dan draait je mail server niet als root, maar NGINX weer wel.

Met de omschreven methode hoef je juist NGINX niet als root te draaien.

[Freeaqingme]

Je hebt het eerst over NAT, dat gebeurt in principe op layer 3+4. Daarmee kan je prima het oorspronkelijke source adres+poort in de IP headers laten staan, waardoor je geen proxy protocol nodig hebt.

Het proxy protocol is vooral zinvol wanneer je een layer 7 proxy gebruikt en je niet de oorspronkelijke source ip+port kan laten staan (wat vunzige hacks met TPROXY daargelaten). Echter, dan moet die layer 7 proxy alsnog op poort 25 luisteren. Nou ben ik geneigd te zeggen dat een (layer 7) http proxy minder vatbaar is voor een remote execution aanval dan een mail server, maar technisch gezien kan het nog steeds.

[DDX]

Of probleem dat je op linux niet eenvoudig poorten lager dan 1024 kan gebruiken als non-root user.
Er zijn verschillende trucjes voor maar ook een paar waar je mogelijk dus misbruik van kan maken als de software kwestbaar is.

[Gwaihir]

Dus hoort er ook vrij weinig te zijn dat je (zo maar) die root toegang geeft..

-- je leest de zin denk ik net andersom dan hij bedoeld is.

[RoestVrijStaal]

Dan moet je jezelf in dezelfde usergroup zetten als die van de daemon waarvan je zijn bestanden wilt CRUD-en.

Of zelf een usergroup maken die de juiste rechten heeft op de plekken die de daemon aanraakt en forceren dat de daemon draait onder die usergroup en jezelf in de usergroup zetten.

[ipsec]

Pasgeleden was er ook al zo’n mooi lek bij Exim die ook nog vrij rap misbruikt werd.

Wij hebben vooral DirectAdmin machines draaien, die hebben standaard Exim aan boord. Als je DA hebt en meteen wilt/kunt patchen, dan moet je de downloadserver even op files.directadmin.com zetten. De andere mirrors hebben de gepatchte versie nog niet gesynchroniseerd.

[DJMaze]

cPanel is ook al gepatcht:
- 78.0.38
- 82.0.14
https://documentation.cpa...y/CKB/CVE-2019-15846+Exim

[Reactie gewijzigd door DJMaze op 24 juli 2024 05:58]

[freddieleeman]

Systeembeheerders die om één of andere reden niet kunnen updaten kunnen er ook voor kiezen tls-verbindingen in het geheel niet meer toe te staan op de server.

Dit is overigens geen optie als je MTA-STS of DANE hebt geconfigureerd. Je zult dan geen mail meer ontvangen van mailserver die deze mechanismen ondersteunen.

[mocean]

Dat is nogal een lek zeg! Slecht als bij zo'n programma de binnenkomende data (nooit te vertrouwen) voor een buffer overflow kan zorgen. Dat moet echt wel in je testproces zitten en afgevangen worden in de code.

[TommieW]

Een buffer overflow kan op ontzettend veel manieren veroorzaakt worden, vaak ook op ontzettend niet voor de hand liggende manieren. Als het mogelijk was om te testen op alle mogelijke lekken, hadden we geen zero-day vulnerabilities meer in de wereld.

[wica]

Ben het me je eens, dat het soms heel moeilijk kan zijn om een bug, die een buffer overflow veroorzaakt, te vinden.
Maar is een NULL character \0 bijzonder? Volgens mij zijn hier in het verleden al wel vaker problemen mee geweest.

[Saven]

Lekker dan, miljoenen servers die dit draaien. En ik verwacht echt niet dat meer dan 10% op korte termijn een update doorvoert. Leuk speelgoed voor scriptkiddies de komende maanden...

[WhiteDog]

Dat zal wel meevallen, bij de meeste implementaties zal het gewoon als update mee binnenkomen. Mijn servers waren al gepatched tegen dat ik er hier over gelezen heb.

[Saven]

Bij DirectAdmin servers iig niet. En dat zijn er veel.

[freddieleeman]

Inmiddels wel via het custombuild script.

[Beunhaas91]

/usr/local/directadmin/plugins/custombuild/admin/build exim

[Timdows]

Te updaten via

cd /usr/local/directadmin/custombuild
./build update
./build set exim yes
./build exim

[sdk1985]

./build set exim yes impliceert dat je het eerst niet gebruikte, dus dat lijkt me niet zo'n handig commando.