Tag Archives: Exploit

Exploit in NetHack < 3.6.4

Posted on by

Weil es so ungewöhnlich ist, muß ich Euch kurz mitteilen, daß in Nethack, genau, dem Textadventure von Anno 1980 🙂 ein Loch ist. Naja, genau genommen, der aktuellen Version davon, wobei, „aktuell“ ist es jetzt auch nicht mehr 😉

NetHack: Privilege escalation/remote code execution/crash in configuration parsing

Die Meldung vom Dev Team von NetHack:

Severity: High
Affected versions: 3.6.0, 3.6.1, 3.6.2, 3.6.3
First Patched Version: 3.6.4

CVE-2019-19905

Basic Information:
A buffer overflow issue exists when reading very long lines from a NetHack configuration file (usually named .nethackrc).

This vulnerability affects systems that have NetHack installed suid/sgid and shared systems that allow users to upload their own configuration files.

All users are urged to upgrade to NetHack 3.6.4 as soon as possible.

Additional information related to this advisory, if any, will be made available at https://nethack.org/security.

Also jeder der NetHack einsetzt sollte darauf achten, keine fremden Konfigs zu benutzen, oder einfach mal auf 3.6.4 updaten. Fedora stellt die Updates bereits zur Verfügung.

Kleine Anmerkung: Ich hab es mal ausprobiert. Früher(tm), an der Uni hatten wir ja MUD im Einsatz, welches mir in der Erinnerung deutlich bedienerfreundlicher vor kommt, als das NetHack hier. Die unlogische Tastaturbelegung ist vermutlich historisch begründet, aber wenn man das 40 Jahre pflegt, könnte man doch auch mal mehr Platz auf der Map und eine intuitivere Steuerung einbauen, oder wäre das zu viel verlangt? Ja, es wäre nicht mehr das NetHack von 1980, aber was ist so schlimm dran? Der Ghostbusters 4 Film sieht auch besser aus, als Teil 1 von 1980 😉

„Security“ by Deutsche Bahn

Posted on by

Die Deutsche Bahn hat ja derzeit schon einen Gesprächstermin mit der Berliner Datenschutzbeauftragten, weil sie Greta’s Reisedaten preisgegeben haben, aber vor 16 Minuten brach auch die Sicherheitsfassade der DB IT zusammen. Auf Full-Disclosure wurde vom Vulnerability Laboratory eine DB Bahn Sicherheitslücke veröffentlicht.

„Security“ by Deutsche Bahn

Man kennt das als Bahnfahrer, man trifft an an einem Bahnhof ein und möchte woanders hin. Dazu braucht man einen Fahrschein, neudeutsch auch Ticket genannt. Um ein Ticket zu bekommen, stehen überall so kleine armlose Roboter rum, die Geld in Tickets wechseln. Dazu gibt man ein, wo man hin will und dann …. crasht gelegentlich die Anwendung intern, und da wird es spannend 🙂

Ein Prozess auf dem… und jetzt gut festhalten… Windows XP System, namens PasswordAgent.exe hat diverse Fehler, mal kann er was nicht abfragen, mal gibt es Laufzeitfehler, wie man das so noch von WinXP kennt ;). Jedesmal wenn das passiert, kommt eine Fehlermeldungsbox. Auf normalen PC wäre die im Vordergrund zusehen, hier allerdings versteckt sie sich hinter dem Anwendungsfenster des Verkaufsautomaten, damit der Kunde genau das nicht sehen kann.

Leider gibt es da noch einen Bug: Wenn man im Zahlenfeld auf Abbrechen klickt, während diese Meldung im Hintergrund angezeigt wird, kommt die nach vorne, vor die Verkaufsanwendung.

Jetzt haben wir ein Standardwindowsfehlerfenster und da ist ein Link drin zu den Details der Fehlermeldung. Darin wiederum ist ein Link zur M$-Hilfe. Drückt man drauf kommt, Ihr ahnt es, ein Browser ins Spiel, weil das ein Weblink ist. Ist der Browser erstmal gestartet, hat man über das Einstellungsmenü die Option ins Filesystem zu wechseln und der Rest dürfte auf der Hand liegen: Trojaner drauf, Ransomware oder einfach die DB Kunden verarschen, in dem der Automat keinen Fahrschein druckt oder oder oder…

Hier nochmal die Kurzfassung des Exploitweges:

PasswordAgent.exe := Unexpected Error (Background) – Runtime/Session/Timeout
=> Transaction Application => Cancel := Unexpected Error (Background) – Runtime/Session/Timeout (Front)
=> Click Error Report => Click Search Collection => Web Browser => Local File System => PWND!

Den Wert des Exploits schätzen die Finder auf 5.000€ – 10.000€ ein.

Angeblich kam die Bahn bereits selbst auf diese Lücke und hätte auch schon mit dem Patchen begonnen, insofern müßten potentielle Spaßvögel sehr schnell reagieren 😉

Quelle: https://www.vulnerability-lab.com/get_content.php?id=2191

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 😉