Exim CVE-2019-13917 – Die Katze ist aus dem Sack

Ich habe es geahnt, natürlich war die String-Expansion vom letzten Exim Exploit nicht nur dort im Einsatz, sondern auch an anderer Stelle:

CVE-2019-13917 – Root Access für lokale und entfernte Benutzer.

Betroffen sind alle aktuellen(und nicht mehr ganz so aktuellen) Exim Versionen 4.85 -> 4.92.

Laut Jeremy Harris besteht die Lücke wie schon beim letzten Exim Exploit in einer String-Expansion-Operation.

Wir erinnern uns: Ein Angreifer konnte vor einem Monat „<${run{bash}}@zieldomain.de>“ als Absender oder Empfänger einer Email setzen und hatte freien Zugang zum System.

So geht das jetzt auch wieder. Diesmal ist es die „Sort“-Funktion, die Einträge, naja, sortiert halt. Wenn ein Angreifer dort Einträge beisteueren kann, wie z.b. einen modifizierten Received-Header, oder multiple Empfängernamen und der angegriffene Server sortiert diese Einträge, für was auch immer er das bräuchte, dann würde der Text des Angreifers ausgeführt.

In PHP nennt man das die EVAL()-Falle. Ist halt immer blöd, wenn man ungeprüft Sachen von fremden Leuten ausführt 😉

Seid Ihr betroffen?

Das ist leicht festzustellen:

exim -bP config | grep -i sort

als Root ausführen und wenn da nichts kommt, dann seid ihr sicher. Da es in der Default Konfig nicht vorkommt, würde sich ein betroffener Admin jetzt direkt daran erinnern, daß er da was sortiert hat und könnte jetzt Updaten. „Könnte“ weil Fedora User nicht können, in der Rebuildversion von heute liest man leider nur das :

* Thu Jul 25 2019 Fedora Release Engineering <releng@fedoraproject.org> – 4.92-9
– Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild

Von CVE liest man nichts, oder Ihr vielleicht? Das ist jetzt peinlich, weil die Exim-Devs das allen Distros rechtzeitig mitgeteilt haben.

Workaround:

Sort-Funktion auskommentieren, siehts zwar nicht mehr schön aus, ist aber sicher 😉

 

 

Firefox: ungepatchte 17 Jahre alte Sicherheitslücke

Wie uns die TheHackerNews heute mitteilen, gibt es im Firefox eine ungepatche Sicherheitslücke, die streng genommen, seit 17 Jahren im Firefox schlummert.

Same-Origin-Policy versagt

Die Same-Origin-Policy versagt bei Zugriffen auf „file://“ URLs. Was andere Browser schon vor Jahren behoben haben, ist für die Firefox Entwickler nicht wichtig, da es bislang keinen Exploit dafür gab. Das hat sich geändert:

Was wir hier sehen, wenn das Bild denn scharf wird (runterladen per youtube-dl hilft dabei), ist folgendes:

Eine Email mit einem HTML Attachment wird in einem Webmail geöffnet.
Die HTML Datei wird von Firefox abgespeichert, wie man sieht im HOME des Users!
Die HTML Datei wird mit Firefox über file://…  geöffnet und ..
präsentiert uns den Inhalt des Verzeichnisses.

Die HTML Seite enthält Javascriptcode, der über die File und Fetch Api vom Browser das Verzeichnis und die Dateien ausliest und dann mit AJAX die Daten exfiltriert.

Ein Patch dafür ist nicht in Arbeit, da Mozilla die Lücke nicht als solche anerkennt. Mal sehen ob sich das jetzt ändert 😉

Quelle: https://thehackernews.com/2019/07/firefox-same-origin-policy-hacking.html

Quickfix: Exim <= 4.91 for CVE-2019-10149

Ok, Exim 4.87 < 4.92 has a serious security hole, which can also be trivially exploited: CVE-2019-10149

A lot of fuss has been made about the weak point, but unfortunately nobody has been able to tell whether it can be fended off without an update. Let’s have a look at what it’s all about.

What is the trivial exploit?

As a local attacker it is enough to send an email with Exim’s sendmail replacement to „<${run{bash}}@zieldomain.de>“. At the moment it is delivered, the embedded command (here bash) is executed as root.

The whole thing can also be executed remotely, so it’s a really nasty vulnerability. But only versions > 4.87 < 4.92 are affected. For this, however, various things must be allowed in the config, which is only partially the case in the default configuration. For example, you cannot include a „/“ in the command because these are illegal characters. This of course restricts the attacker from being strong.

Since even on the exim list there was a lot of secrecy in the game until today, here are the equally trivial countermeasures:

Countermeasures

Just don’t allow „$“ in email addresses 😀 That’s it. There only ARGS came to my mind 😀

This comes into your Exim configuration, then restart Exim:

acl_check_rcpt:

deny message = Restricted characters in address
domains = +local_domains
local_parts = ^[.] : ^.*[\$@%!/|]

deny message = Restricted characters in address
domains = !+local_domains
local_parts = ^[./|] : ^.*[\$@%!] : ^.*/\\.\\./

….

acl_check_mail:

…

drop message = Restricted characters in address
condition = ${if match{$sender_address}{\N.*\$.*run.*\N}{1}{0}}}

# IMPORTANT: Write in before these instructions, otherwise it’s not working!

accept hosts = +relay_from_hosts

…

This chokes off the attacker before the email is delivered.

The better countermeasure would of course be to switch to a more recent Exim. But as it is, there are always „reasons“ why and why something can’t be updated.

Nobody gets his teeth apart…

What annoys me most of all about the gap is that this cheap countermeasure does not appear in the Advisory of Qualys and in the hints of the Exim Team. With the Exim people I can still understand it, because they had fixed the bug independently already at the beginning of the year and can say justly: Just do updates.

Qualyss looks different, they write :

As per the distros list policy:

Below is an abridged version of our advisory (with all the vulnerability
details, but without exploitation details); we will publish the complete
version in 24 hours, or as soon as third-party exploits are published,
whichever happens first.

We believe that it makes no sense to delay this any longer than that:
this vulnerability is trivially exploitable in the local and non-default
cases (attackers will have working exploits before that, public or not);
and in the default case, a remote attack takes a long time to succeed
(to the best of our knowledge).

Nice that you omitted the exploit, how about the workaround, so that the good guys have a small lead?  And this cryptic hint „a remote attack takes a long time to succeed“ means that you should restart your exim every 24h, because there is some shit with „tar pits“.

These are usually spam traps that respond so slowly that the attacker’s attack is just as tough as in a tar pit, up to „no progress at all“. The attackers take advantage of something like this here. Therefore once in the cron „killall -9 exim; systemctl restart exim“ daily  : Done.

A follow-up of the aftermatch and some real exploits can be found here: Exim – Exploit in der Wildnis unterwegs

Translated with www.DeepL.com/Translator

BTW: yes, ofcourse i could have written it in english myself, but the translation isn’t that bad 😉