• Apfeltalk ändert einen Teil seiner Allgemeinen Geschäftsbedingungen (AGB), das Löschen von Useraccounts betreffend.
    Näheres könnt Ihr hier nachlesen: AGB-Änderung
  • Viele hassen ihn, manche schwören auf ihn, wir aber möchten unbedingt sehen, welche Bilder Ihr vor Eurem geistigen Auge bzw. vor der Linse Eures iPhone oder iPad sehen könnt, wenn Ihr dieses Wort hört oder lest. Macht mit und beteiligt Euch an unserem Frühjahrsputz ---> Klick

Neue Sicherheitslücke in Mac OS X aufgetaucht

iPiet

Raisin Rouge
Registriert
07.04.08
Beiträge
1.179
Die Grenze zur Paranoia ist dann aber auch schon bald uberschritten. Für Diskussionen dieser Art und Hinweise zur (fast vollständigen) Absicherung gegen fremde Eingriffe bietet sich dann der "Spion aus der Kälte"-Thread an.

*Alufoliemützeaufsetzundduckundweg* :)

EDIT: Ich schränke meine Paranoia-Bemerkung mal ein. Die von macmark vorgeschlagene Sandbox-Lösung (s.u. ) halte ich für sehr sinnvoll, um sich vor unbefugten Zugriffen zu schützen - aber es muss ja nicht immer gleich der Schäuble oder das BKA sein.
 
Zuletzt bearbeitet:

SilentCry

deaktivierter Benutzer
Registriert
03.01.08
Beiträge
3.831
VM ISO Internet

Ich halte das für eine interessante Lösung. Versteh mich richtig, vielleicht mache ich das auch noch.

Mich stört dabei allerdings dass ich eine komplette VM hochfahren muss wofür es unter (sic) Windows eine einfache (also einfach zu bedienende) Sandbox-Lösung gibt: www.sandboxie.com
(An dieser Stelle möchte ich MacMark zitieren, der zwei interessante Artikel geschrieben hat die sich mit dem Sandboxmechanismus in OS X beschäftigen, obwohl das natürlich nicht so umfassend funktioniert wie die Win-Lösung (sry): http://www.macmark.de/osx_security.php#sandbox und http://www.macmark.de/osx_terminal.php#sandbox_exec )

Der Komfort ist auch wesentlich eingeschränkt, ich nutze OS X immerhin, weil ich es mag, aber mit einer Linux-ISO in einer VM handle ich mir eine andere Bedienung ein, auch muss ich diese VM pflegen, wenn ich für irgendwas einen anderen Codec oder Plugin brauche... wird alles komplexer.

Aber wahrscheinlich hast Du Recht, das ist vermutlich die einzig gangbare Variante, das "Einfallstor Browser" komplett dicht zu machen. Denn darauf zu hoffen, dass Apple in Snowleopard die Sandboxtechnik so implementiert, dass sie alltagstauglich wird, ist wohl sinnlos. Eher drehen sie noch einen Werbespot...

Welche ISO verwendest Du denn?

PS: Warum müssen eigentlich bei jedem Sicherheitsthread die Blinden reinstolpern und "Paranoia" rufen? Ach... vergesst es.
 

SilentCry

deaktivierter Benutzer
Registriert
03.01.08
Beiträge
3.831
Danke Dir. Verstehe ich das richt: Ein Writefile auf #"^/Users/macmark/Library/.*
ist wirklich nötig?
Edit: Was passiert eigentlich, wenn man in so einem Safari per Link einen weiteren Safari aufruft (oder weiter gesponnen: Ein weiteres Programm)? Wird das mit den gleichen Einstellungen gesandboxed? Oder läuft das aus dem Sandbox-Kontext hinaus?
 

MacMark

Jakob Lebel
Registriert
01.01.05
Beiträge
4.874
… Ein Writefile auf #"^/Users/macmark/Library/.*
ist wirklich nötig?
Man kann es noch verfeinern bis auf einzelne Files herunter. Laß die Zeile mal weg und schau mit Console.app, was dann alles versucht und verhindert wird in dem Verzeichnis.
Code:
(debug deny)
sorgt für das Mitloggen abgelehnter Aktionen.

Wenn man alle kontrollierbaren Aktionen sehen möchte, dann sollte man
Code:
(debug all)
nutzen.

… wenn man in so einem Safari per Link einen weiteren Safari aufruft (oder weiter gesponnen: Ein weiteres Programm)? Wird das mit den gleichen Einstellungen gesandboxed? Oder läuft das aus dem Sandbox-Kontext hinaus?

Es läuft immer nur eine Instanz von Safari pro User. Es sei denn Du rufst direkt das Mach-O-Binary (wie unten gezeigt) auf. Dann gilt aber:
Programme in einer Sandbox vererben diese an ihre Kind-Prozesse.
http://www.macmark.de/osx_security.php#sandbox ;)

Oder einfach ausprobieren: Starte Safari aus einer Root-Shell, die per Sandbox eingesperrt ist:

Code:
KeyWest:~ macmark$ sudo -s
Password:
bash-3.2# sandbox-exec -p "(version 1) (allow default) (deny file-write*) (debug deny)" /bin/bash
bash-3.2# whoami
root
bash-3.2# /Applications/Safari.app/Contents/MacOS/Safari 
2009-01-28 13:55:16.370 Safari[886:10b] Exception occurred trying to obtain lock to save bookmarks: NSException [Can't get write lock on (null): Bad address] [(null)]. Bookmarks will not be saved.
2009-01-28 13:55:16.372 Safari[886:10b] Exception occurred trying to obtain lock to save bookmarks: NSException [Can't get write lock on (null): Bad address] [(null)]. Bookmarks will not be saved.
2009-01-28 13:55:16.374 Safari[886:10b] Exception occurred trying to obtain lock to save bookmarks: NSException [Can't get write lock on (null): Bad address] [(null)]. Bookmarks will not be saved.
2009-01-28 13:55:16.600 Safari[886:10b] *** -[NSURL initFileURLWithPath:]: nil string parameter

Noch offensichtlicher wird es, wenn Du in der Sandbox
Code:
(deny network*)
verwendest. Safari erbt diese Sandbox und kann nirgends hinsurfen:

Safari can’t open the page.
Safari can’t open the page “http://livepage.apple.com/”. The error was: “Operation could not be completed. Operation not permitted” (NSPOSIXErrorDomain:1) …
 
Zuletzt bearbeitet:

Paganethos

deaktivierter Benutzer
Registriert
18.11.07
Beiträge
3.702
Der Komfort ist auch wesentlich eingeschränkt, ich nutze OS X immerhin, weil ich es mag, aber mit einer Linux-ISO in einer VM handle ich mir eine andere Bedienung ein, auch muss ich diese VM pflegen, wenn ich für irgendwas einen anderen Codec oder Plugin brauche... wird alles komplexer.

Je nach VM ist das besser oder schlechter gelöst. Ich hab mir gerade die Paralells Demo gezogen, da gibt es einen Modus wo du von der VM nichts siehst. Du ziehst einfach die Verknüpfung von Firefox ins Dock. Ein klick startet dann die VM + Browser, der wie ein ganz normales Programmfenster daher kommt. Die Favoriten habe ich bis jetzt in einen gesharten Order gespeichert (sonst sind die ja nicht verfügbar..). Ich bin mir aber nicht sicher ob man damit für ein Schadprogramm nicht wieder ein Tor zum Host OS geöffnet hat. Ich experimentiere noch. Wenn ich eine zufrieden stellende Lösung habe werde ich das hier posten. Mein Problem: zu wenig IT Kenntnisse und viel zu wenig Zeit.

Optimal wäre natürlich ein OS X in einer VM.. :D

An meiner bisherigen Lösung ist eben das einpflegen von Updates, Codecs, etc. schlecht gelöst. Ich muss nach jedem Update die ISO wieder neu machen.



@MacMark: Ist die Sandbox Lösung so sicher wie die Lösung mit einer VM?
 

pepi

Cellini
Registriert
03.09.05
Beiträge
8.740
Ich umschiffe diese Gefahren seit einigen Wochen elegant indem ich ausschliesslich in einer VM surfe, dessen OS bei jedem Neustart von einem ISO neu gelesen wird. Einmal eingerichtet ist das eigentlich ziemlich komfortabel, vor allem gewinnt man damit fast 100% Sicherheit (ich gehe jetzt einfach mal davon aus, dass die LIVE CD sauber war von welcher ich mein ISO her habe ;) ).
Ich wüßte jetzt noch gerne welche Art, bzw. welchen Grad an Sicherheit Du durch diese Methode zu erlangen glaubst. Wovor glaubst Du nun sicher zu sein und wie kommst Du zu dieser Annahme?
Gruß Pepi
 

MacMark

Jakob Lebel
Registriert
01.01.05
Beiträge
4.874
… @MacMark: Ist die Sandbox Lösung so sicher wie die Lösung mit einer VM?

Die Sandbox-Funktion ist in Leopard Basis-Bestandteil des Betriebssystems. Man kann exakt vorgeben, was die Sandbox erlaubt und was nicht. Das betroffene Programm wird direkt vom System eingesperrt und alle Aktionen "(debug deny/all)" je nach Einstellung protokolliert.

Eine Virtual Machine hat nicht "Sicherheit" als Ziel, sondern Nachbildung von Hardware in Software. Sicherheit ist bei einer Virtual Machine nur Nebeneffekt. Programme können darin machen was sie wollen. Im Extremfall auch herausfinden, ob sie in einer Virtual Machine laufen und die Virtual-Machine-Software angreifen.

Für mich sind virtuelle Maschinen, wenn man sie als Sicherheitsfunktion nutzt, Platz- und CPU-Verschwendung. Und da sie meist selbst normale Anwendungsprogramme sind, haben sie auch nicht viele Möglichkeiten, Sicherheit zu gewährleisten. Im Prinzip ist "Sicherheit" hier nur die Fähigkeit des Host-Betriebssystems, Prozesse voneinander zu trennen und die VM ist einer dieser Prozesse.

Ein Schädling in der VM kann jeden anderen Rechner im Netz (auch seinen Host) per Netz angreifen.
 

Paganethos

deaktivierter Benutzer
Registriert
18.11.07
Beiträge
3.702
Ein Schädling in der VM kann jeden anderen Rechner im Netz (auch seinen Host) per Netz angreifen.

Eben davon habe ich noch nie etwas gelesen oder gehört. Die Grenzen der VM wurden, soweit ich eben weis, noch von keinem Schädling überschritten nie überschritten.
 

MacMark

Jakob Lebel
Registriert
01.01.05
Beiträge
4.874
… Die Grenzen der VM wurden, soweit ich eben weis, noch von keinem Schädling überschritten nie überschritten.

Du gehst mit dem Browser in der VM doch ins Internet? Dafür bekommt die VM eine IP vom Host-System. Jedes Programm in der VM kann daher in Deinem lokalen Netz und im Internet arbeiten. Wird ein Programm in der VM infiziert, dann kann es per Netz in Deinem LAN und im Internet weiterinfizieren. Das Hostsystem ist auch nur eine IP-Adresse wie die anderen im Netz für die VM.

Wenn Du der VM kein Netz zur Verfügung stellst sieht es natürlich anders aus, aber Du läßt ja extra den Browser in einer VM laufen …
 

Paganethos

deaktivierter Benutzer
Registriert
18.11.07
Beiträge
3.702
Würde mich hald wirklich interessiere ob das in der Praxis schon mal vorgekommen ist. Wie gesagt, ich hab noch nie was davon gelesen, obwohl ich extra danach gesucht hatte.


Das es theoretisch gehen könnte war mir klar.


Auch deine Sandbox könnte theoretisch durch irgend einen kleinen Fehler durchlässig werden.
 

MacMark

Jakob Lebel
Registriert
01.01.05
Beiträge
4.874
Es wird nicht unterschieden, ob beispielsweise Windows in einer VM läuft oder ob es direkt auf Hardware läuft.

Wenn die VM Netz-Zugang hat, dann besteht kein Unterschied zwischen Windows in einer VM und Windows auf einem PeeCee im gleichen LAN. Es ist daher nichts besonderes, wenn ein Windows in einer VM ebenso als Zombie unterwegs ist wie ein normaler Windows-PeeCee.

Eine VM soll nichts einsperren. Eine VM soll etwas ermöglichen. Eine VM ist kein Sicherheits-Werkzeug.

Die Sandbox-Kernel-Erweiterung "seatbelt.kext" [deutsch: "Sicherheitsgurt"] von OS X ist ein gezieltes Sicherheits-Feature und sonst hat sie keine Aufgabe. Sie ist bei mir nur 328 KB groß auf der Platte.

Eine VM ist deutlich umfangreicher als 328 KB und mit dem Umfang wächst die Schwierigkeit, Fehlerfreiheit zu gewährleisten.

Ein Programm braucht aus einer VM nicht "ausbrechen", denn es hat ja sowieso Netz-Zugriff! Der Unterschied ob VM oder direkt auf Hardware ist daher vollkommen egal.
 
  • Like
Reaktionen: deckl

SilentCry

deaktivierter Benutzer
Registriert
03.01.08
Beiträge
3.831
@MacMark: Vielen Dank, wieder einmal.
Ich bin enttäuscht von Apple, dass sie diese offensichtlich implementierte Sicherheit dem Anwender praktisch vorenthalten.

Ich wüßte jetzt noch gerne welche Art, bzw. welchen Grad an Sicherheit Du durch diese Methode zu erlangen glaubst. Wovor glaubst Du nun sicher zu sein und wie kommst Du zu dieser Annahme?
Die Frage war zwar nicht an mich gerichtet, aber ich versuche es mal.
  • Eine VM mit einem ISO ist einmal eines: Sicher vor Veränderungen. Man muss sich nicht mehr sorgen, dass im Verlauf, im Cache, in temp-Dateien, ... Spuren bleiben.
  • Ein Schädling, der über eine applikatorische Schwachstelle (Browser, Flash, ...) in die VM gelangt kann den Host nur über das Netz angreifen (das sollte zu stoppen sein) oder über eine Schwachstelle in der VM (bisher meines Wissens noch nicht aufgetreten).
  • Eine Spyware, die sich einschleust, hat keinen Zugriff auf die Host-Daten.
  • Ein Schadprogramm generell wird die falsche Umgebung vorfinden. Sollte ein Angreifer vom BKA also das Ziel "analysieren", wird er sich auf das falsche Zielsystem (Linux oder Windows) vorbereiten, nicht auf OS X. (Sollte er nicht detektieren, dass er in einer VM ist. Es ist kein absoluter Schutz aber eben eine weitere Hürde.)
Würde mich hald wirklich interessiere ob das in der Praxis schon mal vorgekommen ist. Wie gesagt, ich hab noch nie was davon gelesen, obwohl ich extra danach gesucht hatte.
Nein, meines Wissens nicht. Ich müsste mich jetzt genauer erkundigen, wie das mit "bridged network" ist bei Paralles/VMWare, aber wenn das richtig gelöst ist erscheint der Host und die VM als separate IP. Damit muss man im Extremfall nur mit Anriffen rechnen wie sie auch über das LAN stattfinden könnten. Wenn die OS X Firewall dicht ist kann kein Schadprogramm angreifen, mehr als ein Sniffing geht da nicht und dagegen muss man sich im LAN sowieso anders schützen, wenn mehr als ein Client angebunden ist.
 

MacMark

Jakob Lebel
Registriert
01.01.05
Beiträge
4.874
… offensichtlich implementierte Sicherheit dem Anwender praktisch vorenthalten. …

Das typische Vorgehen ist, wie bei anderen Techniken bei OS X vorher auch, anscheinend so:

1. Solche Neuerungen werden erst auf unteren System-Ebenen inoffiziell und undokumentiert von Apple eingeführt. Einige Systemteile nutzen diese dann schon über inoffizielle Schnittstellen.

2. Bis zur nächsten System-Version sind die APIs ausgereift, so daß sie offiziell dokumentiert werden und Programme / Userebene darauf aufbauen können. (Vorher ist das nicht sinnvoll, weil die APIs noch verändert wurden.)

Es kann sein, daß Apple mit Schnee-Leopard ein paar vordefinierte typische Sandboxen dem User auf GUI-Ebene verschiedenen Programmen zuordnen läßt.

Es kann aber auch sein, daß Apple passende Sandboxen direkt in den Programmcode setzt. Der Quellcode eines Programmes kann nämlich freiwillig eine Sandbox aufrufen für sich mit
Code:
 sandbox_init(sandbox_type)
. Der andere Weg ist, daß das Programm von außen mit einer Sandbox aufgerufen wird, wie in meinem Beispiel mit
Code:
sandbox-exec
.

… Eine Spyware, die sich einschleust, hat keinen Zugriff auf die Host-Daten …
Was ist mit gemeinsam genutzten Verzeichnissen zwischen VM und Host? An deren Inhalt erkennt er das Host-System und kann auch infizierte Dateien auf dem Host ablegen.
 

pepi

Cellini
Registriert
03.09.05
Beiträge
8.740
Eben davon habe ich noch nie etwas gelesen oder gehört. Die Grenzen der VM wurden, soweit ich eben weis, noch von keinem Schädling überschritten nie überschritten.
Das ist leider nicht korrekt. Es gab' sogar in Virtual PC (was quasi auch eine VM ist, wenn auch ohne Hardwarevirtualisierungsunterstützung) eine Sicherheitslücke die auf das Wirtsystem übergegriffen hat. (Originellerweise unmittelbar nachdem Microsoft das Ding von Connectix gekauft hatte und das erste eigene Update rausgebracht hat.)

Software kann definitiv feststellen ob sie in einer VM rennt und sich entsprechend auch angepaßt verhalten. Viele Viren tun das bereits um Ihrer Analyse durch Antivirensoftwarehersteller zu entgehen. Sobald sie in einerm VM rennen, verhalten sie sich anders, verstecken sich, richten keinen Schaden an und so weiter. Können, müssen sie aber nicht. Sie können auch ganz andere Dinge tun und beispielsweise das Wirtsystem attackieren und versuchen dieses zu infizieren.
Gruß Pepi