Push-Nachrichten von MacTechNews.de
Würden Sie gerne aktuelle Nachrichten aus der Apple-Welt direkt über Push-Nachrichten erhalten?

Kritischer Fehler, der zum Glück nur wenige betrifft: "sudo" erlaubt Ausführung mit höheren Privilegien

Das "sudo"-Kommando erlaubt es, ein Programm mit den Privilegien eines anderen Nutzers auszuführen. Früher stand "sudo" für "superuser do" – da "sudo" Programme nur mit Superuser-Privilegien ausführen konnte. Doch "sudo" wurde erweitert und konnte fortan auch Programme mit den Rechten anderer Nutzer-Accounts ausführen. Nun aber deckte Apple selbst eine mögliche Sicherheitslücke in sudo auf, welche sich aber glücklicherweise in der Standard-Konfiguration von macOS nicht ausnutzen lässt.


Beim Sudo-Kommando vor Version 1.8.26 lässt sich ein möglicher Puffer-Überlauf ausnutzen, indem man eine sehr lange Zeichenfolge bei der Passwort-Abfrage eingibt. Dies lässt sich über ein simples Terminal-Kommando realisieren:

perl -e 'print(("A" x 100 . "\x{00}") x 50)' | sudo -S id

Hier kommt es zu einem kontrollierten Puffer-Überlauf, welcher dazu missbraucht werden kann, Code mit Superuser-Rechten auszuführen – völlig ohne das Passwort eines Nutzers mit Administrationsrechten. Glücklicherweise erfordert dieser Angriff aber, dass eine bestimmte Konfiguration für "sudo" gesetzt ist: pwfeedback. Diese Option bewirkt, dass man bei der Passworteingabe via "sudo" im Terminal die Anzahl der Zeichen des Passwortes sieht – in der Standardkonfiguration wird kein interaktives Feedback bei der Eingabe des Passwortes gezeigt. In macOS ist diese Option standardmäßig deaktiviert.

Will man überprüfen, ob die Option aktiviert ist, muss man folgende Zeile im Terminal gefolgt vom Passwort eingeben:

sudo -l

Findet man daraufhin die Option "pwfeedback", ist diese aktiv und somit "sudo" angreifbar. Hier bestehen nun zwei mögliche Optionen. Die einfachste ist, auf macOS Catalina 10.15.3 zu upgraden oder die Sicherheitsupdates für 10.13.6 und 10.14.6 einzuspielen – hier wurde "sudo" auf Version 1.8.31 aktualisiert, in welcher der Mangel behoben ist. Die zweite Möglichkeit ist, die "sudoers"-Datei, zu finden unter /etc/sudoers, anzupassen und die entsprechende Option zu entfernen.

Der Fehler wurde ursprünglich von Joe Vennix, Mitarbeiter in Apples Sicherheitsteam gefunden und gemeldet. Vennix fand bereits im letzten Jahr einen Mangel in "sudo": Gibt man eine nicht valide Nutzer-ID-Nummer an (beispielsweise -1), kann man dies ebenfalls ausnutzen, um Programme mit höheren Privilegien auszuführen.

Kommentare

Dirk!04.02.20 09:44
MTN
Die einfachste ist, auf macOS Catalina 10.15.3 zu upgraden oder die Sicherheitsupdates für 10.13.6 und 10.14.6 einzuspielen – hier wurde "sudo" auf Version 1.8.31 aktualisiert, in welcher der Mangel behoben ist.

Ich habe 10.14.6 (mojave) mit den letzten Sicherheitsupdates und er zeigt:

> sudo --version
Sudo version 1.8.29

also nicht 1.8.31
+3
mistamilla
mistamilla04.02.20 10:11
Hier unter Catalina 10.15.3 ebenfalls
$ sudo --version
Sudo version 1.8.29
ITZA GOOTZIE
+2
dtownsonic
dtownsonic04.02.20 10:19
macOS Mojave 10.14.6
Sudo version 1.8.29
+2
Mendel Kucharzeck
Mendel Kucharzeck04.02.20 10:47
Auch mit 1.8.29 ist der Fehler "beseitigt" – er ist zwar nach wie vor vorhanden, aber kann durch eine andere Gegebenheit nicht mehr ausgenutzt werden. Merkwürdigerweise hab ich 1.8.31 unter 10.15.3....
+1
shivaZ
shivaZ04.02.20 10:55
Mendel Kucharzeck
Auch mit 1.8.29 ist der Fehler "beseitigt" ...

... die Option "pwfeedback" taucht hier (10.14.6) zumindest nicht auf.
ɔɐɯ ɔɐɯ ɔɐɯ - sometimes I sit and think, and sometimes I just sit
0
Appletiser
Appletiser04.02.20 11:43
Ist es nicht so, dass der "sudo" Befehl nur mit einem Admin-Account aufgerufen werden kann?
Ich kann mich zwar im Terminal als Admin anmelden (z.B. login admin) um so den sudo-Befehl nutzen zu können, aber wenn ich schon das Admin-PW kenne verstehe ich die Aufregung hier gerade nicht wo wirklich.
Oder habe ich da was falsch verstanden?

Danke.
vg.
0
Deichkind04.02.20 13:10
sudo kann auch von einem "Standard"-Benutzer (ohne Administratorrechte) ausgeführt werden. Ob der Benutzer in der Liste 'sudoers' steht, prüft sudo erst nach dem Verarbeiten des Passworts.
+1
Appletiser
Appletiser04.02.20 14:19
Danke soweit für die Antwort, aber ich will es mal etwas präzisieren.
Ich habe es gerade mal mit einem Standard-Benutzer-Account probiert und wie erwartet kann dieser üblicherweise kein sudo-Befehl auslösen. Er ist also nicht automatisch in der "sudoers" Liste.

Ich habe es hier unter 10.15.3 getestet, kenne dieses Verhalten aber genauso unter allen bisherigen Systemen. Stellt sich mir also die Frage, wie kommt denn ein Standard-Benutzer-Account "ungewollt" auf die "sudoers" Liste?

vg.
+1
Marcel_75@work
Marcel_75@work05.02.20 06:59
Mendel Kucharzeck

Das ist wirklich erstaunlich, habe das gestern mal kurz auf einer Flotte (verwalteter) Rechner geprüft:

Egal ob 10.13.6, 10.14.6 oder 10.15.3, überall sudo Version 1.8.29 … kein einziger mit 1.8.31

Wie bist Du da rangekommen?

Ergibt
which sudo
denn auch
/usr/bin/sudo
bei Dir?

PS: Selbst per Combo-Updater von 10.15.3 bleibt es bei 1.8.29 …
0
Appletiser
Appletiser05.02.20 07:03
Ich habe mich bisher nicht mit der "sudoers" Liste beschäftigt, auf Grund dieses Beitrages dazu aber mal etwas weitere Infos zum Thema gesucht.
Mit der Frage, warum sollte man über diese Datei einem "Standard-User" auf einer Maschine, der normalerweise nicht mal "Programme" installieren darf, explizit solche Superuser-Rechte über die "sudoers" Liste einräumen?
Ich rede hier von Macs die wirklich im produktiven Einsatz bei Benutzern sind oder auch als Server agieren und nicht von irgendwelchen Testumgebungen.

Aus meiner Sicht gibt es keine schlüssige Erklärung dieses zu tun. Ich würde es sogar als grob Fahrlässig empfinden, denn dann brauche ich mich auch nicht mehr über das Thema "Sicherheit" als solches unterhalten. Wie der Beitrag ja auch ausführt, greift dieses theoretische Sicherheitsproblem nicht innerhalb der Standardkonfiguration.

Ansonsten bestätigen die beiden folgenden Beiträge eigentlich auch das, was ich gesagt habe, man muss im Terminal als Admin Account angemeldet sein, sonst kann man normal keinen "sudo" Befehl nutzen/ausführen.


0
Marcel_75@work
Marcel_75@work05.02.20 07:15
Appletiser
… man muss im Terminal als Admin Account angemeldet sein, sonst kann man normal keinen "sudo" Befehl nutzen/ausführen.

Ergänzung:

1) Angenommen Du hast einen User1 (Admin) und einen User2 (Standard, also ohne Admin-Rechte und nicht Mitglied der sudoers-Liste). Dieser User2 wird für die tägliche Arbeit genutzt.

Dann kannst Du folgendes machen als User2 im Terminal:

su user1 -

Das öffnet Dir eine Shell mit den Rechten des Administrators (der ja auch Mitglied der sudoers-Liste ist).

Dadurch klappt dann auch:

sudo su -

Und schwups hat man eine Shell mit root-Rechten geöffnet.

Ich erwähne das nur, weil einige immer wieder glauben, man könne als Standard-User ohne administrative Rechte nicht vernünftig arbeiten, da man ja keine Admin-Rechte hat und deshalb auch nicht ohne weiteres an root-Rechte kommt …

Voraussetzung ist dabei natürlich, dass einem das Kennwort des Admin-Accounts bekannt ist.

Das ist also eher für die eigenen, selbst verwalteten Maschinen gedacht.

"Spannend" wird es jedoch, wenn folgendes passiert:

2) Es gab in der Vergangenheit schon schwerwiegende bugs, die dazu führten, dass selbst ein Standard-User, der nicht Mitglied der sudoers-Liste ist, sogar ohne Kenntnis des Admin-Kennworts eine root-Shell öffnen konnte. Wenn ich mich jetzt nicht täusche, war das beim Release von 10.13 so, was ganz schnell mit einem 10.13.1 Update gefixt werden musste …

Ich bin ja immer noch der Überzeugung *Verschwörungsmodus ON*, dass das 'aus Versehen Absicht war' … denn so ein schwerwiegender bug MUSS im Vorfeld erkannt werden, so etwas darf einfach nicht passieren.
+1
Appletiser
Appletiser05.02.20 09:38
Marcel_75@work

Danke für die expliziten Ausführungen. Dieses ist mir bekannt und so arbeite ich immer, sollte ich z.B. auch innerhalb eines Standard-Accounts mal etwas im Terminal machen müsste, dass nun unbedingt sudo-Rechte erforderlich macht.
Und richtig dafür muss man eben genau das Admin-PW wissen.

Das war eben explizit der Gedankengang zu meiner Frage, wie dann plötzlich ein sudo-Zugriff aus der Decke fallen soll, damit man die hier erwähnte Sicherheitslücke ausnutzen können kann?

Ich nenne sowas "theoretisch Sicherheitslücken". Bei der hier beschriebenen Problematik sehe ich mindestens einen im Vorfeld vorgenommen Eingriff auf der Admin-Ebenen, damit diese "theoretische Gefährdung" dann überhaupt greift.

Sollte der Admin aber eben schon so fies sein und sabotieren, dann sind alle Sicherheitsmaßnahmen im ersten Schritt sowieso nicht mehr wirkungsvoll und damit ein ganz anderes Thema


An die Geschichte mit dem Bug im Anmeldefenster kann ich mich auch erinnern, dass war in der Tat dann wirklich eine Sicherheitslücke, die auch direkt "praktischen" Nutzen/Schaden hätte haben können.
0

Kommentieren

Sie müssen sich einloggen, um die News kommentieren zu können.