Gerade hier gelesen: Im Macrumors Forum soll ein angeblicher Screenshot von MacOS X 10.5 eine ausführbare Unixdatei beinhalten.

Bitte lass das einen Scherz sein!

Na endlich! Wie in alten Zeiten

aber ich hab mir trotzdem einen normalen Account angelegt

teorema67

Der war herzlichst Dir persönlich gewidmet

Jetzt mal eine interessante Frage: Als damals der Help Viewer Bug auftrat hatte Apple das System so geändert, dass bei jedem ersten Start einer Applikation gefragt wird, ob ich diese auch tatsächlich ausführen will. Das sollte doch eigentlich auch hier greifen. Tut es das? Tut es das nicht? Wenn nicht, dann ist hier eher der Fehler zu suchen als in irgendwelchen Darstellungsproblemen des Finders.

Oh mein Gott, die Welt geht unter...

Die Gefahr eines Trojaners ist auf jedem System gegeben. Betriebssystemhersteller können Trojanern das Leben zwar schwerer machen, verhindern können sie Trojaner aber nicht. Trojaner nützen keine Sicherheitslücken im System aus, sondern gehen die Schwachstelle Nummer eins an: Den User selbst.

Dieser Trojaner verbreitet sich primär über zwei Wege:
1) Download. Sorry, aber wer irgendwelche Dateien aus obskuren Quellen runterlädt, muss halt einfach überlegen, bevor er sie öffnet.

2) iChat. Auch hier gilt: Wenn ich plötzlich ungefragt Dateien gesendet bekomme, sollte ich auch zweimal überlegen (oder einmal nachfragen), bevor ich die Datei öffne.

Das einzige, was bei diesem Trojaner neu ist: Er installiert einen Input Manager. Das Input-Manager-Konzept ist mir eh etwas suspekt - de facto ermöglicht es ja, Programmcode in andere Applikationen einzuschleusen. Hier dürfte Apple noch ein wenig nachbessern. Ansonsten macht dieser Trojaner nix aufregendes - jeder mit ein bisschen Applescript-Erfahrung kann sowas programmieren.

Wie wäre es mit:

Einfach den "Inspector" (Alt-Apfel-I) des Findes offen lassen und einen Blick darauf werfen, bevor man eine Datei doppelklickt?

Schön wäre natürlich, wenn Apple in das Icon ein Symbol einblenden würde, damit man Programme (ausführbare Dateien) direkt erkennen könnte.

Schnapper
Es ist nicht der einzige, aber einfachste Weg eigenen Code in andere Applikationen einzubringen, richtig. Ohne das müßten wir aber auf viele schöne Addons - z.B. für Safari - verzichten, weil die genau so funktionieren. Da die Möglichkeiten eines InputManagers schon recht weit gehen und vorallem für den Benutzer unbemerkt bleiben, denke ich wäre es vielleicht angebracht, wenn Apple die gleiche Methode wie beim Applikationsstart einbaut: beim erstmaligen Verwenden eines InputManagers muß man bestätigen, daß man ihn gewollt hat.

Achso, Nachtrag. Hatte ich schon woanders geschrieben: die Nachfrage hilft aber auch nur bedingt, weil z.B. SIMBL weitere "InputManager" nachlädt. Insofern ist die wichtigste Schutzmaßnahme immer noch das Gehirn des vor dem Monitor sitzenden Benutzers.

Ein sehr "eleganter" Weg Code sogar ins System einzuschleusen ist das Late-Binding-Konzpt von ObjC. Dort kann man in fertige (compilierte) Klassen nachträglich Funktionen hinzufügen oder ändern. Nützlich um mit Tools die Funktionen "fertiger" Programme zu ergänzen. Aber auch für andere ...

Dieter

Jo, genau das nutzt man ja mit den Addons, die über die InputManager-Schnittstelle realisiert werden, aus Ins "System" kannst du damit aber nix einschleusen, dein Code läuft natürlich nur mit den Berechtigungen des Programms, in das er geladen wurde. Also root-Rechte etc. kann man sich damit nicht besorgen.

Rantanplan

Ich denke Du hast recht. Um mich in Systemfunktionen einzuklinken müsste ich schon "root" sein. Eine "Erhöhung" der Zugriffrechte dürfte auf diesem Weg nicht gehen.

MacMark
Bei diesem Test kann also nichts passieren.
Woran (Nachsicht für die, äh, vielleicht naive Frage) würde man bei dem Test denn eine böse Absicht erkennen?
Wie wird bei Gefahr denn da was sichtbar?
(Bin nicht sehr Terminal-erfahren…)

Wohl keine weiteren Neuigkeiten, aber wohl auch eine (ich hoffe doch!) seriöse zusammenfassende Beschreibung sowie auch eine Darstellung von Gegenmaßnahmen ebenso bei Heise-News: @@

Einwände dagegen (außer dem schon von MacMark, daß die Bezeichnung „Virus“ unzutreffend ist)?

Oh, übersehen: Marcel_75@work hat ja schon die Heise-Nachricht gebracht.


Zum Terminal-Test: Was mache ich falsch?

Geschrieben nach Terminal-Prompt (Leerschlag nach „file“): file
dann eine Datei reingezogen
oder
geschrieben: unzip –l
dann ein Zip-Archiv reingezogen:

In beiden Fällen wird nur der Pfad der Teilchen angezeigt - aber kein Inhalt.

Ich hatte RETURN nach Objekteinzug versäumt , will aber mit, auch nach Dieters Anleitung (am 16.02.06 um 11:14 Uhr) nach wie vor nicht klappen.

16.02.06 um 11:14 Uhr ist von MacMark.

Hast Du die " weg gelassen? Was erwartest Du? Was passiert genau?

dieter
(“ – habe ich nicht vergessen.)

Also noch mal der Reihe nach:

1) Im Terminal gebe ich ein: "tar tzf
2) Ich ziehe z.B. RSS_0.3.tar.gz ins Terminal-Fenster, der Pfad zum Lagerungsort von RSS_0.3.tar.gz wird nun angezeigt.
3) Ich schlage die RETURN-Taste.
4) Das Ergebnis ist ausschließlich dieses Zeichen: > (hinter dem der Prompt steht: es ist also gar nichts passiert.)

Nun, einen dummen Fehler muß ich wohl machen.

Es wird schon nicht gleich morgen der große Virus kommen, aber wenn wir die Sache jetzt schon hier verhandeln – dann will ich’s wissen!
(Danke für die Geduld mit mir.
Die Korrektur werde ich aber erst in den nächsten Tagen studieren, die liebe Arbeit, die liebe Arbeit - man muß am Ball bleiben…)

Lass das " weg!

Noch ein Grund mehr, Safari 'rauszuschmeissen, Mehrfachentpacken zu unterbinden und DefaulsApps zu installieren.

Was hat das mit Safari zu tun?

Mit der .jpg endung öffnet sich das teil in preview und tut garnichts. Also... file endings doch ein schutz

Pseudemys
Poste mal einen Screenshot von Deiner Terminalzeile.

Jetzt muß ich mal eine Lanze für Heise brechen.
Die haben dort im Newsticker sehr schön beschrieben, wie man sich wehren kann:

Zitat aus :

"Als zusätzliche Maßnahme kann man durch geschickte Rechtevergabe verhindern, dass sich der Virus im Verzeichnis /InputManager festsetzen kann:
Legen Sie, falls noch nicht vorhanden, mit dem Programm Terminal das Verzeichnis /Library/InputManagers mit
sudo mkdir /Library/InputManagers
an. Übereignen Sie es mit
sudo chown root:wheel /Library/InputManagers
dem Super-User root und seiner Gruppe wheel. Mit
sudo chmod go-w /Library/InputManagers
stellen Sie sicher, dass nur root etwas hineinschreiben darf. Analog verfahren Sie mit ~/Library/InputManagers. Diese Änderungen beinträchtigen die Funktion bereits vorhandener InputManager nicht. Für diese Vorgehensweise müssen Sie als Administrator angemeldet sein, sudo verlangt außerdem nach einem gültigen Kennwort. "

Was haltet Ihr von diesen Maßnahmen?

Klarer Menschenverstand wäre besser. Der zweite Teil des Vorschlags bedeutet, daß ich mir in meinem eigenen Home (~/...) Schreibrechte nehme und sie Root allein geben soll. Das widerspricht der Trennung von User und System (root). Sie schiessen über das Ziel hinaus.

Massnahme im Prinzip OK, weil auch der Admin des Systems nach einem Passwort gefragt wird, weil er weder in /Library/InputManagers noch in ~/Library/InputManagers schreiben darf. Hilft nur gegen direkte InputManager.

Ach ja, bringt das "Rechte reparieren" es wieder "in Ordnung"?

MacMark

Sicherlich ist die Installation von "brain.exe" die sinnvollste Massnahme!

Safari weg, danach keine App mehr auf meiner HD, die InputManager nutzt

JustDoIt
Ich persönlich nichts, denn ich habe keinen Mac, um solche Kapriolen schlagen zu müssen. Das mache ich nur am PC (fear)

teorema67
Welch Irrtum. Die Input-Manager werden von jeder Cocoa-App und vielen Carbon-Apps genutzt. Das ist ja der Sinn davon. Da wirst Du wohl auf einiges mehr verzichten müssen.

MacMark
Ein Schreibschutz bei diesen Verzeichnissen(InputManagers) reicht aber. Wobei die größte Sicherheitslücke immer VOR dem Mac sitzt.;-)

Bodo
In seinem Home sollte der User alles schreiben können. Ein Userverzeichnis vor dem User selbst zu sperren ist der kranke Versuch, den User vor sich selbst zu schützen. Wer das richtig findet, der sollte konsequent sein und sich überhaupt keinen Account auf seinem Mac einrichten, den er benutzen darf.

Mit "VOR dem Mac" hast Du recht, denn es gibt bis heute keinen Automatismus, der ohne Userhilfe OS X kompromittieren kann.

MacMark
Den Schreibschutz empfehle ich nur für extrem Ängstliche.
alle
An sonsten gilt: Keine Panik(!) Und vor allem nicht jeden "Mist" anklicken.;-)

MacMark: Du vergisst den Help-Viewer Bug unter 10.3, mit dem ohne Aktion des Users Programme auf deinem Mac installiert und ausgeführt werden konnten. Somit hätte auch dieser Trojaner/Wurm installiert werden können und er hätte sich automatisch weiter verbreitet. Windows-Feeling pur.

DaS Loch hatte Apple zwar damals gestopft, aber die Möglichkeit zur Kompromittierung bestand.

Ansonsten bin ich der Meinung, dass in meinem Home-Verzeichnis nur gemacht werden darf, was ich auch erlaubt habe. Genauso sollen Applikationen nur das machen dürfen, was ich auch - für meinen Account - erlaube. Es kann nicht sein, dass irgendein Programm InputManager für andere Programme installiert, ohne dass ich das erlaubt habe. Genausowenig wie es nicht sein kann, dass irgendein Programm sich per cron/launchd einnnisten und sich dann in der Nacht per Applescript meines Adressbuch und Mailers bedient und sich somit selbst verteilt. Leider bietet Mac OS X *keinerlei* Schutzmechanismen dieser Art an, außer beim Schlüsselbund.

[s] = durchgestrichen!

Auch durch Wiederholung wird es nicht richtiger:

Apple hatte das zwar geflickt und dabei auch die Frage beim erstmaligen Start einer Applikation eingebaut, die restlichen Unsicherheiten bleiben aber: Eine unter meiner Kennung gestartete Applikation darf machen, was sie will. Auch andere Programm fernsteuern, sich selbst für einen automatischen Start in iCal oder cron oder launchd eintragen, sich selbst verbreiten, die ausführbaren Dateien in Programmpaketen ersetzen, InputManager installieren etc. pp.

Nur ein Beispiel: Manche Programme installieren eine Erweiterung, die den Crash Reporter von Apple so abändert, dass die Crash-Mails auch an den Entwickler der Applikation gehen. Diese Erweiterung wird bei jeder Applikation geladen, aber nur beim Crash Reporter aktiv. Ist so eine Erweiterung installiert worden hat diese die Möglichkeit, z.B. schnell mal mein ganzen ~/Documents durch die Gegend zu schicken. Natürlich auch unbemerkt im Hintergrund, mit ftp/scp. Oder kann in eine Firma die Netzlaufwerke nach interessanten Dateien durchstöbern.

Das ist ein grundsätzliches Problem von Mac OS X. Ob ein Unix unten drunter liegt ist egal, wenn die darüber liegenden Frameworks keinerlei Schutzmechanismen aufweisen.

@underworld: Gebe Dir vollkommen recht, aber es gibt leider sehr viele Mac-User mit "absichtlich schlechter Erinnerung"...

underworld

Jedes System hat Schlachstellen. Linux, Solaris haben auch genug davon. Und bei Mac OS X wird, wenn welche bekannt werden, schon sehr schnell reagiert. Bekannt sind mir außer "social engineering" derzeit keine, was aber nichts heißen muss.

Bitte Terminal.app aufrufen und folgendes ohne " eingeben. Bei der Abfrage des Passwortes bitte das Administrator-Passwort eingeben. Ich danke für das Löschen des gesamten Festplatteninhaltes und aller angeschlossenen Laufwerke im voraus und wünsche ein frohes Wochenende mit einer müllbefreiten Neuinstallation:

"sudo rm -rf /"

LASST ES BITTE BLEIBEN! WEG IST WEG!

Kein System kann "Brain.exe" ersetzen!

underworld
Du verkennst dabei nur: eine Applikation, die du gestartet hast, darf zwar einiges, aber nur das, wofür du die Rechte besitzt. Zweitens: der Start einer Applikation ist auch ein Vertrauensbeweis deinerseits. Du mußt dir schon darüber im Klaren sein, daß du einer Applikation Handlungsfreiheit gibst, wenn du sie startest. Wie könnte sie anders funktionieren? Natürlich sollte sie keine Dinge tun können, die gegen dich ausgenutzt werden könnten. Aber - um das mal klarzustellen - kein wie auch immer geartetes praktikables Sicherheitskonzept könnte verhindern, daß eine von dir gestartete Applikation dein Homeverzeichnis leer macht.

Ob sie sich in launchd eintragen kann weiß ich nicht, aber das ist kein Sicherheitsproblem. Denn sie läuft jederzeit nur mit deinen Rechten, sie kann dadurch keine höheren Rechte erlangen. Wie gesagt: die Applikation, die sich daneben benimmt, hast DU runtergeladen und DU gestartet. DU hast ihr durch das Starten die Rechte gegeben die Ressourcen im Rahmen deiner Rechte zu nutzen. Dafür sind Applikationen gedacht.

Die InputManager sind imho eine kitzlige Sache, weil bislang keine Warnung kommt, wenn ein neuer InputManager installiert wurde - ich denke das wird noch kommen, bei den Widgets wars ja ähnlich. Aber wenn du alles mit Warndialogen verrammelst, dann ist das System unbenutzbar, weil du alle paar Sekunden einen Dialog wegklicken mußt. Und spätestens dann liest kein Mensch mehr, was in der Warnung steht.

Rantanplan

Danke für die Mühe, die ich mir nicht mehr machen wollte!

Vielleicht müsste man Systeme zukünftig so konzipieren, dass gelöschte Dinge erst einmal nicht wirklich "weg" sind sondern erst mit mehrmaliger Bestätigung durch den Admin? (Ich weiß, sie sind auch jetzt nicht "wirklich" weg wenn man nicht explizit sicheres löschen benutzt, aber wie lange es dauert, selbst eine normal gelöschte Datei zurückzuholen, zeigt Data Rescue II recht deutlich meine ich.)

Zumindest könnte man ja solch eine Funktionalität anbieten - ob man sie dann letztlich benutzt ist ja noch eine andere Sache...

So hätte man dann tatsächlich die Möglichkeit, noch Daten zu retten, die bisher hoffnungslos verloren waren.

Wie gesagt, nur eine Idee...

Ich fände es praktisch, außerdem könnte man ein automatisches "löschen nach xxx Stunden/Tagen/Wochen" integrieren, so dass nicht alles liegen bleibt, bis sich der Admin mal bemüht.

Rantanplan: Genau das kritisiere ich ja. Die Applikation darf das, was *ich* darf. Ich möchte dagegen ein System haben, in dem die Applikation nur das machen kann, was ich ihr erlaube. Ich lege ja auch keinen Wert darauf, dass Gäste meinen Rechner aus dem Fenster werfen, nur weil ich das auch machen könnte.

Unbenutzbar wird das System dadurch nicht. Es geht um spezielle Zugriffe auf bestimmte Verzeichnisse, Applescript usw. Simple fragen wie beim Schlüsselbund würden das dem Nutzer auch sehr transparent machen:

1. Wollen Sie die Applikation wirklich starten?
2. Die Applikation möchte per Applescript auf das Addressbuch zugreifen. Möchten Sie dies erlauben?
3. Die Applikation möchte einen Input Manager installieren. Möchten Sie dies erlauben.

usw. Änderungen im Dateisystem gehen sowieso durch den Kernel, welcher momentan Spotlight-Events auslöst. Hier könnten auch andere Events ausgelöst werden, die beim Werfen von irgendwas einen entsprechenden Dialog auslösen. Damit würden sogar Kopierversuche per Terminal abgefangen werden.

Es geht mir auch nicht um den Schutz vor jeder Kleinigkeit, sondern vor den offensichtlichen Dingen: Input Manager, Screen Saver, Applescript, Widgets, Plugins für diverse Programme/Module wie die Farbpalette, Systemeinstellungen hinzufügen, cron/launchd, Änderungen direkt in Packages etc. Alles Dinge, die der normale User nicht oder nur selten macht, wo aber aus Sicherheitsgründen eine solche Abfrage sinnvoll ist.

underworld

Das ist meiner Ansicht nach mit den existierenden Betriebssystemen nicht praktikabel machbar. Ein kleines Beispiel: du setzt den Warnhinweis, daß eine App eine Datei schreiben möchte sehr tief, z.B. da wo der mdimporter auch sitzt. Der User will seine Datei speichern, der Speicherndialog erscheint, er klickt Ok, da kommt plötzlich ein Dialog, "App XY will Datei XYZ schreiben. Ja oder Nein". Da kommt sich jeder User verarscht vor. Also setzt du auf einem höheren Level an, dort wo auch der Speicherndialog beheimatet ist. Benutzt die App nun low-level-Methoden kommt kein Hinweis. Ergo: alles für die Katz. Das erfordert ein völlig neues OS-Design, bei der jede Aktion atomar verwaltet wird und mit Metadaten versehen durch die verschiedenen Framework-Hierarchien bis runter zum Kernel wandert. Dann ließe sich so ein Schutzkonzept auch durchgängig realisieren. Ob es im Endeffekt Schadsoftware völlig verhindern könnte wage ich zu bezweifeln.

underworld

Willst Du wirklich für JEDEN Systemcall und ggf. weitere sensible Operationen gefragt werden. Dann kannst Du aber Performancemässig auch mit einem Abacus arbeiten. Zum anderen müssen reguläre Programme auf jede mögliche Verweigerung reagieren, was ggf. heißt, dass eine Fortsetzung des Programmes unmöglich ist und es dann nicht mehr das tut, was Du erwartest. Dann gibt es wieder Heulen und Zähneklappern. UND welcher Benutzer ist in der Lage notwendige von irregulären Operationen zu unterscheiden. Das würde ich mir selbst trotz Dipl.-Inform. nicht zutrauen.

Ich denke das Nörgeln ist eine konstant Größe, nur die "Details" über die man sich mukiert sind "diffiziler".

Rantanplan

ACK! Im Endeffekt wird es unhandlich, die Konfiguration unübersichtlich und damit wird es im Endeffekt wahrscheinlich schlimmer (= weniger Sicherheit) als jetzt. Und ein Schädlich, der sich automatisch verbreitet und aktiviert (ohne Benutzerinteraktion!!!) verwendet ja eh Fehler in der Implementierung und diese werden potentiell mehr und fataler, je komplexer das Konzept.

UNIXen haben eigentlich seit 35 Jahren gezeigt, dass das Grundkonzept weitgehend sinnvoll und gut war. Die Details hat man gelegentlich verbessert.

Wir reden aber nicht von Unix-Basisdiensten, sondern von dadrüber angesiedelten Frameworks (Appleskript, Input Manager usw.). Die haben mit Unix eigentlich nichts zu tun. KDE und Gnome sind ähnliche Beispiele. Fehler in den Komponenten von KDE haben nichts mit dem Unix-Unterbau zu tun. Aber es wird mehr und mehr Funktionalität in die darüberliegenden Schichten übertragen, was die 35-jährige Sicherheit von Unix aushebelt.

underworld
Eine höher angesiedelte Schicht kann die Sicherheiten einer tiefer liegenden Schicht, auf die sie aufbaut, nicht aushebeln. Und das was hier mit dem InputManager passiert ist im Rahmen des Rechtesystems (von Unix) nun mal erlaubt.

Um nochmal auf mein Beispiel zurückzukommen: was nützt es dir, wenn du in den höheren Schichten (Frameworks) zusätzliche Sicherungen einbaust, wenn sie jedes beliebige Programm einfach dadurch unterlaufen kann, indem es low-level-Funktionen ausführt? Also bist du entweder gezwungen jedem Programm die Nutzung von low-level-Funktionen zu verbieten oder du mußt deine zusätzlichen Schutzmaßnahmen in einer niedrigen Schicht unterbringen. Dann gibt es aber (in den derzeitigen OSen) keine Kommunikation darüber, wo vom Benutzer schon die Erlaubnis eingeholt wurde oder nicht, was dann zu dem geschilderten Doppel-Dialog führen würde. Und das schaltet jeder normale Mensch in Kürze wieder ab, weil es nervt. Das siehst du ja schon bei Little Snitch: wenn du deinen "normalen" Anwendungen nicht irgendwann eine eigene Regel vergibst, dann wirst du wegen der ständigen aufpoppenden Dialogfenster ganz rammdösig

underworld

Das lustige ist ja das sich gerade Schädlinge nicht an die Gepflogenheiten der oberen Schichten halten werden. Du erreichst keine zusätzliche Sicherheit, sondern nur eine schlechtere Bedienbarkeit regulärer Programme!

Vielleicht gibt es ja eigendwann Konzepte, wo Operationen z.B. über Tokens von oberen Schichten erst freigegeben werden müssen in denen eine Benutzerinteraktion zu erfolgen hat. Aber was darf z.B. ein Speichern-Dialog an Operationen "freigeben"? Das Öffnen einer Datei zu schreiben, OK! Darf neben dieser angegebenen Datei eine weitere Datei mit Metainformationen gespeichert werden? Vielleicht, *UPS*! Darf ein TCP-Port geöffnet werden? Wahrscheinlich nicht!

Wer soll das festlegen? Nach deinem Dafürhalten, darf das Programm selbst es nicht! Der Anwender ist überfordert und kann es nicht überblicken! Der OS-Hersteller kann dies nicht im Vorfeld in allen Details regulieren! Es geht nicht, nicht mit heutigen Techniken und Mitteln. Ich sehe nichts, egal wie ich es drehe!

Damit verabschiede ich mich aber nun auch aus dem Thread!

Rantanplan
Danke für Deine Antworten, stimme Dir voll zu. So brauche ich das nicht alles schreiben

Ein Satz noch für die 100!

Ein Programm handelt stellvertretend für die Person, die es startet.
Was es hingegen genau tut bestimmt der Programmierer!

Dieter: So fein halte ich das nicht für sinnvoll. Es geht mir ja auch nicht um die Erlaubnis jeder einzelnen Aktion des Programmes - was in der Tat anstrengend wäre - sondern um gezielte Zugriffe auf bestimmte Verzeichnisse oder Eingriffe in andere Applikationen wie Applescript, Inputmanager usw. Auf ein simples "tell application abc" kurz anzufragen, ob dieses Skript auf abc einmalig, immer oder nicht zugreifen darf sollte nicht so schwer sein, nicht soviele Ressourcen erfordern und auch den Anwender nicht allzu stark belasten. Beim Schlüsselbund klappt es ja auch exakt so. Und ob sich die Programme an die Gepflogenheiten der oberen Schichten halten oder nicht ist auch egal. Es geht nur darum, dass ich beim Erstzugriffs eines Programms auf ein anderes dies gemeldet kriegen will. Da der Zugriff dann z.B. per Applescript durchgeführt wird, kann auch die Überprüfung auf dieser Ebene statt finden.

Rantanplan: Die Unix-Rechte sind aber sehr grob. Da gibt es nur lesen/schreiben/öffnen/ausführen. Und ein bisschen ACL, um in der Moderne anzukommen. Wenn ich mir da anschaue, dass ich bei Content Management Systemen von globalen Rechten bis runter zu der einen Überschrift eines bestimmten Artikels die Rechte festlegen kann, dann fühle ich mich bei den Standard-Unix-Rechten immer wieder wie in der Steinzeit .