Sicherheit unter 10.3.9 mit Whatsize ausgehebelt

[tau]

@ agro & ChristianMac:

Hier mal ein ls -l von einem user, wie er sein sollte (Zugriffsrechte)
Macht das mal mit Euren usern, die von WhatSize gesehen werden.

Terminal: ls -l /Users/Dein User

white-rabbit:~ admin$ ls -l /Users/testuser
total 0
drwx------   3 testuser  testuser  102 14 Jan 03:05 Desktop
drwx------   4 testuser  testuser  136 14 Jan 03:53 Documents
drwx------  24 testuser  testuser  816 16 Jan 18:27 Library
drwx------   3 testuser  testuser  102 14 Jan 03:05 Movies
drwx------   3 testuser  testuser  102 14 Jan 03:05 Music
drwx------   3 testuser  testuser  102 14 Jan 03:05 Pictures
drwxr-xr-x   4 testuser  testuser  136 14 Jan 03:05 Public
drwxr-xr-x   5 testuser  testuser  170 14 Jan 03:05 Sites

Und dann legt Euch mal einen neuen user an und schaut, ob Ihr den auch „WhatSizen“ könnt, meinetwegen vom Admin aus.

Ich hab den Verdacht, daß Ihr mal Eure user geklont habt, bzw von einem Backup rübergezogen habt, dabei hats möglicherweise andere Rechte gehagelt.

 

[agro]

War wohl nichts...

Hallo Leute,

es tut mir leid. Ich habe mich da wohl geirrt . Das ist mir sehr peinlich und ich kann nur hoffen, dass ihr mich jetzt nicht schlagt: Nachdem ich die Lage nochmal genauer untersucht habe, hat sich herausgestellt, dass sich die Zugriffsmöglichkeit nur auf bestimmte Ordner und Dateien bezog, die auch auf Finderebene für andere Benutzer zugänglich sind. In WhatSize kann ich zwar alle Ordner aller Benutzer sehen, aber weiter nichts. Die Größe ist nur dort zu sehen, wo ich das auch sehen darf.
Also alles ok. Mac OS X ist doch sicher.

Gruß
agro

 

[ratti]

Sonst müßt WhatSize ja rootaccess haben, was definitiv nicht ohne Passwort geht.

Das ist so nicht richtig.

Wenn ein Toll bei der Installation(!) root-Access bekommt, kann es
- einen Daemonprozess installieren, der mit rootrechten läuft (So machen es viele Server-Programme)
- Sich selbst suid root installieren

Das wären dann bloß die sauberen Methoden.

Eine unsaubere wäre: Sich das rootpasswort merken und es jederzeit wiederverwenden. So macht es Carbon Copy Cloner - während der läuft, kann jeder User im Temrinal "ps aux | less -S" eingeben und - voila - da ist das Adminpasswort. Furchtbar. CCC macht das immer nur pro Durchlauf von "ditto", aber wer sowas macht, der hat es nicht weit zu "Passwörter in Configfiles schreiben".

Gruß,
Ratti

 

[tau]

Sonst müßt WhatSize ja rootaccess haben, was definitiv nicht ohne Passwort geht.

Hi Ratti!

Ich hatte das auch im Zusammenhang mit WhatSize geschrieben, das ja nicht mit Rootrechten installiert wird (mit PW und so) sondern einfach im Userkontext läuft. Notfalls aus dem .dmg heraus, das man runtergeladen hat.


ps aux | less -S

Das hab ich nicht kapiert. ich habs mal probiert, mit laufendem CCC und ohne. Ich sehe halt alle Prozesse. Wo sehe ich das Rootpasswort?
CCC kann man ja auch nur als Admin (sudo) benutzen, und man muß vor jedem Klonvorgang das PW eingeben
Ich steh grad aufm Schlauch.. was genau meinst Du jetzt damit.. kopfkratz



@agro: Keine Schläge, sowas dient doch immer der allgemeinen Lernquote für uns alle

 

[agro]

@agro: Keine Schläge, sowas dient doch immer der allgemeinen Lernquote für uns alle

Ich danke dir für die Absolution!

Gruß
agro

 

[ratti]

Ich hatte das auch im Zusammenhang mit WhatSize geschrieben, das ja nicht mit Rootrechten installiert wird (mit PW und so) sondern einfach im Userkontext läuft. Notfalls aus dem .dmg heraus, das man runtergeladen hat.

Das war auch mehr so allgemein. "Ohne Passwort kein root" ist so nicht richtig.

ps aux | less -S

Das hab ich nicht kapiert. ich habs mal probiert, mit laufendem CCC und ohne. Ich sehe halt alle Prozesse. Wo sehe ich das Rootpasswort?
CCC kann man ja auch nur als Admin (sudo) benutzen, und man muß vor jedem Klonvorgang das PW eingeben
Ich steh grad aufm Schlauch.. was genau meinst Du jetzt damit.. kopfkratz

Du musst CCC tatsächlich arbeiten lassen. Er ruft aus der GUI heraus mehrfach das Kommandozeilentool "ditto" auf, welches rootrechte benötigt. In obiger Prozessliste taucht dann ungefähr sowas auf:

echo "adminpasswort" | sudo ditto /quelle /ziel ...

So grob. Hab grad keinen Mac hier.

Wenn gleichzeitig ein anderer User eingeloggt ist (zum Beispiel per ssh, oder auch einfach ein Apache-Script oder cgi), dann hattest du jetzt mal 'ne Kiste, wenn der will. Das mag bei den Kisten auf unseren Schreibtischen relativ Latte sein, z.B. auf einem Webserver ist es ein Debakel.

Gruß,
Ratti

 

[tau]

echo "adminpasswort" | sudo ditto /quelle /ziel ...

Hm. Ich wills jetzt grad nicht testen, zu faul, ich glaub Dir.

Angenommen, man führt die Ditto-Befehle manuell aus. Sieht man dann auch ein echo "adminpasswort"?

Wo ist der Unterschied, CCC ist doch nur ein Shellscript im weitesten Sinne...
Und wo liegt dann der konzeptionelle Fehler, bei Bombich oder Apple? Oder BSD?

Sorry, mit meinem Wissen über diese Sachen bin ich dieser Stelle haarscharf am Limit.

 

[ratti]

Hm. Ich wills jetzt grad nicht testen, zu faul, ich glaub Dir.

Angenommen, man führt die Ditto-Befehle manuell aus. Sieht man dann auch ein echo "adminpasswort"?

Wo ist der Unterschied, CCC ist doch nur ein Shellscript im weitesten Sinne...
Und wo liegt dann der konzeptionelle Fehler, bei Bombich oder Apple? Oder BSD?

Wenn du CCC startest und die Einstellungen macht, siehst du ja eine Liste mit Ordnern, etwa so:

usr
Library
Users
System
Applications
...

Der "ditto"-Befehl kann immer nur einen Ordner kopieren. Deswegen wird in CCC obiges so umgesetzt:

ditto $quelle/usr $ziel/usr
ditto $quelle/Library $ziel/Library
ditto $quelle/Users $ziel/Users

Jedesmal, wenn ditto neu aufgerufen wird, rückt auch der Fortschrittsbalken einen Schritt weiter (und deswegen ist es auch kein "richtiger" Fortschrittsbalken, weil die CCC-GUI kar nicht mitkriegt, wo ditto gerade ist)

Wenn DU ditto aufrufst, wirst du das per "sudo ditto" machen, deswegen ist das Adminpasswort nicht in der Prozessliste zu sehen.

Der Fehler liegt, nach meiner persönlichen Meinung, bei mehreren Beteiligten.
Zunächst mal schieben alle mir bekannten Tools solche einem Verhalten einen Riegel vor, indem sie solche Parameter gar nicht auslesen oder anbieten.
Sowas funktioniert zum Beispiel nicht, weil explizit abgestellt:

ssh rattiasswort@example.com
oder
ssh example.com < loginbatch.txt

Heisst: Ich würde mir von Apple wünschen, dass sudo einfach stdin nicht auswertet.


Darüberhinaus sollte man es, auch wenn es geht, einfach nicht machen.
Das Problem ist natürlich kniffelig: Das Programm stellt Funktionen zur Verfügung, die per se gefährlich sind und von Malware missbraucht werden könnte, wenn man z.B. einen Daemon verwendet oder ein suidroot binary installiert. Und gleich die komplette GUI als root laufen zu lassen ist auch nicht die feine englische.

Das beste wäre wohl, wenn es ditto und Co als Library gäbe, die andere Programmierer einfach ihrem Programm zulinken können. Die ganze GUI könnte man mit root-rechten starten, einen zweiten Thread forken, der root bleibt, und der Rest des Programms droppt seine Privilegien freiwillig wieder. So ganz nebenbei könnte man dann sogar einen vernünftigen Prozessbalken einbauen und die Hänger abfangen, die ditto machmal erleidet (Tip: Platten vor dem klonen immer mit Diskwarrior putzen).

Es wird sicherlich noch mehr Methoden geben.
Aber ganz ehrlich gesagt: Wenn es unumgänglich ist, dass das Adminpasswort in der Prozessliste steht, dann würde ich einfach davon Abstand nehmen, dieses Programm zu schreiben. Dann geht das eben nicht. Oder wenigstens einen riesenfetten knallroten blinkenden Banner auf die Website setzen: Trenne den Rechner vom Netz, während du klonst.

Gruß,
Ratti

 

[tau]

Wenn es unumgänglich ist, dass das Adminpasswort in der Prozessliste steht, dann würde ich einfach davon Abstand nehmen, dieses Programm zu schreiben. Dann geht das eben nicht. Oder wenigstens einen riesenfetten knallroten blinkenden Banner auf die Website setzen: Trenne den Rechner vom Netz, während du klonst.

Das natürlich ist auch wieder einmal nur eine Lücke, wenn man einen useraccount für den Rechner innehat und wenigstens SSH aktiv ist.
Soviel für den Normalnutzer, der darf sich relativ sicher fühlen, hat er die Firewall an (und SSH gesperrt)

In Firmennetzen hat das natürlich andere Qualität.


In Mike Bombichs (sehr großem) Forum hat ihn einer mal drauf angesprochen:
http://forums.bombich.com/viewtopic.php?t=3988&highlight=aux

Bombich selbst gibt Apple die Schuld und empfiehlt, SSH auszuschalten während des Klonvorgangs. Mit Tiger scheint es gefixt zu sein:

Not trying to downplay the issue, BUT, you can mitigate your risk by turning off SSH while you do your cloning. That said, there are still ways of exploiting this, even if you aren't logged in.

Incidentally, this is Apple's bug and it will be addressed in Tiger. I submitted this bug a re... well, suffice it to say that it was a good long time ago. I'm glad to see its finally being addressed.

Setzt eigentlich Apple Software Restore nicht auch auf ditto auf?

 

[ratti]

Das natürlich ist auch wieder einmal nur eine Lücke, wenn man einen useraccount für den Rechner innehat und wenigstens SSH aktiv ist.
Soviel für den Normalnutzer, der darf sich relativ sicher fühlen, hat er die Firewall an (und SSH gesperrt)

Zunächst mal ist es eine Lücke.
Dass dann sofort und in allen Fällen die Kiste gerippt ist, habe ich ja auch nicht behauptet. Es ist aber ein Problem.

Den grössten Anteil daran hat zunächst mal die Tatsache, dass der Autor nicht darauf hinweist, obwohl ihm das ganze bekannt ist.

Ich habe in meiner Fontverwaltung ein ähnliches Problem:
Um Sicherheit herzustellen, müsste das Programm mehr Rechte haben, damit es den Eigentümer einer Datei ändern kann. Kann es aber so nicht. Kein Problem - dann macht es der User eben manuell, oder auf eigenes Risiko gar nicht.Er wird bei der Installation groß drauf hingewiesen.

Du kannst dir vorstellen, wie ich aus den Latschen gekippt bin, als ich zufälligerweise drüber gestolpert bin und in ps mein Adminkennwort im Klartext gesehen habe...

In Firmennetzen hat das natürlich andere Qualität.

Ja. Aber. Sooo sorglos ist es zuhause dann doch nicht.

Bombich selbst gibt Apple die Schuld und empfiehlt, SSH auszuschalten während des Klonvorgangs.

Bombich empfiehlt, das Riskio zu /verkleinern/, indem man das tut. Nach wie vor bleiben weitere Problemquellen: php oder cgi im Apache. Andere Prozesse, die ps tracen.
Es braucht ja nicht mal böswillig zu sein. Ein Programm crasht, und ein Wrapper schickt einen IO-Snapshot per Internet raus, so wie Mac OS oder Firefox das tun ("Fehlerreport einsenden?"). Lief zu dem Zeitpunkt CCC, geht dein Kennwort raus - und du klickst auch noch "Ja, ist OK", weil man sowas ja nicht ahnt und beim Bugfix helfen will.

Mit Tiger scheint es gefixt zu sein:

Das freut mich, denn die Software von Mike Bombich ist viel zu nett, um ihn für einen Stümper zu halten.
Andererseits bedeutet das ja wohl, dass auch ANDERE Programme diesen Bug triggern, und da wird mir nun wieder heiss und kalt. Wer weiss, was das alles betrifft.

Setzt eigentlich Apple Software Restore nicht auch auf ditto auf?

Keine Ahnung. Aus dem Bauch raus würde ich vermuten, dass Apple eher in beiden den gleichen Code zulinkt. Shellauffrufe aus der GUI heraus macht man nicht gern.

Gruß, Ratti