Apple Remote Desktop mit massiver Schwachstelle

[MacMark]

Also eagl was ich aktiviere oder deaktiviere ich bekomme immer diese Fehlermeldung.

B.

Wenn Du den Remote Desktop aktivierst und dabei die Option "Open and quit applications" aktivierst, dann funktioniert der Exploit auch mit angeschaltetem Remote Desktop. Zumindest bei mir.

 

[Skeeve]

Bei mir kommt dann das hier:

Sieht mir nach einem Copy&Paste Error aus. Zeig mal das Script.

 

[MacMark]

Man bekommt interessante Log-Nachrichten (system.log). Ich habe mal den Loglevel von 3 auf 1 geändert und dann den Exploit probiert:

20.06.08 18:55:32 sudo[1464] macmark : TTY=ttys001 ; PWD=/Library/Preferences ; USER=root ; COMMAND=/usr/bin/defaults write /Library/Preferences/com.apple.ARDAgent AgentLogLevel 1
20.06.08 18:56:05 ARDAgent [1467] ********ARDAgent Launched********
20.06.08 18:56:05 com.apple.launchd[89] ([0x0-0x61061].com.apple.RemoteDesktopAgent[1467]) Check-in of Mach service failed. PID 1467 is not privileged: com.apple.RemoteDesktop.agent
20.06.08 18:56:05 ARDAgent [1467] ********ARDAgent Ready********

Offenbar ist die Absicht, die Aktion nicht zuzulassen. Sieht also nach einem Programmierfehler aus.

Die Aktionen, die die Logmeldungen verursachen, waren:

sudo defaults write /Library/Preferences/com.apple.ARDAgent AgentLogLevel 1
osascript -e 'tell app "ARDAgent" to do shell script "whoami"';

 

[chrisbiolog]

Wenn Du den Remote Desktop aktivierst und dabei die Option "Open and quit applications" aktivierst, dann funktioniert der Exploit auch mit angeschaltetem Remote Desktop. Zumindest bei mir.

Tschuldigung dass ich wieder so dumm frage aber wo finde ich das den?

Skript folgt:

 

[Bonobo]

Hier: Gleiche Eingabe wie Chrisbiolog und gleiches Ergebnis.

 

[ZENcom]

ARD 2 unter Tiger ist also per sé nicht betroffen? ARD 3 unter Leopard allerdings ist in vollem Umfang von der Sicherheitslücke betroffen? Verstehe ich das so richtig?

Ich habe vor einigen Tage mein Titanium das Leo-Update gegönnt. Läuft übrigens ganz gut. Nun bekomme ich die u.a. Fehlermeldung:

Das wird aber auch ein anderes Problem sein. Das Leo-Update installiert zwar die Komponenten, lässt aber die eigentliche Applikation aussen vor. Das bedeutet das RemoteDesktop immer noch Version 2.2 ist, aber die systemweiten Zugriffsroutinen bereits auf 3.0 laufen.

So würde auch unter ARD 2.2 diese Sicherheitslücke bestehen, da je die "root"-Ausführungen bereits unter ARD 3 laufen.

Wie ist das eigentlich bei deaktiviertem "root"-User? Da sollte es doch auch keine Möglichkeit des Hacks geben, weil es auf dem System kein Zugriff via "root" vorgesehen ist? Oder ist bei Leo der "root"-User Default aktiv? Schau ich gleich mal nach…

 

[Skeeve]

Skript folgt:

Kein Copy&Paste Error und mir unverständlich.

 

[Zeisel]

Vorab: Bis vor 10 Minuten war ARD für mich ein Fernsehsender - sonst nichts...

Unter OS X Leopard genügt die Aktivierung der 'Entfernten Verwaltung' im Menüpunkt Sharing.

Sollte die Sicherheitslücke also wie folgt geschlossen sein? Ich bin nicht sicher, ob ich das richtig verstanden habe... wenn ja, dann ist es ja relativ einfach, sich vorerst zu helfen. Sollte ich noch einen Benutzer hinzufügen, oder kann das Feld leer bleiben?

 

[3nd3ff3kt]

Leute ihr müsst die Meldung mal richtig lesen und dann überlegen was da steht.

Zitat: "Grundsätzlich funktioniert der Exploit auch aus der Ferne, etwa auf einem Server, auf dem ein Anwender ein eingeschränktes Konto mit SSH-Zugriff hat."

Niemand hat bei mir ein eingeschränktes Konto und kann per ssh aus der Ferne zugreifen!!!!! Und wenn jemand einen physischen Zugriff auf meine Kiste hat ist es eh rum. Also locker bleiben!

 

[Zeisel]

Leute ihr müsst die Meldung mal richtig lesen und dann überlegen was da steht.

OK, tue ich mal:

Damit sich ein potentieller Angreifer die Lücke zunutzen machen kann, muss er angemeldet sein - egal, ob er direkt vor dem Computer sitzt oder nur per Remote Desktop auf den Rechner zugreift.

Soweit hast Du ja recht, aber weiter:

Ein Trojaner, der vom unwissenden Nutzer ausgeführt wird, hat jedoch ebenso Zugriff auf die Schwachstelle.

Den muss ich zwar erstmal selbst ausführen, dennoch darf so etwas nicht sein und sollte schnellstmöglich behoben werden. Lies also auch Du mal richtig...

 

[3nd3ff3kt]

Stimmt soweit. Ich halte dennoch diese Meldung mal wieder für reine Panikmache. Sofort fangen (fast) "Alle" an irgendwas am System einzustellen, um diese "Lücke" zu stopfen, obwohl das Riskio verhältnissmässig gering ist. Das Schlimme ist, das viele garnicht wissen, was sie da machen. Ich habe manchmal den Eindruck, dass bei Heise ab und zu mal Computer-Bild Redakteure schreiben dürfen.

 

[MacMark]

… Wie ist das eigentlich bei deaktiviertem "root"-User? Da sollte es doch auch keine Möglichkeit des Hacks geben, weil es auf dem System kein Zugriff via "root" vorgesehen ist? Oder ist bei Leo der "root"-User Default aktiv? …

Man kann sich standardmäßig nicht als "root" anmelden. Nichtsdestotrotz existiert root und ist aktiv - Systemprozesse sind root, beispielsweise alles, was im "Activity Monitor.app" als root oder System genannt wird.
Wenn man jedoch angemeldet ist, kann man root werden, beispielsweise mit "sudo -s" als Admin.

… Zitat: "Grundsätzlich funktioniert der Exploit auch aus der Ferne, etwa auf einem Server, auf dem ein Anwender ein eingeschränktes Konto mit SSH-Zugriff hat." …

Per SSH funktioniert es nur, wenn genau der User, der per SSH angemeldet ist, auch eine GUI im Vordergrund laufen hat auf demselben Rechner. Dann bräuchte er jedoch auch kein SSH, weil er ja bereits angemeldet ist.

Es wurden in beispielsweise Safari schon Fehler gefunden, die es ermöglichen, beim Besuch einer Webseite, Shellcode auszuführen von eben dieser Seite. Zusammen geben diese Bugs dann der besuchten Webseite Rootzugriff. Sollte zur Zeit ein solcher Bug noch vorhanden sein, dann haben wir ein Problem.

… Ich halte dennoch diese Meldung mal wieder für reine Panikmache. Sofort fangen (fast) "Alle" an irgendwas am System einzustellen, um diese "Lücke" zu stopfen, obwohl das Riskio verhältnissmässig gering ist. …

Ein wesentlicher Sicherheitsaspekt ist, daß auf dem Rechner nicht jeder User machen kann, was er will. Der Bug gibt jedoch jedem, der eine GUI auf OS aktiv hat, die Möglichkeit, root zu sein. Das ist der größte lokale Bug, den man sich vorstellen kann.

Das klappt sogar für "Guest User", der sich ohne Paßwort amelden kann (allerdings nicht remote).

Es wäre gut, wenn Apple den Bug schnell behebt.

 

[tharwan]

zuckt apple jetzt eigentlich endlich mal? immerhin sind gut 24h um. und wahnsinnig schwer zu fixen ist das jetzt ja nicht grade.

 

[MacMark]

zuckt apple jetzt eigentlich endlich mal? immerhin sind gut 24h um. und wahnsinnig schwer zu fixen ist das jetzt ja nicht grade.

Die vorgeschlagenen Fixes schütten das Kind mit dem Bade aus. Apple hingegen wird vermutlich eine Änderung im ARDAgent machen.

 

[tharwan]

warum das?
ich meine wenn der ARDAgent unter dem User läuft dann muss er eben für bestimmte dinge nachfragen, ist doch in ordnung.
Nicht in Ordnung ist das Apple zu zeit gar nix macht, ich finde wenigstens ein hotfix, was einfach die rechte ändert und den agent neu startet hätten sie schon bringen können.

 

[MacMark]

Die Panik und das Stochern im Dunkeln überlassen sie Dir und die technisch sinnvolle Lösung machen sie selbst. Und da Apple keine Frittenbude ist, wo man eben mal ne neue Ladung Pommes ins alte Fett schmeißt, fasse Dich in Geduld und lade Dir halt mal 3 Tage keine Angelina_naked_omFg_1elf_really_horny.jpg runter.

 

[Skeeve]

Angelina_naked_omFg_1elf_really_horny.jpg runter.

Jo! Danke für den Tipp! Das war echt hammermäßig! Hasste auch Angela_M_naked.jpg schon geladen?

 

[tharwan]

Die Panik und das Stochern im Dunkeln überlassen sie Dir und die technisch sinnvolle Lösung machen sie selbst. Und da Apple keine Frittenbude ist, wo man eben mal ne neue Ladung Pommes ins alte Fett schmeißt, fasse Dich in Geduld und lade Dir halt mal 3 Tage keine Angelina_naked_omFg_1elf_really_horny.jpg runter.

alles klar?
ist ja ok wenn du agro bist, aber gibt doch bitte ne technisch sinnvolle begründung und nicht so ein gesülze. danke

 

[MacMark]

… bitte ne technisch sinnvolle begründung …

Gab ich bereits:

Die vorgeschlagenen Fixes schütten das Kind mit dem Bade aus. Apple hingegen wird vermutlich eine Änderung im ARDAgent machen.

Übersetzt heißt das: Die "fix es Dir selbst"-Vorschläge, die kursieren, brechen die Funktion kaputt. Oder noch anders: Du willst den Pickel auf der Nase loswerden und schlägst dafür den Kopf ab.
Die sauberste Lösung bisher ist, "Remote Management" einzuschalten, was den Exploit verhindert.

Wenn man die üblichen Vorsichtsmaßnahmen nutzt (nicht alles klicken etc), dann deckt man einen möglichen Trojaner, der diesen Bug nutzt, ebenfalls ab. Darüber hinaus sollte man einen interessierten Blick auf Unbekanntes werfen, was man sich gezogen hat:
http://www.macmark.de/osx_terminal.php#examine
Und es zur Not mal im Sandkasten toben lassen:
http://www.macmark.de/osx_terminal.php#sandbox_exec

 

[MacMark]

Im April 2008 gab es anscheinend ein Update, daß das SUID-Bit definierte für den ARDAgent:
lsbom -p fm?M /Library/Receipts/RemoteDesktopClient.pkg/Contents/Archive.bom | grep 104755
./System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent 104755 root/wheel -rwsr-xr-x

104755, heißt: Regular file "10", suid "4", rwx owner "7", r-x group "5", r-x-other "5"-

Befehls-Erläuterung:
http://www.macmark.de/osx_permissions.php#rechte-vorgaben-ansehen

Rechte-Erläuterung:
http://www.macmark.de/osx_permissions.php#rechte-bedeutungen