ROOT Exploits in Exim < 4.94.2

Ihr fragt Euch vermutlich, wieso sich so lange gebraucht habe, das zum Thema zu machen, weil die Nachricht ja gestern noch raus kam. Der Grund ist: Sichern, Suchen und Patchen was das Zeug hält.

ROOT Exploits in Exim < 4.94.2

Insgesamt sind es 21 Lücken, welche die Pentester von Qualys gefunden haben:

Summary
Local vulnerabilities
- CVE-2020-28007: Link attack in Exim's log directory
- CVE-2020-28008: Assorted attacks in Exim's spool directory
- CVE-2020-28014: Arbitrary file creation and clobbering
- CVE-2021-27216: Arbitrary file deletion
- CVE-2020-28011: Heap buffer overflow in queue_run()
- CVE-2020-28010: Heap out-of-bounds write in main()
- CVE-2020-28013: Heap buffer overflow in parse_fix_phrase()
- CVE-2020-28016: Heap out-of-bounds write in parse_fix_phrase()
- CVE-2020-28015: New-line injection into spool header file (local)
- CVE-2020-28012: Missing close-on-exec flag for privileged pipe
- CVE-2020-28009: Integer overflow in get_stdinput()
Remote vulnerabilities
- CVE-2020-28017: Integer overflow in receive_add_recipient()
- CVE-2020-28020: Integer overflow in receive_msg()
- CVE-2020-28023: Out-of-bounds read in smtp_setup_msg()
- CVE-2020-28021: New-line injection into spool header file (remote)
- CVE-2020-28022: Heap out-of-bounds read and write in extract_option()
- CVE-2020-28026: Line truncation and injection in spool_read_header()
- CVE-2020-28019: Failure to reset function pointer after BDAT error
- CVE-2020-28024: Heap buffer underflow in smtp_ungetc()
- CVE-2020-28018: Use-after-free in tls-openssl.c
- CVE-2020-28025: Heap out-of-bounds read in pdkim_finish_bodyhash()
Acknowledgments
Timeline

Davon konnten 4 Lücken genutzt werden um die Rechte zu Root auszuweiten und 3 für Remote-Code-Executions genutzt werden, was in der Kombination nichts anderes bedeutet, als daß die Angreifer die Server übernehmen können.

„We have not tried to exploit all of these vulnerabilities, but we successfully exploited 4 LPEs (Local Privilege Escalations) and 3 RCEs (Remote Code Executions):“

Ich vermute ja, daß diese Lücken durch eine automatische Code-Analyse gefunden wurden, da ich mir kaum vorstellen kann, das ein Mensch das alles so überblicken wird. Auch den Exim-Devs wurde nicht gesagt, wie die Lücken gefunden wurden. Aber auch hier die Vermutung, daß es mit automatischen Tools und sehr viel Erfahrung der Analysten geschafft wurde.

Auf der Exim-Mailingliste wurde dies von einigen negativ hervorgehoben, wobei man immer bedenken muß, daß alle Exim Entwickler auch noch ein Berufsleben haben. Wenn dann die Patche nicht mehr kaputt machen sollen, als die Lücken selbst, kann das schon ein bisschen dauern.

Ein bisschen gedauert hat es dann auch, bis z.b. Fedora die neue Exim Version ins Stable übernommen hat. Dies geschah erst durch Benutzerintenvention ( meine 😉 ) einen Tag nach der Veröffentlichung der Lücken. Für das im Endstadium befindliche Fedora 32 gab es den Fix nicht mehr, weswegen ich jedem nur raten kann, auf 33 zu updaten, wenn er Exim betreibt.

DNF: das neue YUM, oder?

DNF ist seit Fedora 21 das Tool für Softwareupdates.  DNF soll die Probleme von YUM lösen, indem es andere Algorithmen zur Abhängigkeitsauflösung anwendet, unter anderem.

Zunächst mal muß man keine Angst vor der Umstellung haben, denn DNF ist sogut wie es geht YUM kompatibel, was die Befehle in der Shell angeht, und YUM kann zur Not auch weiter verwenden. Das geht so gut, daß die gleichen alten Probleme auf die gleiche Art gelöst werden müssen.

Ich hatte ja mal gezeigt, wann und wie man Updates abschaltet:

# cat /etc/yum.conf 
[main]
cachedir=/var/cache/yum/$basearch/$releasever
keepcache=0
debuglevel=2
logfile=/var/log/yum.log
exactarch=1
obsoletes=1
gpgcheck=1
plugins=1
installonly_limit=3
exclude=qmmp* gedit*
...

DNF gibt sich da etwas schlanker :

# cat /etc/dnf/dnf.conf 
[main]
gpgcheck=1
installonly_limit=3
clean_requirements_on_remove=true
exclude=gedit*

Es macht aber am Ende genau das gleiche.

Warum habe ich jetzt Gedit von weiteren Updates ausgenommen ?

Für alle die es nicht wissen, Gedit ist der standardmäßig installiere Texteditor für Gnome. In Fedora 20 war er : schlank, schlicht, schnell, nützlich. Mit dem Update auf Fedora 21 fallen mir nur folgende Attribute ein: Mozilladesign, unnütz, bloated (rpms), absoluter Schrott.

Gedit war in Fedora 20 der mit Abstand nützlichste Editor, weil er optisch nicht so überladen war wie z.b. Blue Fish, aber dennoch alles hatte : Tabs, Syntaxhighlighting, Rechtschreibkorrektur und Platz!

Die neue Version ist umgangssprachlich für den Arsch. Die Menüführung ist abenteuerlich und komplett umständlich. Die Icons sind weg, man müßte jetzt Menüfunktionen aufrufen. Das Layout ist überdesigned zur absoluten Nutzlosigkeit verschönt. Ganz sicher mußte der Designer diese Änderungen nicht mit seinem Geditdesign machen, sonst wäre ihm aufgefallen, was für einen Müll er da produziert. Ist ja häufig so, daß Produkte bis zur Unkenntlichkeit umdesigned werden, nur damit man mal was gemacht hat als Hersteller. Ob das Update am Ende nützlich war, interessiert doch am Ende keinen mehr, Hauptsache es ist neu.

Zu allem übel, kann man den Gedit nicht optisch auf nützlich zurückstellen, weswegen es tatsächlich nur zwei Lösungen gab: 1. Auf einen anderen Texteditor umsteigen oder 2. yum erase „gedit*“; rpm -i –nodeps gedit*f20*rpm .

Jetzt gibt es zwei Wege an die RPMS zu kommen:

1. KOJI benutzen. Das hat aber trotzdem noch viel Gesuche zur Folge.

oder 2. Einfach im alten Fedora 20 Repository nachsehen:

# cat /etc/yum.repos.d/fedora.repo 
[fedora]
name=Fedora $releasever - $basearch
failovermethod=priority
#baseurl=http://download.fedoraproject.org/pub/fedora/linux/releases/$releasever/Everything/$basearch/os/
metalink=https://mirrors.fedoraproject.org/metalink?repo=fedora-$releasever&arch=$basearch
enabled=1
metadata_expire=7d
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$releasever-$basearch
skip_if_unavailable=False
...

Die BaseURL zeigt wird nun einfach etwas angepaßt und dann im Browser aufgerufen ( bitte: Nicht bei Google eingeben, sondern in die Adressleiste des Browsers! ). Das wäre dann diese hier:

http://download.fedoraproject.org/pub/fedora/linux/releases/20/Everything/x86_64/os/

Der Repobesuch mit dem Browser erlaubt auch eine einfache Navigation durch die Repos, was bei Koji nicht der Fall ist. Damit kann man viele Programme sehr viel schneller finden, als im Koji Buildsystem.

Nachdem die RPMS auf der Platte geparkt wurden, müssen Sie dan mit rpm -i --nodeps installiert werden, weil die Abhängikeiten im RPM natürlich auf Fedora20 lauten und nicht auf Fedora 21 Pakete. Wer sich mit dem Gedanken trägt sein Gedit auch zu downgraden, der sollte folgende Pakete nehmen, die restlichen sind so schwer abhängig, das klappt vermutlich nicht:
2588 -rw-rw-r--. 1 marius marius 2646356  5. Jul 23:26 gedit-3.10.2-1.fc20.x86_64.rpm
  16 -rw-rw-r--. 1 marius marius   13944  6. Jul 00:04 gedit-beesu-plugin-0.4-13.fc20.x86_64.rpm
 124 -rw-rw-r--. 1 marius marius  124560  6. Jul 00:04 gedit-code-assistance-0.2.0-4.fc20.x86_64.rpm
  56 -rw-rw-r--. 1 marius marius   53584  6. Jul 00:04 gedit-cossa-3.2.0-6.fc20.x86_64.rpm
 836 -rw-rw-r--. 1 marius marius  853444  5. Jul 23:26 gedit-plugins-3.10.0-1.fc20.x86_64.rpm
  20 -rw-rw-r--. 1 marius marius   16920  5. Jul 23:26 gedit-zeitgeist-3.10.2-1.fc20.x86_64.rpm

Damit ist Gedit dann wieder einsetzbar. Sieht zwar nicht mehr so schick auch wie früher, aber es tut seinen Job.

Sicherheitslücke im Gnome 3 Desktop

Im Gnome 3 Desktop klafft mindestens seit der Version für Fedora 18 eine Sicherheitslücke.

Diese betrifft i.d.R. Benutzer eines Laptops, da diese das Laptop öfters in den Suspend-on-Disk Modus versetzen um Energie zu sparen, auf Deutsch: Den Deckel zu machen 😉

Wenn das passiert, wird der Bildschirm schwarz, weil er ausgeht. Wenn der Bildschirm wieder angeht, sieht man auf einigen Rechnern den Inhalt des Desktops vor dem Suspend, bis der Screensafer einsetzt und dem ganzen einen Riegel vorschiebt:

Am 9.12.2015 wurde die Lücke zum zweiten Mal an Fedora und damit an Gnome gemeldet.

Ein zweites Mal ? Ja, genau. Schon in Fedora 18 wurde auf einem Laptop dieser Effekt bemerkt und an Fedora gemeldet. Da es sich um einen Security-Bug handelt, wurde darüber nichts bekannt. Im Laufe der nächsten Tage, kamen die Redhat- und Gnome-Entwickler zu dem Schluß, des es an dem „alten“ „langsamen“ Laptop liegen mußte und es modernen nicht reproduziert werden konnte.

Nun sind 2,5 Jahre rum und ich habe ein neues Laptop…. und den gleichen Bug wie vor 2,5 Jahren.

Diesmal gab es aber eine Fristsetzung für Gnome. Das Sie diesen Beitrag lesen können, bedeutet, daß die Schweigefrist von 90 Tagen um ist.

Wie können Sie diesen Bug ausnutzen um an Informationen zu gelangen ?

Eine Voraussetzung ist natürlich, daß das Opfer sensitive Daten angezeigt hat, bevor der Suspendmodus eingeleitet wurde. Ansonsten sehen Sie zwar den Desktop, aber außer einigen anrüchigen Pornohintergründen, wenden Sie vermutlich kaum etwas „entdecken“ können 🙂

Wie exploiten wird dies nun ?

Das ist schon so trivial, daß man sich schämen muß es zu erwähnen:

Handy nehmen
Videoaufnahme starten
auf den Bildschirm richten
Leertaste auf dem Opfer Laptop benutzen
etwas warten bis das Bild kommt.
Weggehen.

Spulen Sie die Videoaufnahme langsam ab und halten Sie einfach in dem Moment an, wenn der Bildschirm zusehen ist.

Kleiner Tip:

Das Laptop und der Monitor sollten in einer hellen Umgebung aufgenommen werden, also nicht nur den Bildschirm sondern auch etwas Dekor, weil dann der Videochip die Aufnahme nicht überstrahlt, wenn es von schwarz auf weiß umschlägt.

Gegenmaßnahmen:

Zuerst den Screensafer starten, dann den Suspendmodus benutzen.

Betroffen:

min. Fedora 18,19,20,21,22,23 mit Gnomedesktop
vermutlich: Ubuntu, Debian mit Gnome und alle Fedora vor 18 mit Gnome