Gestern gab es ja den Trojaner, der einen Input-Manager benutzt, um iChat zu patchen im Speicher, damit es eine Datei (sich selbst) anderen Leuten aus der Kontaktliste zum Download anbietet.

Prinzipiell kann jeder Input-Manager jedes Programm patchen. Offiziell, um dem User neue Arten der Texteingabe zu ermöglichen. Programme wie PithHelmet und einige Tools von Unsanity nutzen Input-Manager jedoch, um Safari oder den Crashreporter oder andere Programme im Speicher zu patchen (verändern).

Hier ist ein guter Artikel dazu:
daringfireball.net/2006/01/smart_crash_reports
Und einige Gedanken zu den Berechtigungen bzgl. Input-Managern:
daringfireball.net/2006/02/scr_addenda

Das Ausnutzen von Input-Managern zu nicht-offiziellen Zwecken ähnelt den Programmen, die Mach-Injection / Mach-Override verwenden, wie hier beschrieben:

osx.realmacmark.de/osx_dynamic-overriding.php

Möglicherweise sollte Apple die Möglichkeiten, die Entwickler mit den Input-Managern haben, einschränken, oder die Installation solcher Manager mit entsprechenden Warnhinweisen gegenüber dem installierenden Admin versehen.

Der Trojaner nutzt einen Mechanismus, den viele reguläre Programme auch verwenden. In keinem der Fälle entspricht diese abnormale Verwendung der Input-Manager dem von Apple gedachten Zweck von Input-Managern.

Einschränken ist der falsche Weg. Apple muss bei solchen Dingen einfach mal einmalig fragen, ob man es ausführen will. Gilt z.B. auch für Applescript-Zugriffe. Wie das geht zeigt ja das Schlüsselbund sehr gut.

Insgesamt gesehen ist Mac OS X nämlich offen wie ein Scheunentor, wenn man es einmal auf das System geschafft hat. Der User hat keine Kontrolle über das, was die Applikationen machen dürfen. Und da ist es dann eben ein leichtes, sich z.B. per Applescript durch die Gegend zu verschicken. Oder man klickt sich einfach einen Automator-Workflow zusammen und verteilt diesen. Fertig ist der Wurm.

Sicherlich kann man die Verzeichnisse schützen, so dass nur mit Angabe von Passwörten eine Installation statt finden kann, aber das wären nicht nur die InputManager-Verzeichnisse. Und was ist mit den Meta-Inputmanagern (SIMBL)?

Mehr Potential bieten das LastBinding der ObjC Klassen des System. Die ObjC Laufzeitumgebung erlaubt es nachträglich Funktionen in fertigen (compilierten) Klassen hinzuzufügen oder zu verändern. Das ist ein Feature kein Bug, kann aber "ausgenutzt" werden. Von kleinen schönen Tools, die Apples Programme erweitern, als auch von ...

underworld
Kennzeichnen von "Ausführbaren Dateien" (Programmen) in den Icons wäre zudem sehr nützlich. Dann kann man uns nicht mehr so einfach mit einem überlagerten Icon täuschen! Idee: Ein Zahnrad unten links im Icon (analog zum Alias-Pfeil)