Apple und die Sicherheit

[MacFlieger]

OK, danke. Das bringt ein wenig Licht in den Dschungel.

[Florian]

Lion sei sicherer als Snow Leopard, längerer Artikel dazu auf Mac&I:
http://www.heise.de/mac-and-i/artikel/Security-Check-Lion-holt-auf-1372134.html

(noch nicht gelesen, übernehme keine Garantie für Sinnhaftigkeit.

[radneuerfinder]

Lesenswertes Interview mit Charlie Miller:
http://www.engadget.com/2011/11/18/the-engadget-interview-dr-charlie-miller/

[radneuerfinder]

Späh-Software aus Deutschland nutzt iTunes-Lücke (gestopft mit iTunes 10.5.1) aus:
http://www.spiegel.de/netzwelt/netzpolitik/0,1518,798891,00.html

[warlord]

Späh-Software aus Deutschland nutzt iTunes-Lücke (gestopft mit iTunes 10.5.1) aus:
http://www.spiegel.de/netzwelt/netzpolitik/0,1518,798891,00.html

Passend dazu auch: http://projects.wsj.com/surveillance-catalog/#/

[radneuerfinder]

Wie schnell ist Apple bei den Updates der SchadsoftwareDefinitionen?
http://www.golem.de/1111/88108.html
http://www.heise.de/mac-and-i/meldung/Apple-hinkt-bei-XProtect-Updates-hinterher-1387562.html

und:
http://www.heise.de/security/meldung/iTunes-Sicherheitsluecke-war-mehr-als-drei-Jahren-offen-1384627.html

[radneuerfinder]

http://iphone.appleinsider.com/articles/12/02/01/forensics_vendor_warns_mac_os_x_filevault_vulnerable_to_decryption.html

[MacFlieger]

@radneuerfinder: Da bist Du mir ein paar Minuten zuvor gekommen. Ich wollte auch darauf hinweisen.

Diese Lücke ist eigentlich keine FileVault-Lücke, sondern betrifft alle Verschlüsselungssysteme (FileVault, BitLocker in Windows, TrueCrypt) und ist eigentlich eine Firewire-Lücke, die so gewollt ist. Besser macht es das alles nicht.

Mal zusammenfassend:
- Man benutzt FileVault 2, BitLocker oder TrueCrypt ja deshalb, weil man möchte, dass die Daten keinem Unbefugten zugänglich sind. Das ist im Diebstahlfall oder auch bei unbemerktem physischen Zugang eines Unbefugtem zum Gerät. Bei abgeschaltetem Gerät sind diese nach bisherigem Kenntnisstand bei gutem Kennwort auch sicher und nur per Brute-force zu knacken.
- Wenn das System allerdings läuft, dann muss es ja irgendwie auf die Daten zugreifen können und benötigt dafür einen Schlüssel. Denn hat der Benutzer beim Starten eingegeben. Der Schlüssel muss im RAM gehalten werden, um benutzt zu werden.
- Normalerweise sollte und kann kein Prozess auf dem betreffenden Rechner den Schlüssel aus dem RAM extrahieren, denn dazu müsste der Prozess entsprechende Rechte haben. Ohne Sicherheitslücke im System ist das nicht drin.
- Die verlinkte Firma geht aber von einem anderen Rechner aus über eine Firewire-Verbindung aus vor und nutzt ein Feature von Firewire, was wir hier schon öfters kritisch angemerkt haben. Die Firewire-Schnittstelle kann per DMA direkt auf das RAM zugreifen völlig an der CPU und dem laufenden System vorbei. So kann der andere Rechner in Ruhe das komplette RAM auslesen und dort nach dem Kennwort suchen. Da das ganze ein Feature und kein "Fehler" von Firewire ist, kann es auch nicht einfach durch einen Patch behoben werden.

Fazit:
- Sind die Rechner ausgeschaltet, dann sind die Daten sicher vor diesem Angriff.
- Ist der Rechner eingeschaltet oder im Schlafmodus, dann sind die Daten nicht sicher.
- Abhilfe macht nur ein Abschalten der Firewire-Schnittstelle. Geht das auf einem Mac? Müsste wenn überhaupt im EFI passieren, oder?

[Florian]

Reicht es /System/Library/Extensions/IOFireWireFamily.kext zu löschen?

Dann bliebe allerdings immer noch USB und Thunderbird zu deaktivieren.

[MacFlieger]

Reicht es /System/Library/Extensions/IOFireWireFamily.kext zu löschen?

Weiß ich nicht, glaube ich aber nicht, denn Firewire funktioniert ja auch ohne laufendes System.
Das ist eine Hardwaresache, die völlig am System/Prozessor vorbei geht.

Dann bliebe allerdings immer noch USB und Thunderbird zu deaktivieren.

USB hat kein DMA.
Bei Thunderbolt (nicht -bird) ist das gleiche Feature=Problem wie bei Firewire, korrekt.

[Florian]

USB ist aber doch so was von geknackt. Das wird schon irgendwie ausgenutzt werden können.

Habe selbst mal gegoogelt, Löschen der .kext nützt offenbar nichts, steckt man ein Gerät an Firewire dran, läuft es.
Bliebe das Open-Firmware-Passwort?

Das Thema hatten wir aber schon mal (ff.). mbs meinte damals, nur Entfernen der Ports wirke.

Scheinbar ist das immer noch so.

[MacFlieger]

USB ist aber doch so was von geknackt. Das wird schon irgendwie ausgenutzt werden können.

Was meinst Du?
Die gemeldete "Lücke" beruht doch darauf, dass Firewire/Thunderbolt komplett aufs RAM zugreifen kann, ohne dass der Prozessor oder ein laufendes System dazu gefragt werden oder es beeinflussen können.
USB macht ohne ein laufendes System überhaupt nichts.

Habe selbst mal gegoogelt, Löschen der .kext nützt offenbar nichts, steckt man ein Gerät an Firewire dran, läuft es.

Natürlich. Es ist ein Feature der Hardware und hat nix mit dem System zu tun.

Bliebe das Open-Firmware-Passwort?

Was soll das bringen? Die Lücke ist doch nur ausnutzbar, wenn der Rechner vom Benutzer gestartet wurde und läuft bzw. schläft.

Das Thema hatten wir aber schon mal (ff.). mbs meinte damals, nur Entfernen der Ports wirke.

Eben, es ist eine Hardwaresache. Einzige Idee hätte ich, dass man das im EFI deaktivieren können könnte. In dem Fall könnte man es nicht von extern einfach wieder einschalten. Aber ich habe keine Ahnung, ob derartiges machbar ist.

[Florian]

Habe das nicht so konkret auf diesen Fall bezogen, bzw. vermisch-mascht.

USB ist doch allgemein das beliebteste Einfallstor, soviel ich weiß. Mehr wollte ich nicht sagen.

Diese Lücke funktioniert also nur, wenn der Mac läuft. Dann würde aber doch vielleicht ein Löschen der .kext helfen können, weil ja die Firewire-Anschlüsse vom System so überhaupt nicht erkannt werden. So mein erster Gedanke. Stimmt aber nicht.

[MacFlieger]

USB ist doch allgemein das beliebteste Einfallstor, soviel ich weiß. Mehr wollte ich nicht sagen.

Da geht es aber um etwas ganz anderes. Über USB kann dann Malware gestartet werden.

Diese Lücke funktioniert also nur, wenn der Mac läuft. Dann würde aber doch vielleicht ein Löschen der .kext helfen können, weil ja die Firewire-Anschlüsse vom System so überhaupt nicht erkannt werden. So mein erster Gedanke. Stimmt aber nicht.

Ja stimmt nicht, weil Du hier zwei Sachen vermischst.
- Die Lücke=Feature ist in der Hardware. Die Firewire-Schnittstelle hat auch ohne Hilfe oder laufendes System Zugriff auf das RAM. Dagegen kann der Prozessor und ein evtl. laufendes System nichts tun. Dafür braucht auch ein System nicht laufen. Dafür muss der Computer nur unter Strom sein. Also noch einmal: Über Firewire/Thunderbolt können externe Geräte das RAM auslesen und manipulieren, egal ob und was auf dem System läuft.
- Das zweite ist, dass man seine Daten per FileVault/BitLocker/TrueCrypt vor unbefugtem Zugriff (Diebstahl etc.) sichern möchte. Solange der Rechner ausgeschaltet ist, kann kein Angreifer das entschlüsseln. Auch der Zugriff aufs RAM per Firewire, wenn der Dieb das Gerät einschaltet, ist problemlos, denn das RAM ist leer. Wenn aber der Rechner vom Benutzer gestartet wurde, muss der ja das Kennwort eingegeben und der Schlüssel im RAM rumliegen. Dann(!) kann das RAM per Firewire ausgelesen und der Schlüssel extrahiert werden. Danach kann man die Platte entschlüsseln.

Also:
- Hardware erlaubt ungeprüften Zugriff aufs RAM. Da ist keine kext oder irgendwas im Spiel!
- Nur im laufenden System gibt es ein Problem, weil das ohne Schlüssel im RAM nicht laufen kann.

Schaltest Du die kext aus, kann Dein Rechner nicht mehr auf Firewire zugreifen. Der Schlüssel ist aber trotzdem im RAM und die Firewire-Schnittstelle kann direkt aufs RAM zugreifen.

[mbs]

Das grundsätzliche Problem lässt sich in der Tat nicht lösen. Ab Mac OS X 10.7.2 oder höher hat Apple aber ein neues Sicherheits-Feature in den Kernel integriert, der solche Angriffe in vielen Fällen zuverlässig unterbinden kann. Diese Maßnahme besteht darin, dass der DMA-Betrieb der Firewire-Schnittstelle in bestimmten Betriebszuständen hardwaremäßig abgeschaltet wird. Voraussetzung dafür ist:

• Verwendung von Mac OS X 10.7.2 oder höher
• ein Benutzer muss angemeldet sein
• Schneller Benutzerwechsel muss abgeschaltet sein
• Bildschirmschoner mit Kennwortschutz muss eingeschaltet sein

Außerdem kann man zusätzlich erzwingen, dass das FileVault-Kennwort im Ruhezustand aus dem RAM gelöscht wird, indem man (a) den Standby-Ruhezustand verbietet und sofortigen Hibernate-Ruhezustand ("Safe Sleep") erzwingt und (b) die entsprechene Sicherheitsfunktion einschaltet. Beides wird mit dem Befehl

Code: [Auswählen]

sudo pmset -a destroyfvkeyonstandby 1 hibernatemode 25
erledigt.