Tag Archives: Exploit

Neue Schwachstelle im Fedora Systemdesign?

Posted on by

Travis Ormandy, genau der vom Google Security Team, hat bei Red Hat und Fedora im April 2019 einen Securityreport eingebracht, daß eine Änderung zum Setzen von Bootflags, jetzt die Tendenz hat, extrem leicht dem Bootprozess zu stören.

SUID für grub2-set-bootflag

„grub2-set-bootflag“ ist ein Befehl aus der Bootloaderedition, der zwei Argumente annimmt. Aufrgund der Argumente verorte ich das mal im FastBootBereich des Systemstarts, weil es augenscheinlich um so Sachen wie schnelleres Laden, wenn Booten schon einmal erfolgreich war, geht.

Das Problem

$ ls -l `which grub2-set-bootflag`
-rwsr-xr-x. 1 root root 20272 Oct 10 00:35 /usr/sbin/grub2-set-bootflag

Wie man unschwer sehen kann, ist das ein Programm, daß man als User ausführen kann und dann Dinge als Root tut. Um genau zu sein, es schreibt eine Bootoption in die grubenv abhängig vom Argument. Ohne erst einmal ein halbes Dutzend Bugreports zu lesen, die grubenv enthält so Sachen wie „welchen Kernel soll ich booten“ und ist extrem anfälliger Bockmist.

Ja,Ja, ich hörs schon wieder, ich soll nicht so auf anderer Leute Arbeit rumhacken 🙂 Also erkläre ich das mal, dann verstummt Ihr von alleine 😉 Das ist Bockmist weil, die grubenv muß EXAKT 1024 Zeichen lang sein, um vom Bootloader verarbeitet werden zu können. Ist sie kleiner oder größer, wird sie ignoriert … und auch nie wieder beim Update der Bootconfig gefixt.

Woher ich das weiß, na von dem halben Dutzend Bugreports über die letzten Jahre, die Andere und ich zu dem Thema bei Red Hat abgesetzt haben und Ihr könnt mir glauben, die ziehen sich extrem unnötig in die Länge.

Immer mal wieder passiert es nämlich, daß grubby die grubenv selbst sabotiert. Unwissentlich passiert das, wenn jemand von Hand an der grubenv rumeditiert um z.b. einen anderen Kernel einzustellen. Macht das nicht! Nehmt Grubby dafür! Grubby: wie man wieder einen Default Kernel setzen kann

Um die exakte Dateilänge von 1024 zu erreichen, wird in die grubenv eine Reihe von abgezählten „#“ Padzeichen eingefügt. Könnt ja mal reinsehen. Wenn jetzt also jemand dort Optionen einbringt und der Grubenv-Block wird zu groß, oder zu klein, dann fällt das System auf die Defaults zurück.

Was im Zweifel bedeutet: Es bootet nicht mehr!

Welchen Grund wird es wohl gehabt haben, daß jemand einen anderen Kernel eingetragen hat? Genau 😉

Boot Loader Specification

Mit Fedora 30 wurde im Bootbereich auch Einiges geändert, so stehen die Kernels nicht mehr in der grub.conf drin, sondern finden sich jetzt in /boot/loader/entries/ als einzelne Dateien wieder und die saved_entry Variable in der grubenv referenziert nur noch einen dortigen Dateinamen.

Jetzt kommt Travis ins Spiel

Travis hat also aufmerksam die Publikationen von Fedora verfolgt und stolperte über das Problem mit dem Setuid. Damit kann nämlich jeder Benutzer, und damit Programm, diesen Grub2 Befehl ausführen. Würde das mit der grubenv stabil laufen, wäre das noch kein Problem.

Jetzt hat Travis aber einen Weg ersonnen, wie man als User die grubenv unbrauchbar machen kann, indem man z.b. das Padding zerstört ( siehe Bockmist oben ).

$ sudo egrep -bo ‚^##‘ /boot/grub2/grubenv
322:##

Zum Ermitteln wieviele ## da als Padding drin sind. Es geht aber auch pauschal mal eine 10 Byte lange Datei , kommt aufs gleiche raus.

python
Python 2.7.16 (default, Apr 30 2019, 15:54:43)
[GCC 9.0.1 20190312 (Red Hat 9.0.1-0.10)] on linux2
Type \“help\“, \“copyright\“, \“credits\“ or \“license\“ for more information.
>>> import resource
>>> import os
>>> resource.setrlimit(resource.RLIMIT_FSIZE, (323,323))
>>> os.execlp(\“grub2-set-bootflag\“, \“grub2-set-bootflag\“, \“menu_show_once\“)
Error flushing /boot/grub2/grubenv: File too large

Das Pythonbeispiel begrenzt also die Filelänge für sich und alle Subprozesse und Ihr ahnt es schon, das wirkt sich auch auf den per SUID aufgerufenen Prozess von Grub aus.

Ergebnis: Grubenv zerstört, Booteinstellungen auf Defaults zurückgesetzt und ggf. System damit unbrauchbar gemacht.

Und weil man das auch absichtlich zerstörerisch einsetzen kann, hat Travis das an Security@Redhat geschickt. Fedora und Red Hat haben es bis heute ignoriert. Heute lief der Full-Disclosure Timer aus, mal sehen ob jetzt was passiert.

Für Grubunzulänglichkeiten können Red Hat und Fedora natürlich nichts, aber man muß ja nicht noch Öl ins Feuer kippen. Vor F30 wurde es mit mit pkexec ausgeführt, was sich besser auf bestimmte Prozesse oder Benutzer einschränken läßt. Warum das geändert wurde bleibt in einer dunklen Developer-Mailingliste verborgen 😉

 

 

Exim: CVE-2019-15846 Root-Exploit und die Abwehr

Posted on by

So, es ist wieder soweit, wir stopfen den Exim gegen CVE-2019-15846. Diese Lücke beinhaltet einen eher ungewöhnlichen Angriffsvektor, jedenfalls für mich. Aus der Richtung hätte ich nicht mit Problemen gerechnet.

CVE-2019-15846: Root-Exploit durch SNI

Was ist das Problem werdet Ihr fragen? Schon mal was von TLS gehört? Nein? Nagut 😉 Das ist der Nachfolger von SSLv3 und wurde 1998 ins Leben gerufen um primär ein Problem zu lösen: Für SSLv3 braucht jede Domain, die das benutzen wollte, eine eigene IP auf dem Server, weil es nicht möglich war, das Cert passend zur aufgerufenen Domain auszuwählen.

Dies wurde durch SNI in TLS 1.0 behoben, so daß Webserver jetzt alle verschlüsselt erreichbaren Domains auf einer einzigen IP hosten konnten. Dazu gibt der Client, dem Web/ oder Mailserver mit, für welche Domain er eine Verbindung aufbauen möchte, bevor die Verbindung wirklich aufgebaut wird.

Genau da liegt das Problem

Der per SNI übergebene Domainname landet beim Exim derzeit ungeprüft im Filesystem und wenn etwas ungeprüft im Filesystem landet, kann man damit einiges anstellen, in diesem Fall Root werden. Das ist eine stark vereinfachte Darstellung, weil ich will ja nicht, daß Ihr Euch daraus einen eigenen Exploit baut 😉

Die Gegenmaßnahme

Mal von den bereits verfügbaren Update-Patchen abgesehen, kann man den Angriff dadurch erschweren, daß man die zum Angriff nötigen Zeichen im SNI blockiert.

Das geht so :

acl_check_mail:

deny condition = ${if eq{\\}{${substr{-1}{1}{$tls_in_sni}}}}
       message = no invalid SNI for you

deny condition = ${if eq{\\}{${substr{-1}{1}{$tls_in_peerdn}}}}
       message = no invalid tls strings for you

Es wird aber empfohlen das Update einzuspielen, weil nicht ausgeschlossen werden kann, daß dies nicht ausreicht um die Lücke dauerhaft zu schließen.

Für den derzeit bekannten Angriffsvektor gibt es bereits einen Proof-of-Concept Exploit, daher solltet Ihr sehr schnell handeln und noch schneller Updaten!

Fedora patzt beim Update

Das ist dem schnell Updaten wird für Redhat und Fedora Benutzer ein Problem werden, denn es gibt noch keine Updates. Fedora/Redhat hat es komplett verpennt, obwohl ich dem Maintainer höchstselbst eine Headsup Notitz gemailt habe und auf einer von den Distros überwachten Liste, eine entsprechende Nachricht eingegangen ist. Da haben ich und Golem das ja auch her gehabt. Heise Sec meinte, es würde reichen, wenn man das CERT bei Twitter abboniert hat.. ne sorry, reicht nicht 😀

Dann fixt jetzt mal eure Server, mein Cluster ist damit schon durch.

1. Update: 14:48

Wie aus sicherer Quelle bekannt wurde, hat Redhat eine „Urlaubsvertretung“ mit dem Problem betraut, da der Maintainer nicht zur Verfügung steht derzeit, er ist im Urlaub. Ob das die Ursache ist, daß es noch keine Updates gibt, weiß man nicht sicher, aber im Bereich des möglich wärs ja 😉 Sorry Fedora, aber ein bisschen Spot muß sein, ich sehe nämlich immer noch keine Pakete im Buildsystem bauen …

2. Update: 17:11

Das Update von Exim hat jetzt bei Fedora den Status „dringend“/“urgent“ .

3. Update: 18:20

TestRPMs sind verfügbar:

https://kojipkgs.fedoraproject.org//packages/exim/4.92.2/1.fc29/x86_64/exim-4.92.2-1.fc29.x86_64.rpm https://kojipkgs.fedoraproject.org//packages/exim/4.92.2/1.fc29/x86_64/exim-mysql-4.92.2-1.fc29.x86_64.rpm https://kojipkgs.fedoraproject.org//packages/exim/4.92.2/1.fc29/x86_64/exim-clamav-4.92.2-1.fc29.x86_64.rpm

4. Update: 19:01

Die RPMs wurden ins Stable gepusht. Damit gehen die Updates jetzt für alle live.

Danke an alle Helfer, Urlauber, Urlaubsunterbrecher und Vertretungen, die es heute Nachmittag dann doch noch geschafft haben und besonders an Heiko Schlittermann, mit dem ich noch die Eckpunkte des Workarounds diskutieren konnte, bevor es offiziell wurde.

Nicht schon wieder ein Root-Exploit im Exim

Posted on by

Wie heute bekannt wurde, gibt es schon wieder einen Remote-Root-Exploit im Exim-Mailserver: CVE-2019-15846 . Das wäre jetzt schon die dritte krasse Sicherheitslücke im Exim in diesem Jahr. Ich mag ja Exim sehr gern, aber die Pille ist schon irgendwie bitter, IMHO.

Das Kurz-Interview zum Thema mit einem der Exim-Verantwortlichen findet Ihr unten.

„A local or remote attacker can execute programs with root privileges.“

Alle Versionen bis einschließlich 4.92.1 sind laut Vorabmeldung davon betroffen. Derzeit gibt es für die Lücke noch keinen funktionierenden Exploit, aber da es schon einen Proof-of-Concept gibt, kann das nicht lange dauern, bis es einen Exploit in der Wildnis geben wird.

Mehr Details mochte man uns noch nicht anvertrauen, aber Freitag um 12 Uhr gibt es mehr Infos. Ist wie bei einer Pressekonferenz, wenn die Polizei mehr zu den aktuellen Erkenntnissen eines Falls rausrückt 😉

Gefixt ist das Problem in Version 4.92.2. Ich werde Euch mitteilen, wenn die Pakete im Koji auftauchen, da ich die natürlich testen werde 😉

Hier ein Auszug aus der Originalmeldung:

Version:    up to and including 4.92.1
Issue:      A local or remote attacker can execute programs with root
            privileges.
Details:    Will be made public at CRD. Currently there is no known
            exploit, but a rudimentary POC exists.

Coordinated Release Date (CRD) for Exim 4.92.2:
            2019-09-06 10:00 UTC

Ein Kurzinterview mit einem der Exim Entwickler

Ich habe kurzentschlossen Heiko Schlittermann ein paar Fragen zum Thema gestellt, die er mir freundlicherweise spontan beantwortet hat. Heiko hatte heute morgen auch die Head-Ups-Mail an die Eximliste geschrieben, steckt also voll im Thema drin:

Kommen die diesjährigen Schwachstellen aus Projekten, die den Code von Exim extra auditiert haben, oder sind es eher voneinander unabhängige Reporter?

Sowohl als auch. CVE-2019-10149 (Juni) wurde uns von einer Security-Firma gemeldet. Ich vermute, daß die im Auftrag eines Kunden Auditing gemacht haben. Dieses CVE betraf streng genommen uns nicht, weil die aktuelle Version den Bug nicht mehr drin hatte (wurde unbeabsichtigt beseitigt).

CVE-2019-13917 (Juli) war „Selbstanzeige“. Es ist einem der Entwickler aufgefallen, nachdem er nach CVE-2019-10149 begonnen hat, den Code so umzubauen, daß er „tainted data“ besser erkennt.

CVE-2019-15846 (September) wurde uns von einem User als Bug reported, daraufhin haben wir die o.g. Security-Firma beauftragt, das Potential dieses Problems zu untersuchen. Haben sie. Daher wurde es ein CVE. Sie fanden noch zwei weitere verdächtige Sachen, die wir aber mit ihnen klären konnten und es sind jetzt einfach nur Bugs, die sich nicht ausnutzen lassen. (Sind im „master“ schon gefixt.)

2. Drei schwere Lücken in wenigen Monaten Abstand, erschüttert das nicht das generelle Vertrauen in so ein Produkt?

Das Gespräch hatte ich auch eben mit meinem Kollegen. Wie ist die kritische Schwachstellendichte? Zu wenige: könnte bedeuten, da kümmert sich niemand, zu viele: könnte bedeuten, die Software ist Schrott. Mein Vertrauen erschüttert es nicht. Aber ich bin nicht objektiv, denn ich bin ja involviert. Natürlich führen diese Schwachstellen auch bei den Entwicklern zum Denken – sie oben, in Reaktion auf -1049 wurde „tainted data“ eingeführt. Gut möglich, daß weitere Änderungen folgen.

3. Ist für das Jahr noch mehr zu erwarten? (Dann muß ich ein neues Rezept gegen Bluthochdruck besorgen 😉 )

Wenn wir das wüssten, würden wir es gleich mit erledigen. Kannst ja präventiv eins besorgen, vielleicht verwendest Du ja noch andere Produkte. Die Summe allen Elends ist konstant 🙂

4. Was waren in den letzten Jahren die bisherigen Security-Nightmare-Highlights bei Exim?

Die uns bekannten sind als CVE veröffentlicht: http://www.exim.org/static/doc/security/ Ich denke, diese Liste müsste vollständig sein. Wenn nicht, dann gib Bescheid, ich kümmere mich drum.

Danke für das Gespräch.