Anfängerfehler in Mac OS X entdeckt

[Ijon Tichy]

Nachdem die im "Month of Apple Bugs" entdeckten Lücken IMHO eher theoretischer Natur und oft wenig mit OS X selbst zu tun hatten, ist die nun entdeckte Lücke nicht nur gefährlich, sondern vor allem ziemlich peinlich, wie unter anderem heise online gestern berichtete.

In dem Bericht wird aber auch gleich ein Fix beschrieben!

Ich habe gesucht, aber diese News nirgends gefunden. Also sorry, falls das schon gepostet wurde.

Nachtrag: Hab gerade doch noch entdeckt, dass es hier schon gepostet wurde.

 

[Schomo]

Was ist denn daran peinlich? Jedes Os hat wohl seine Lücken. Ich finde die Aktion jedenfalls sehr gut, und begrüße die Veröffentlichungen! Apple hat sicher ein offenes Ohr, was diese Fehler betrifft.

Gruß Schomo

 

[KÜN-Mr90]

hmm, und was bedeutet das für Nichtinformatiker wie mich?

was für ein Sicherheitsrisiko ist das und wie kann es sich äussern?
ich habe von dem im Text beschriebenen Problem kein wort verstanden
ist es möglich, dass ins deutsche zu übersetzen?

gruß eines Unwissenden

 

[Ijon Tichy]

was für ein Sicherheitsrisiko ist das und wie kann es sich äussern?
ich habe von dem im Text beschriebenen Problem kein wort verstanden
ist es möglich, dass ins deutsche zu übersetzen?

Ich bin zwar (eine Art) Informatiker, aber kein Sicherheitsexperte, so dass ich auch nur ansatzweise einschätzen kann, was das bedeutet. Nach dem Studium des Artikels und einiger Beiträge im Heise-Forum ist auf jeden Fall eine Mitwirkung des Anwenders notwendig, und der muss Admin-Rechte haben oder sie gewähren. Manche finden das wohl sehr theoretisch, aber IMO muss man auch bedenken, dass unter Windows sich sehr viele Trojaner durch Mithilfe unwissender Anwender einnisten. Dies war vor allem früher der Fall, als Schadprogramme noch selten und Virenscanner noch viel seltener waren und Otto Normaluser von solchen Dingen allenfalls gerüchteweise gehört hatte. Und hinterher kann man immer sagen, dass es blöd ist, einfach eine zugesandte Datei auszuführen...

Ich will nicht unken, aber die Situation von damals ist ja bei den Mac-Usern von heute ähnlich. Irgendwann kommt bestimmt mal einer auf die Idee auszunutzen, dass Mac-User von solchen Dingen bislang noch nicht betroffen waren.

Und laut dieser nicht-repräsentativen Umfrage arbeitet immerhin jeder dritte AT-User auf seinem Mac regelmäßig mit Admin-Rechten.

 

[joey23]

ähm, ich verstehe das problem nicht, aber ich kann auch den fix nicht finden. kann mir mal wer auf die sprünge helfen..?

 

[Cyrics]

ähm, ich verstehe das problem nicht, aber ich kann auch den fix nicht finden. kann mir mal wer auf die sprünge helfen..?

Also... das Problem ist folgendes:

grundsätzlich dürfen nicht irgendwelche "normalen" Programme weitere Programme und diese wiederrum Programme aufrufen mit immer den gleichen Rechten und diese immer weitergebend.
Weiterhin werden die Programme nicht direkt durch eine absolute Pfadangabe verlinkt sondern durch eine relative.
Also nicht /usr/bin/blabla sondern ../blabla

somit kann sich jeder Angreifer zu Nutze machen, dass ein normaler Anwender sich bei der Systemsteuerung authentifiziert als Admin um meinetwegen die Netzwerkeinstellungen zu ändern. Aber anstelle auf das Symbol Netzwerk zu klicken, klickt er vielleicht auf die Datei, die im Hintergrund dann ausgeführt wird, und zwar mit den Rechten, die du in der Systemsteuerung gegeben hast.

Problem soweit verstanden?

Trivial finde ich diese Lücke nicht... bisher hat sie sich keiner zu Nutze gemacht aber könnte mir schon einige Sachen überlegen, die man anstellen könnte damit.

Um das zu verhindern muss man ins Terminal... hier öffnet man mit Admin-Rechten die Datei service, die im Verzeichnis /sbin liegt.

Also tippt man im Terminal: sudo nano /sbin/service

nun fügt man hinter #!/bin/sh
folgende Zeile ein:

export PATH="/bin:/sbin:/usr/sbin:/usr/bin"

Um beim Texteditor nano speichern zu können, muss man Strg+O drücken. Dann überschreibt man mit einem Druck auf die Entertaste, die alte Datei und verlässt das Programm per Strg+X.

Natürlich kann man auch jeden anderen Texteditor nehmen... jedoch brauch man immer Superuser-Rechte, da man sonst bloss Lesen und nicht Schreiben darf.

 

[Leonardo]

Problem soweit verstanden?

Hallo Cyris

Das Problem habe ich denke ich grob verstanden und mich auch erst einmal an deine Lösung gehalten, vielen Dank (auch wenn ich lieber vim als nano benutze ). Aber wenn du die Zeit hast, würde ich mich über eine Erklärung sehr freuen, warum ich mit der modifizierung der PATH Variable diesem Angriff ausweichen kann. Und warum die Datei unter /sbin liegt? Wann wird die denn ausgeführt?

Also wie gesagt, falls du oder ein anderer wissender sich die Zeit nehmen mag, würde ich den Fehler gerne besser verstehen.

Viele Grüße,
Leonardo

 

[Cyrics]

Das Problem habe ich denke ich grob verstanden und mich auch erst einmal an deine Lösung gehalten, vielen Dank (auch wenn ich lieber vim als nano benutze ). Aber wenn du die Zeit hast, würde ich mich über eine Erklärung sehr freuen, warum ich mit der modifizierung der PATH Variable diesem Angriff ausweichen kann. Und warum die Datei unter /sbin liegt? Wann wird die denn ausgeführt?

Also wie gesagt, falls du oder ein anderer wissender sich die Zeit nehmen mag, würde ich den Fehler gerne besser verstehen.

Hallo,

also das File Hierarchy System (kurz FHS) schreibt vor, dass im /sbin Verzeichnis alle relevanten Dateien liegen, die zum Starten, Herunterfahren und Administrieren des Systems benötigt werden.
Dazu gibt es natürlich auch noch weitere Verzeichnisse, zum Beispiel /bin. Das FHS wird eh nie so wirklich streng ausgelegt...

daher eben die sehr allgemeine Einschränkung der PATH-Variablen...

Also inwiefern hilft diese Einschränkung nun? Sie hilft in dem Sinne, dass der Dateiaufruf, auf eine Datei zeigen muss, die nun in einem der Verzeichnisse liegen muss. In diesen Verzeichnissen kann man auch nur schreiben, wenn man root-Rechte hat.
Also bräuchtest du nun für zwei verschiedene Vorgänge die Authentifizierung als root. Beim ersten mal kann es noch ein Versehen sein, aber beim zweiten mal ist es einfach nur Dummheit auf gut deutsch.

Man hat also eingeschränkt, dass ein Angreifer in einem ihm zugänglichen Verzeichnis eine Datei ablegen kann, die mit root-Rechten durch die Ausnutzung der laschen Sicherheitsbestimmungen bei der Systemsteuerung ausgestattet wird. Da der Angreifer dafür root-Rechte nun brauchen würde.

Es wird ja auch explizit geschrieben, dass für die Ausnutzung dieser Schwachstelle der Angreifer bereits im System sein muss. Da dies aber durch irgendwelche anderen Lücken vielleicht mal möglich sein kann, setzt man die Sicherheitseinstellung durch die Einschränkung mit der PATH-Variable höher indem man root-Rechte nötig macht.

Ist jetzt alles doppelt und dreifach irgendwie erklärt... tut mir leid. Das Prinzip ist scheinbar also relativ simpel.

 

[Leonardo]

I got it.

Dankeschön!

 

[MacMark]

Rastafari (von apfeltalk) schreibt dazu folgenden interessanten Beitrag:
http://www.heise.de/security/news/foren/go.shtml?read=1&msg_id=12033678&forum_id=111309

 

[Skeeve]

hmm, und was bedeutet das für Nichtinformatiker wie mich?

Ich versuche mal eine Erklärung.

Wenn Du ein UNIX Kommando aufrufst, dann darf das Kommando genau das machen, was Du auch darfst. Also z.B. eine Datei anlegen oder löschen.

Nun gibt es Programme, die müssen, wenn sie aufgerufen werden, Dinge erledigen, die Du nicht darfst. Dazu gibt es im Unix das SUID, das Set User ID flag. Wenn dieses gesetzt ist, dann darf das Programm nicht alles das, was Du darfst, sondern alles das, was der Besitzer des Programms darf. Das ist dann im Normallfall der Superuser root. Und der darf alles.

Das Problem ist nun, daß das Kommando "writeconfig" das Kommando "/sbin/service" aufruft und dabei sein rootrechte mitgibt, d.h. "service" darf nun alles.

"service" wiederum ruft, "launchctl" auf. Dummerweise ruft es NICHT "/bin/launchctl" sondern einfach nur "launchctl" auf. Damit wird "launchctl" über den Pfad gesucht, das heißt in all den Verzeichnissen, die in der Variablen PATH definiert sind. Das führt dann im Normallfall dazu, daß das richtige "/bin/launchctl" gestartet wird.

Was aber, wenn nun vor dem Aufruf von "writeconfig" die Variable PATH manipuliert wurde? Zum Beispiel könnte jemand an den Anfang der Variablen das directory "/Users/shared/boeseScripte" gestellt haben um in dem Verzeichnis ein eigenes launchctl zu plazieren. "/sbin/service" würde also wieder über den Pfad suchen und "/Users/shared/boeseScripte/launchctl" finden und fröhlich mit rootrechten ausführen.

Das ist jetzt vielleicht etwas zu simpel erklärt, aber ich hoffe, das Prinzip ist deutlich geworden.

 

[QuickMik]

Rastafari (von apfeltalk) schreibt dazu folgenden interessanten Beitrag:
http://www.heise.de/security/news/foren/go.shtml?read=1&msg_id=12033678&forum_id=111309

wum...unser rastafari hat wieder mal zugeschlagen
woher weißt du das er das ist?

passen würde es ja zu ihm :-D
perfekt.

bei den heise jolly´s springt mir sowieso der "taschenfeitl" auf.
und wenn ich den "vokuhila" (vorne kurz hinten lang) in der glotze sehe....
hupft mir die pockenimpfung auf.

 

[KÜN-Mr90]

Ich versuche mal eine Erklärung.

Wenn Du ein UNIX Kommando aufrufst, dann darf das Kommando genau das machen, was Du auch darfst. Also z.B. eine Datei anlegen oder löschen.

Nun gibt es Programme, die müssen, wenn sie aufgerufen werden, Dinge erledigen, die Du nicht darfst. Dazu gibt es im Unix das SUID, das Set User ID flag. Wenn dieses gesetzt ist, dann darf das Programm nicht alles das, was Du darfst, sondern alles das, was der Besitzer des Programms darf. Das ist dann im Normallfall der Superuser root. Und der darf alles.

Das Problem ist nun, daß das Kommando "writeconfig" das Kommando "/sbin/service" aufruft und dabei sein rootrechte mitgibt, d.h. "service" darf nun alles.

"service" wiederum ruft, "launchctl" auf. Dummerweise ruft es NICHT "/bin/launchctl" sondern einfach nur "launchctl" auf. Damit wird "launchctl" über den Pfad gesucht, das heißt in all den Verzeichnissen, die in der Variablen PATH definiert sind. Das führt dann im Normallfall dazu, daß das richtige "/bin/launchctl" gestartet wird.

Was aber, wenn nun vor dem Aufruf von "writeconfig" die Variable PATH manipuliert wurde? Zum Beispiel könnte jemand an den Anfang der Variablen das directory "/Users/shared/boeseScripte" gestellt haben um in dem Verzeichnis ein eigenes launchctl zu plazieren. "/sbin/service" würde also wieder über den Pfad suchen und "/Users/shared/boeseScripte/launchctl" finden und fröhlich mit rootrechten ausführen.

Das ist jetzt vielleicht etwas zu simpel erklärt, aber ich hoffe, das Prinzip ist deutlich geworden.

Vielen Dnak für den Erklärungsversuch, also verstehn tu ichs trotzdem nicht wirklich

ist aber auch nicht wirklich schlimm, für mich wäre allerdings interessant zu wissen, ob man auch ohne das Wissen um solche Aktionen "zitat: Wenn du ein Unix Kommando aufrufst") solche unwissend ausführt, (sprich: mach ich sowas auch? )

gruß Stefan

 

[Mac Patric]

Hallo Cyrics,
da ich nur Anwender bin und nur diesen Rechner besitze habe ich folgende Frage:

Dieser o.g. Befehl im Terminal eingeben und die Sicherheitslücke ist geschlossen?

Oder kann es mir passieren, dass ich irgendetwas in den Sand setze und meinen Mac damit platt mache?

MP

 

[QuickMik]

Dieser o.g. Befehl im Terminal eingeben und die Sicherheitslücke ist geschlossen?

Oder kann es mir passieren, dass ich irgendetwas in den Sand setze und meinen Mac damit platt mache?

jep!
vergiss es. es braucht niemand im terminal rumhacken.
es gibt kein loch und keinen exploid dazu. das ist alles theorie von leuten die das gras wachsen hören.

 

[Ijon Tichy]

jep!
vergiss es. es braucht niemand im terminal rumhacken.
es gibt kein loch und keinen exploid dazu. das ist alles theorie von leuten die das gras wachsen hören.

Hm. Ist es deiner Meinung nach etwa sinnvoll, ein Loch erst dann zu stopfen, wenn es schon einen Exploit dazu gibt? Immerhin wärst du in guter Gesellschaft. Dieser Meinung war Microsoft ja auch lange.

Andererseits hast du sicher recht, dass man den beschriebenen Fix nur dann durchführen sollte, wenn man ungefähr weiß, was man tut. Sonst ist nämlich der Fix selbst ein nicht unerhebliches Risiko...!

 

[MacMark]

Lies mal Punkt 4 hier:
http://www.heise.de/security/news/foren/go.shtml?read=1&msg_id=12033678&forum_id=111309

 

[Wishi]

export PATH="/bin:/sbin:/usr/sbin:/usr/bin"

Ist das wirklich so richtig und was bedeuten denn in dieser Pfadangabe diese Doppelpunkte... *verwirrt bin*

 

[MacMark]

... was bedeuten denn in dieser Pfadangabe diese Doppelpunkte ...

Doppelpunkte trennen verschiedene Pfade.

 

[QuickMik]

...Andererseits hast du sicher recht, dass man den beschriebenen Fix nur dann durchführen sollte, wenn man ungefähr weiß, was man tut. Sonst ist nämlich der Fix selbst ein nicht unerhebliches Risiko...!

genau das meinte ich.