Zum Mitschreiben: Schutz vor der (akuten) OS X Sicherheitslücke [Update_10]

Frisch aktualisiert am 08.06.04:
Inzwischen ist es recht einfach geworden:
1. Alle Updates in der Software Aktualisierung installieren (i.e. Security Update 2004-05-24, Update auf 10.3.4 und Security Update 2004-06-07)
2. Das automatische Öffnen von Downloads im jeweiligen Browser nach wie vor deaktivieren (damit ist in erster Linie 'Sichere Dateien nach dem Laden öffnen' in den Safari Einstellungen gemeint). Zwar nicht mehr zwingend erforderlich, aber es handelt sich dabei zumindest um eine potenzielle Schwachstelle, insofern bleibt es empfehlenswert.

(3. Die mit RCDefaultApp umgestellten Protokolle dürfen wieder auf ihr Wunschprogramm zurückgebogen werden.
4. Paranoid Android kann getrost verbannt werden: "If you'd like to uninstall it, you can do so by running the Paranoid Android installer again and pressing the "Uninstall" button. Alternately, you can disable it using the APE Manager preference pane, or you can toss "Application Enhancers/Paranoid Android.ape".)

Apple hat mit dem aktuellen Security Update alle verbleibenden bisher bekannten Lücken vorerst geschlossen.

Hervorragende Lektüre dazu nach wie vor von John Gruber über das Security Update: "If you previously used RCDefaultApp or More Internet to disable vulnerable URI protocols, you can re-enable them if you want. Note, however, that Security Update 2004-06-07 removes the ‘disk:’ and ‘disks:’ protocols from your Launch Services database. These protocols simply no longer exist. In addition, DiskImageMounter has been modified such that it will no longer mount volumes via these protocols, even if you were to re-enable them (the protocols)." und seine überarbeitete Anleitung inklusive kurzer FAQ
--

Im Anschluss alle älteren Beiträge:

Wer sich noch nicht um die Sicherheitslücke (hier und hier im fscklog) gekümmert hat, sollte es spätestens jetzt nachholen, oder sich zumindest bei vernichteten Daten nicht allzu sehr wundern, denn Apple's Patch steht nach wie vor aus. (Vorgestern ließ Apple verlauten, das Problem sehr ernst zu nehmen und es momentan zu untersuchen, obwohl der Entdecker der einen Sicherheitslücke Apple angeblich schon Ende Februar darüber informiert hatte). Nach einem Wired Artikel sind zudem die üblichen Verdächtigen daran, sich der Lücke zu bemächtigen: "Malicious script kiddies are reportedly rushing to exploit the first serious security hole discovered in Apple Computer's Mac OS X." Sicherlich ist bisher noch kein bösartiger Fall bekannt und das Risiko insgesamt wohl als gering einzustufen, aber die zwei Minuten Zeit kann man es sich ruhig kosten lassen.

Das Problem liegt in einigen URI Protokollen, nämlich dem help: Protokoll, dem disk: und disks: Protokoll sowie zusätzlich im telnet: und ssh: Protokoll. Entsprechend sollten diese deaktiviert werden, was sich mit der 49KB kleinen Freeware RCDefaultApp (die sowieso auf jeden Mac gehört) leicht und einfach erledigen lässt:

Nach der Installation, 'Default Apps' in den Systemeinstellung anwählen
unter URLs entsprechend

help
disk, disks
telnet
ssh
jeweils auf 'disable' schalten.
Fertig.
Schneller geht es wirklich kaum und bis zum offiziellen Security Update dürfte man damit gut bedient sein. Ich halte das übrigens für die bessere Variante als den obskuren Paranoid Android Installer (der natürlich zusätzlich den Application Enhancer benötigt) von Unsanity, der weder ein ReadMe enthält, noch klar sagt, vor was oder wem er eigentlich schützt: "Paranoid Android is designed to shield you from a different approach than described in the recent Wired article and other sources, so this is not about recent help:// vulnerability (although it will shield you from that one as well)." Gegenläufige Meinungen werden in den Kommentaren übrigens immer gerne gesehen.

Mehr zur Lücke:
bei John Gruber, der erklärt, warum man lieber RCDefaultApp statt MoreInternet nehmen sollte:
"MisFox and More Internet both only show URI protocols registered through the Internet Config system; RCDefaultApp also shows protocols registered directly through Launch Services.[…] The ‘disk:’ and ‘disks:’ protocols are registered directly in Launch Services, which means they aren’t displayed in MisFox or More Internet.

Bei codepoetry schaut man auf die Geschichte der Help-Funktion im MacOS der letzten Dekade zurück: "So, now we have a problem. The Mac help system has used AppleScripts to perform much of its assistant-like tasks since System 7.5 and retained that all the way to Panther. In theory, the system is closed and the help protocol only used within the Help Viewer program. However, since the help protocol is registered with the system URL handler, any program at all, even Mail, could call it. And there we have the issue at hand."

Und macnewsworld.com liefert ein Interview mit dem Entdecker der help:/disk: Schwachstelle lixlpixl: "I was building a site where PHP and AppleScript work together to achieve what I wanted. That's when I discovered that you could start applications on the Mac via [a] URL," lixlpixel said. "Of course that's no big deal, but then I realized that if you knew the location of the downloaded program on the user's machine, it gets more dangerous. That's why I notified Apple."[…] For his part, lixlpixel admitted being a bit overwhelmed by the reaction. "I am a big fan of Apple. [I] use their systems and have converted several friends to Mac. I don't want to be seen as trying to hurt Apple," he said."

Update:
Eric Bangeman schlägt bei Ars.technica Apple unter anderem vor, etwas weniger Geheimniskrämerei walten zu lassen: "Don't get me wrong: I don't think Apple needs to disclose every security vulnerability they or third-parties find. But when the news sites pick up on something, Apple needs to be forthcoming with a response that acknowledges the problem (if it really exists) and lays out Apple's plan to deal with it."

Bei macslash gibt es einen Hinweis, dass die Lücke mit 10.3.4 (7H58) geschlossen sein wird.

Update_2:
John Gruber hat inzwischen ebenfalls das telnet: Protokoll mit in die Lücken-Liste aufgenommen und erklärt nochmals ausführlich die darinsteckende Problematik. Das Deaktivieren von ssh hält er allerdings nicht für nötig: "For one thing, even though the ssh protocol can be loosely described as a secure alternative to telnet, the ssh shell command provides an entirely different set of command-line switches than the telnet tool; ssh has no analogous switch to telnet’s “-n”.

Update_3:
Das Security Update 2004-05-24 schließt erst einmal die HelpViewer Lücke.

Update_4 22.05.04:
Ich habe meine Meinung zu Paranoid Android erheblich revidiert, nachdem weitere Details bekannt wurden. Der oben genannte Workaround alleine reicht nicht aus, mehr dazu hier im fscklog.

Frisch aktualisiert am 27.05.04:
Da die Sicherheitslücke unter OS X etwas unüberschaubar geworden ist, hier eine Zusammenfassung der einfachen Schritte, die ich bei mir vorgenommen habe:

1. Apple's Security Update und Update auf 10.3.4 installieren
2. Das automatische Öffnen von Downloads im jeweiligen Browser deaktivieren (damit ist in erster Linie 'Sichere Dateien nach dem Laden öffnen' in den Safari Einstellungen gemeint).
3. Mit der Freeware RCDefaultApp unbedingt folgende URIs/URLs deaktivieren:
• afp
• disk
• disks
• ftp (zumindest darf nicht der Finder dafür benutzt werden)
• ssh (wird noch diskutiert, kann aber deaktiviert kaum schaden)
• help (seit Security Update 2004-05-24 bzw. 10.3.4 nicht mehr notwendig)
• telnet (seit 10.3.4 nicht mehr notwendig)

Wer sich danach noch vor Schwachstellen (aber nicht vor dem Application Enhancer) fürchtet, könnte Paranoid Android installieren und als Krönung wäre für die ganz Furchtsamen zusätzlich Little Snitch zu empfehlen.

Zusätzlicher Hinweis: Die in RCDefaultApp (inzwischen bei Version 1.1.1 mit deutscher Lokalisierung) getätigten Einstellungen müssen bei Mehrbenutzer-Systemen für jeden User einzeln vorgenommen werden.

Zu Test- und Infozwecken ist nach wie vor die Seite von Jens Jakob Jensen zu empfehlen:
http://ozwix.dk/OpnAppFixer/testit.html.
Oder alternativ: http://test.doit.wisc.edu/.

Update_5 23.05.04:
Paranoid Android liegt in Version 1.1 vor, die anscheinend selbst mögliche Sicherheitslücken aufweist, wenn Shapeshifter und RealOnePlayer nicht installiert sind.

Update_6 23.05.04:
John Gruber erklärt in seiner stets mehr als lesenswerten Weise, warum er eine Installation von Paranoid Android für überflüssig hält: "Therefore I cannot recommend the use of Paranoid Android. As far as I have determined (and admittedly, that’s an important disclaimer), every security problem “solved” by Paranoid Android can also be solved by changing or disabling Mac OS X’s default URI handlers using RCDefaultApp. RCDefaultApp uses supported API calls to modify your Launch Services settings, and should therefore conflict with nothing. Paranoid Android uses completely unsupported mechanisms to inject code into every running application, and therefore has the potential to conflict with anything."

Update_7 25.05.04:
ssh sollte nun auf jeden Fall deaktiviert werden, auch dafür gibt es inzwischen einen exploit.
John Gruber hat die oben genannten Schritte bei sich ebenfalls nochmals zusammengefasst, wer Hintergrundinfos will, sollte sich den Artikel unbedingt ansehen (dort fehlt allerdings der HInweis auf die ssh Problematik).

Update_8 27.05.04:
Überarbeitung der Anleitung nach 10.3.4 Update.

Update_9 27.05.04:
Die Diskussion über die wahren Ursachen sind in vollem Gange, während die Herangehensweise von Unsanity die Schwachstellen in der automatischen URI-Vergabe (sprich Launch-Services) impliziert, geht man bei codepoetry einen Schritt zurück: "This is not a bug or security problem with Launch Services. This is a bug with DiskImageMounter (the program that transparently mounts disk images for the Finder, and is the default handler of the disk: and disks: protocols). The same thing needs to happen for this program as happened for Help Viewer: if the calling program is not itself (or in this case, Finder) then either error out or ask for permission." Mehr dazu auch in diesem Artikel: "These are technically "untrusted user input" problems; programs are trusting user-created input far too much and, thus, creating a nice gaping security hole. Therefore we should call on Apple to fix the problems with DiskImageMounter, Finder, and Terminal (the telnet: breakage) rather than some Chicken Little "URI vulnerability" that doesn't exist."