Waarom nog steeds Exim gebruiken als er zo veel goede alternatieven zijn? Het omcatten van je config hoeft toch geen jaren te kosten?

Systemd:
https://docs.arbitrary.ch/security/systemd.html
https://gist.github.com/gwire/0edf28658e6638b3699f621b5d5c70ec
https://gist.github.com/martint17r/98a2ae5e657abaf76f3d07c0380e15d8
https://groups.google.com/g/linux.debian.bugs.dist/c/Ruk3ZLdISQU
https://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg1882678.html
https://jo-so.de/2021-05/Exim.html (ook AppArmor)

Exchange Online.......

Waarom veranderen van een service als je gewoon de boel kan patchen. Dat de vendor niet direct patched wil niet zeggen dat er niet allang patches zijn vanuit andere teams of een mitigation strategie is bedacht. Als je als bedrijf elke keer zou veranderen van service omdat er weer eens een zeroday is dan kan je dagelijks je bedrijf opnieuw gaan opzetten.

"Exim4 MTA CVEs assigned from ZDI"
https://seclists.org/oss-sec/2023/q3/254

Volgens Heiko Schlittermann (vrijwilliger bij Exim) staan er fixes klaar voor CVE-2023-42114, CVE-2023-42115 en CVE-2023-42116, maar die zijn nog niet vrijgegeven.

Mogelijk gerelateerd is deze commit op Exim github:
https://github.com/Exim/exim/commit/9b810c775c6e9dd1f8a87a743b943b465a1ca5a1

Blijkbaar is de communicatie tussen ZDI (Trend Micro) en de "maintainers" nogal slecht geweest.

De patches zijn momenteel alleen beschikbaar voor distributie maintainers volgens Gentoo: https://bugs.gentoo.org/show_bug.cgi?id=CVE-2023-42115

Sinds gisteren is de 4.79 RC1-1 van Exim beschikbaar bij Debian, maar die is niet aangegeven als gepatcht: https://security-tracker.debian.org/tracker/CVE-2023-42115

Exim heeft timeline aan distro's doorgegeven zegt Jeremy van het Exim project:
https://lists.exim.org/lurker/message/20230930.205045.d91489b2.en.html

De fixes zullen ook gereleased worden in v4.79.

Waarschuwing BSI: https://www.bsi.bund.de/SharedDocs/Cybersicherheitswarnungen/DE/2023/2023-266613-1032.html

Uitleg van Heiko Schlittermann over onder andere de belangrijke vraag waneer Exim kwetsbaar is en wanneer niet.
https://seclists.org/oss-sec/2023/q4/3

Het plan van het Exim project is om maandag 2 oktober 14:00 uur een deel van de fixes vrij te geven.
https://www.openwall.com/lists/oss-security/2023/10/01/7

Er komt dan ook een exim-4.96.1 security release met deze fixes.

Kleine correctie het gaat om 4.97 niet 4.79. Zou niet best zijn dan moeten we namelijk flink downgraden.

Waarom de CEO's positie aanhouden als hij een griepje heeft, en er zoveel goede schippers aan wal staan? Het vervangen van je personeel hoeft toch geen jaren te duren?

Als de CEO's conditie zodanig is dat ie een jaar geen vinger uitsteekt mag ie ook echt wel wieberen.

Een bug hebben is één ding, een security bug melding een dik jaar negeren is een indicatie van een project dat gewoon niet meer functioneert.


Fanboys moeten eens een dosis realisme krijgen.

Klop,t het moet zijn 4.97. Ik kan het bericht niet aanpassen.

Ik denk dat je weinig fanboys hier van EXIM gaat vinden. De meeste zullen hier gewoon mee moeten werken omdat de infra erop ingericht is. Alle MTA's zijn draken van software implementatie en onderhoud. Realisme is dat bugs, zerodays soms maanden of jaren in een product zitten en je conditional migitation ervoor toepast tot er een officiele fix is.

En meeste security bugs in goede configuraties kunnen zelf niks uithalen. Dit soort kwetsbaarheden vereisen specifieke actieve modules over het algemeen of slechte basis configuraties. Alsof je dus een gat hebt zitten in de middels muur van je bouwerk maar de buitenste gewoon prima is. Liever natuurlijk geen enkel gat maar niet direct iets om ook zorgen om te maken zolang je goed je netwerk monitored en audit.

We hebben onze infra al gecontroleerd en van de 6 zerodays was er 1 met verhoogd risico waar we zelf weer maatregelen op hebben genomen en nu staat het waiting on vendor met known issue flag onze vendor geeft aan deze week met de fixes zelf te komen. Just a ordinary office day.

Geen excuus voor de EXIM devs of enig ander bedrijf om te lanterfanten qua beveiliging en patching maar nog jij nog ik kan ze hier in beweging krijgen. Dus je kan klagen wat je wilt het gaat geen effect hebben daar heb je bureaus als ZDI voor die ze een PR schop kunnen geven.

Degene op wie ik reageerde (2 okt 09:29) leek de gang van zaken bij Exim wel acceptabel te vinden en geen reden om de platform keuze te herzien.

M.i. is realisme toch ook dat je vendoren (inclusief open source projecten) met een ondermaats track record in het _oplossen_ van gerapporteerde security bugs gaat herzien als leverancier.

Een MTA zit vaak op een kritische plek - namelijk Internet-facing .
Dan moet de lat gewoon hoog liggen.


Tsja, tcp/25 is gat -door- je buitenste muur , en producten op die plek moeten hun broek heel goed kunnen ophouden.


Klopt - patchen en supplier waiting is een fact of life.


Dat is wat aan het gebeuren is.
Of dus projectje 'exim vervangen' opstarten , en zeker als het om de internet-facing MTA gaat .
Stemmen met de voeten kan ook.

Hier iets roepen helpt (heel misschien) een klein beetje om andere beheerders dat zetje te geven dat niet alleen bugs, maar ook de respons erop een deel moeten zijn van je keuze criteria voor een bepaald product / project .

https://ftp.exim.org/pub/exim/exim4/ bevat nu 4.96.1 met een deel van de security patches.

Exim's documentatie: https://exim.org/static/doc/security/CVE-2023-zdi.txt

En dat is waarom je ook server hardening uitvoert en extra beveiliging lagen hebt.

Je gaat er doodleuk vanuit dat poort 25 uberhaubt open zou staan en als hij wel open was mag ik toch echt hopen dat die gene nog een firewall ertussen zitten heeft naast een IDS platform en SIEM koppeling.

Dit zijn beslissingen waar maanden overheen kunnen gaan en zeker niet gebaseerd op 1 incident melding bij grote netwerken. Stemmen met de voeten gebeurt uiteindelijk door de aandeelhouders en hoger management. Geen simpel projectje te noemen naast dat je moet uitzoeken hoe het zit met je andere vendors als ook klanten wensen. Om voorbeeld te geven cPanel/ WHM werkt enkel met EXIM en postfix integratie is niet mogelijk. Dan moet je je cPanel er ook uitgooien of mailing omzetten naar apart cluster zoals Amazon SES.

Maar dan ben je er nog niet dan moet klanten instrueren dat hun webmail GUI en adres mogelijk verandert. Je moet rekening houden met dat er mogelijk configuratie conflicten ontstaan dat je data niet allemaal direct converteerbaar is en dus handmatig geimporteert moet worden timestamp conflicten kunnen ontstaan. Naast dat je SOC ineens heel anderere netwerk verbindingen registreert die allemaal geaudit en gewhitelist moeten worden voor in gebruikname mogelijk ook nog IPwarming uitvoeren met paar honderduizen tot miljoenen berichten.
Nog niet te hebben over je interne documentatie of wachten op certificering herzieningen en aanpassing in privacy policy.

Kortom echt geen *projectje*

Ik betwijfel ten zeerste dat enige ITer in een positie tot bedrijfs infraherstructurering zich gaat baseren op informatie van een relatief klein nederlands forum dan wijk ik toch echt sneller uit naar een hosting gespecialiseerd forum en discussie groep van provider partners. Daarnaast heb je security consultants voor dit soort zaken alsmede vendor gesprekken naar aanleiding van post mortems.

Ah, dat ben ik. Inderdaad correct geextraheerd.

Maar, als CEO houd ik mij altijd aanbevolen voor verbeteringen, maar eis dan wel dat die suggesties werkelijk verbeteringen zijn. Desgewenst mag je mij gerust fanboy noemen, daar ik het al zo'n kwart eeuw gebruik, en daarvoor qmail.

Maar om nog wel wat nuance aan te brengen, ben ik niet geheel imbeciel (vind ik zelf dan), en kijk ik het nog wel even aan.
Mocht het werkelijk allemaal zo fataal en critical zijn, in mijn use-case, dan zal ik mijn mening daarop wellicht gaan herzien.

En je platform zorgvuldig uitkiest.

Voor een Internet facing MTA ga ik er inderdaad vanuit dat TCP/25 openstaat .
Niet zo'n gekke aanname toch ?

Firewall en IDS zijn zo ontzettend nutteloos als het om TLS sessies gaat.

Natuurlijk kun je een stuk relaxter kijken als je deze MTA alleen op interne servers gebruikt.


Onzin - (externe) aandeelhouders gaan niet over MTAs of vendor C/J/H zitten zeuren. In een kleine BV is het het misschien de DGA die met alle petten (w.o. die van GA ) op beslist .

(Hoger) management gaat over een Opex/Capex budget , en aandeelhouders uiteindelijk over winstverwachting en bedrijfsrisico's.
De input dat in plaats van het nalopen, of band-aiden van een high-maintenance product of platform (cq risico lopen met een slecht onderhouden platform) men beter af zou zijn met een migratie naar iets anders komt van middenmanagement , en evt hoger management [CISO office] .

Het zal zelden of nooit een acute crash actie zijn om een bepaald product NU te vervangen, dat klopt.

Maar voor elk product heb je (mi) een soort van 'moving avarage satisfaction score' , en wordt of een keer de grens bereikt, of wordt het meegenomen bij een (nieuwe) opzet "niet meer op basis van product X" , dan wel " dit is echt wel de druppel , we gaan nu een migratie project opstarten" .


Ok, met die dependencies is het een forse klus . Otoh - je eerste priotiteit zouden de internet facing MTAs moeten zijn voor dit type bugs , en daar kun je echt wel een andere voor/tussen schuiven.
Hoef je ook geen nieuwe adressen op te warmen.


Er zitten hier ontzettend weinig mensen die uberhaupt _werken_ in de IT, zo lijkt het inderdaad.

Degenen die dat wel doen - je zou toch geen consultancy nodig moeten hebben om een paar heel dikke minnen te zetten bij een project/product/vendor dat een jaar lang niks doet met serieuze security bugs.
- En dat voor iets waarvoor Internet facing een 'normale' deployment zou moeten zijn. Bij Enterprise (en scada) vendors ligt de verwachtingslat wat lager.