Schweres Sicherheitsproblem in Tiger und Leopard

[mbs]

Die Firma Intego hat einen sehr schweren Sicherheitsfehler in Mac OS X Leopard entdeckt, der es lokalen Benutzern ermöglicht, alle Rechte des Systems zu erlangen und somit jeden Schutz zu umgehen. http://www.intego.com/news/ism0802.asp

Einfache Demo:

Code: [Auswählen]

osascript -e 'tell app "ARDAgent" to do shell script "whoami"'
Zur Abhilfe:
In "Systemeinstellungen > Sharing" den Dienst "Entfernte Verwaltung" einschalten (das ist kein Tippfehler).

In Tiger gibt es das analoge Problem, jedoch nur, wenn der Apple Remote Desktop Client installliert wurde.

Das Problem kann von außen nur dann ausgenutzt werden, wenn Benutzer auf irgendeine Weise die Möglichkeit erlangen, Programme zu starten, beispielsweise über eine Remote Shell.

[MacFlieger]

Uiuiui, also doch richtig, dass man den Dienst einschalten muss, um das Problem nicht zu haben. Sehr merkwürdig.

Ich hatte das gerade eben auch ausprobiert. Und es funktioniert tatsächlich. Wobei allerdings die Ausgabe eines Directorylistings merkwürdig ist:

Eingabe:

Code: [Auswählen]

osascript -e 'tell app "ARDAgent" to do shell script "ls -l /"';Ausgabe:

Code: [Auswählen]

-rw-r--r--   1 root    admin         0 Mar 27 17:29 .com.apple.timemachine.suppo
lrwxr-xr-x@  1 root    admin        11 Mar 28 14:38 var -> private/var

Da hätte ich jetzt doch was anderes erwartet. Komisch.

Aber noch als Nachfrage:
Wenn ich die "Entfernte Nachfrage" aktiviert habe und bei "Optionen" und "Computereinstellungen" nichts angehakt habe, dann läuft zwar der Dienst, aber nichts kann benutzt werden, richtig?

[Jochen]

....der es lokalen Benutzern ermöglicht, alle Rechte des Systems zu erlangen und somit jeden Schutz zu umgehen.

Zur Abhilfe:
In "Systemeinstellungen > Sharing" den Dienst "Entfernte Verwaltung" einschalten (das ist kein Tippfehler).

Was ist jetzt das Problem ?
Das der lokale Benutzer, also ICH Zugriff habe, oder dass statt ausschalten einschalten eingestellt sein muss 

Jochen

[MacFlieger]

Das Problem ist:
Wenn der Dienst ausgeschaltet ist, dann kann jeder lokale Benutzer oder Programm, egal wie eingeschränkt seine Rechte sind, Befehle mit root-Rechten ohne weitere Passworteingabe ausführen. Also eine klassische Rechte-Eskalation.

Das einschalten des Dienstes ist nur ein Workaround, um den Fehler indirekt zu beheben.

[mbs]

Da hätte ich jetzt doch was anderes erwartet. Komisch.

Das liegt offenbar an eingeschränkten Terminal-Einstellungen in der gestarteten Sub-Shell und ist nur ein Darstellungsfehler. Hab im Moment keine Zeit, die genaue Ursache auszuknobeln. Wenn Du was wie "ls -l / > /tmp/ls.txt" probierst, kannst Du aber sehen, dass der Befehl vollständig und korrekt ausgeführt wird.

Wenn ich die "Entfernte Nachfrage" aktiviert habe und bei "Optionen" und "Computereinstellungen" nichts angehakt habe, dann läuft zwar der Dienst, aber nichts kann benutzt werden, richtig?

So scheint es zu sein. Kannst Du ja ausprobieren.

Was ist jetzt das Problem ?
Das der lokale Benutzer, also ICH Zugriff habe,

Das Problem ist, dass Du mehr Zugriff hast, also Du haben darfst und dass das für jeden anderen, der Programme ausführen kann, auch gilt.

[warlord]

Das einschalten des Dienstes ist nur ein Workaround, um den Fehler indirekt zu beheben.

Und damit wird dann womöglich das "remote" Ausnützen ähnlicher Lücken (die es womöglich noch gibt) ermöglicht. Ist mir irgendwie nicht sympathisch, dieser Workaround.  

[MacFlieger]

Und damit wird dann womöglich das "remote" Ausnützen ähnlicher Lücken (die es womöglich noch gibt) ermöglicht. Ist mir irgendwie nicht sympathisch, dieser Workaround.  

Mir auch nicht aus den gleichen Gründen. Ich starte ungerne Dienste, die ich nicht benötige.
Deshalb habe ich das ja auch nur als Workaround und nicht als Lösung bezeichnet. Lösung kann es nur von Apple geben. Hoffentlich schnell.

[MacFlieger]

Ähm, was ich ganz unterschlagen hatte:
In dem Link von radneuerfinder in dem anderen Thread ist noch eine weiterer möglicher Workaround gepostet:
Das Problem tritt ja auf, weil beim ARDAgent das SUID-Bit gesetzt ist und somit das Programm mit root-Rechten läuft. Man könnte also einfach dieses Bit entfernen:

Code: [Auswählen]

chmod u-s /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent
Wer ARD nicht nutzt, kann das vermutlich problemlos machen. Ich vermute aber, dass Nutzer von ARD das nicht tun sollten, allerdings haben die ja sowieso den Dienst eingeschaltet und sind nicht betroffen.
Eine spätere Rechtereparatur wird das Bit vermutlich wieder setzen.

[warlord]

Kann man es wohl wagen, mit

Code: [Auswählen]

chmod u-x /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent
den ARDAgent gleich ganz auszuschalten? Mir war dieses Apple Remote Gedöns noch nie geheuer.

[MacFlieger]

Kann man es wohl wagen, ... den ARDAgent gleich ganz auszuschalten?

Ich denke, das ist problemlos, wenn man den nicht benutzt/benötigt.
Zudem müsste diese Modifikation bei einem "Rechte reparieren" wieder rückgängig gemacht werden.

Das eigentliche Sicherheitsproblem ist ja meiner Meinung nach so entstanden:
- Wenn der ARDAgent per Sharing aktiviert ist, braucht der für einige Sachen halt root-Rechte, soll den Anwender aber nicht fragen, evtl. sitzt da ja keiner oder auch eben einer ohne Admin-Rechte. Daher bekam der ARDAgent das SUID-Bit gesetzt. Damit das aber keiner missbrauchen kann, wurde in dem ARDAgent eine Zugriffskontrolle eingebaut, die missbräuchliche Zugriffe verhindert. Aus diesem Grund funktioniert die Lücke auch nicht, wenn "Entfernte Verwaltung" aktiviert ist.
- Dass jemand auf den Gedanken kommen könnte, der ARDAgent lokal aufzurufen, wenn der gar nicht aktiviert ist,ist anscheinend keiner gekommen. Ruft man den also manuell auf, kann man ihm Befehle unterschieben, die mit root-Rechten ausgeführt werden.

Das ganze müsste sich eigentlich recht einfach beheben lassen (meine Vermutung). Einfach zusätzlich einbauen, dass der ARDAgent nichts macht, wenn er nicht per "Entfernte Verwaltung" gestartet wurde. Oder die gleichen Kontrollen benutzen, die bei eingeschaltetem Dienst, aber keinen "Häkchen" benutzt werden.
Am besten wäre es vermutlich völlig auf das SUID-Bit zu verzichten, in wie weit dass aber möglich ist ohne Funktionen lahmzulegen, weiß ich nicht.

[Florian]

In Tiger gibt es das analoge Problem, jedoch nur, wenn der Apple Remote Desktop Client installliert wurde.

Ich bin echt dankbar für diese Klarstellung, manche Meldungen lesen sich, als müsste man den ARDC erst installieren, um die Lücke zu schließen, was natürlich irgendwo komisch wäre, aber wenn's da steht… z.B. im Original von Intego:
„There are cases where this exploit does not work. If a user has turned on Remote Management in the Sharing pane of System Preferences under Mac OS X 10.5, or if a user has installed Apple Remote Desktop client under Mac OS X 10.4 or earlier and has activated this setting in the Sharing preferences, the exploit will not function.“

[Patrick]

Hängt wohl mit eben diesem Bug zusammen:

http://www.betanews.com/article/Mac_OS_X_Trojan_reported_in_the_wild/1213976101

[MacFlieger]

Ja, wobei der hier besprochene Bug "nur" eine Rechteausweitung ermöglicht.
D.h. durch diesen Bug kann ein Trojaner nicht nur den User ausspionieren/betreffen, der ihn selber absichtlich gestartet hat, sondern alle User auf dem gleichen Computer. Solange nur der gleiche User betroffen ist, wird keine Sicherheitslücke benötigt.

[warlord]

Hier meint einer, das Einschalten der entfernten Verwaltung nütze doch nichts. Jedenfalls nicht nachhaltig. Und er hat eine andere Lösung. Allerdings ist die auch irgendwie seltsam und mir ist nicht so ganz klar, was da geschieht und wieso sie (vielleicht) funktioniert.

[MacFlieger]

Hast Du das mal ausprobiert?

Im Endeffekt sehe ich das so:
- Wer ARD nicht braucht und daher ausgeschaltet hat, sollte einfach das SUID-Bit entfernen. Das ARD danach nicht mehr 100%ig funktioniert, ist ja egal, weil man es eh nicht braucht/nutzt.
- Wer ARD braucht, hat es eingeschaltet und soll eigentlich ja von dem Problem nicht betroffen sein. Laut Deinem verlinkten Artikel sind aber gerade die betroffen, weil ein Neustarten des Dienstes die Lücke öffnen soll. Klingt für mich komisch, aber wäre schön, wenn das mal jemand ausprobieren kann.