FileVault ist unsicher

[maceis]

Hättest Du den Thread verfolgt wüsstest Du, dass es genau darum geht.
...

Habe ich

Wenn den Rechner jemand in die Finger bekommt kann er alles rausfinden. Da kann man noch so toll verschlüsseln. Zufällig ausgelagerte Passworte aus einer Auslagerungsdatei herauszufischen setzt auch einen root-Zugriff auf den Rechner voraus.

Meine Rede (Beitrag #10)

Hat jemand die Maschine physikalisch im Zugriff, kann man sich den Root-Zugang sehr einfach und schnell beschaffen.
...

Seh´ ich auch (fast) so, aber sicher nicht (bitte Themenstart lesen) mit ein wenig googeln und "greppen" in den (nach einem Neustart neu angelegten) swapfiles oder in der Gerätedatei des Systemlaufwerks.

Das größere Risiko dürfte IMHO das Backup der Netinfo Datenbank sein und das darin (wenn auch verschlüsselt) abgespeicherte Admin-Kennwort sein.
Evtl. könnte man auch gleich die NI-Datenbank "fälschen".

Und noch was:
Root-Zugang heisst nicht gleichzeitig Zugang zu allen verschlüsselten Daten.
Wer allerdings das root- oder Adminkennwort für die Verschlüsselung sensibler Daten "recycelt" hat selber Schuld.

 

[sgmelin]

mit ein wenig googeln und "greppen" in den (nach einem Neustart neu angelegten) swapfiles oder in der Gerätedatei des Systemlaufwerks.

Das stimmt. Bei mir zumindest. Warum bei anderen das Passwort im Klartext im Swapfile drinsteht ist mir ein Rätsel. Vielleicht sollte man mal die OS Versionen überprüfen. Es ist durchaus denkbar, dass mit einem Sicherheitspatch dieses Leck beseitig wurde und da es noch niemand Publik gemacht hat, hat man es nicht erwähnt, um böse Buben (und Mädels) nicht auf dumme Gedanken zu bringen.

 

[maceis]

Das stimmt. Bei mir zumindest. Warum bei anderen das Passwort im Klartext im Swapfile drinsteht ist mir ein Rätsel. Vielleicht sollte man mal die OS Versionen überprüfen. Es ist durchaus denkbar, dass mit einem Sicherheitspatch dieses Leck beseitig wurde und da es noch niemand Publik gemacht hat, hat man es nicht erwähnt, um böse Buben (und Mädels) nicht auf dumme Gedanken zu bringen.

Wohl eher, um sich selbst keine Blöße zu geben ; aber möglich wärs.
Nur:
Ich habe alle Patches drauf und trotzdem steht bei mir das Passwort im Klartext da.
Seh´ ich aber immer noch nicht als wirkliches Leck, da ja nur root (bzw. ein Admin Benutzer) die swap-files greppen kann.
In den meisten Umgebungen benötige ich also (einfach gesagt) das root-Passwort, um das root-Passwort aus den swapfiles zu greppen *g*.
Ideal finde ich das mit den geswapten Passwörtern aber trotzdem nicht.

 

[abgemeldeter Benutzer]

Ich dachte eigentlich eher, dass bei mir zu wenig RAM da ist, denn bei mir wurde ja (im Gegensatz zu Dir) offensichtlich ausgelagert.
Ich habe ja "nur" 512 MB in meinem Sawtooth.

Im Laufe der 54 Tage hat mein Cube ja auch jede Menge ausgelagert, die Swapdateien sind mittlerweile zusammen schon 3GB groß.
Außerdem steht der Eintrag immer im Swapfile0 und offensichtlich auch ganz am Anfang. Es scheint außerdem die Daten des zuerst angelegten Benutzers zu sein, auch wenn der überhaupt nicht angemeldet war.

@ sgmelin
Bei Dir steht auch kein Passwort im Klartext drin?

 

[sgmelin]

@ sgmelin
Bei Dir steht auch kein Passwort im Klartext drin?

Nein. Der Eintrag sieht bei mir folgendermassen aus:

------------- schnipp ----------------------------------

aepfelchen:~ root# strings -8 /var/vm/swapfile* |grep -A 4 -i longname
Dlongname
Sven Gmelin
password
/bin/bash
username
[...]
---------------- schnapp -----------------------

Also völlig harmlos. Später folgen dann noch andere Einträge, aber nichts, was auch nur annähernd Ähnlichkeit mit meinem Passwort hätte.

Ich habe auch schon den umgekehrten Weg versucht und statt "longname" mein Passwort eingegeben. Da kam dann garnix zurück.

Ha, habs gefunden: Wenn man bei strings statt -8 die länge des tatsächlichen Passworts oder gar nichts eingibt kommt es wirklich. Naja, da aber niemand weiss, wie lang mein Passwort ist, sehe ich noch immer kein grosses Problem. Nichtsdestotrotz sollte man es Apple melden.
Andreas-s: Diese Ehre gebührt Dir, als Finder des Lecks.

 

[eXecUTe]

Die Tatsache dass dieser Bug seit Monaten bekannt ist und immer noch nichts unternommen wurde erlaubt Rückschlüsse auf die Sicherheitspolitik von Apple, weshalb ich zweimal überlegen würde bevor ich Apple-Produkte für irgend eine sicherheitskritische Anwendung einsetze.
[/URL]

ich glaub man sollte nicht immer alles so eng sehen, klar is das ein bug, der sicher bald behoben wird, doch ueberleg doch mal, schaltest du eine win kiste ein, weisst du schon beim start, das jeder 2. deine daten mitlesen kann, ehrlich gesagt fuehl ich mich auf apple doch recht sicher! auch wenn man ueber kleine umwege solche bugs ausnutzten kann oder wie auch immer!

 

[abgemeldeter Benutzer]

Ha, habs gefunden: Wenn man bei strings statt -8 die länge des tatsächlichen Passworts oder gar nichts eingibt kommt es wirklich. Naja, da aber niemand weiss, wie lang mein Passwort ist, sehe ich noch immer kein grosses Problem.

Dann ist es klar, warum es bei manchen erscheint, aber bei mir nicht. In früheren Versionen von Mac OS X wurde das Passwort immer auf 8 Zeichen gekürzt bzw. verlängert. Seit Panther ist das nicht mehr so. Bei Passwörtern, die vorher angelegt worden sind, gilt aber noch die alte Regel.
Wenn das (gleiche) Passwort unter Panther neu eingegeben wird, dann wird es nach der neuen Regel neu angelegt.


P.S. Bei der Tiger-Preview liefert grep überhaupt kein Ergebnis. Vielleicht ist das Problem ja bei Apple schon bekannt.

 

[TerminalX]

Ha, habs gefunden: Wenn man bei strings statt -8 die länge des tatsächlichen Passworts oder gar nichts eingibt kommt es wirklich. Naja, da aber niemand weiss, wie lang mein Passwort ist, sehe ich noch immer kein grosses Problem.

Wenn ich nicht weiß, wie groß dein Passwort ist, gebe ich einfach nichts an. Lies mal was du geschrieben hast.

Gruß,
Dayzd

 

[sgmelin]

Wenn ich nicht weiß, wie groß dein Passwort ist, gebe ich einfach nichts an. Lies mal was du geschrieben hast

Jaja...

 

[?=?]

Ob und wie man das Swap-File untersucht (untersuchen kann) ist eher sekundär.
Irgendjemand wird irgendwann eine Sicherheitslücke finden, um sich den Zugriff zu verschaffen.

Ob und wo Benutzereingaben (wie Passwörter, PINs, etc.) in Swap-Files auftauchen ist in einem präemptiven Multitasking-System (auch Linux, Windows, Solaris, AIX, ...) nur zu einem sehr geringen Ausmaß deterministisch.
Die imho einzig wirkungsvolle Alternative ist, das der gesamte Speicher des Prozesses (der die Daten entgegen nimmt um sie zu verschlüssen!) non-swappable ist.
Das ist im Computer-Security Bereich eigentlich Allgemeinwissen und findet sich so auch in der Standard-Literatur (z.B. Bruce Schneier, Practical Cryptography, Chapter 9.3.2 Swap Files).

Insofern finde ich das von Apple ein schwaches Bild.

 

[TerminalX]

Jaja...

Das ganze nutzt einem ja nichts, weil man das Admin-Passwort braucht um sudo auszuführen. Oder?

--------------------------------------------
Dayzds-Computer:~ *******$ strings /var/vm/swapfile* |grep -A 4 -i longname
strings: can't open file: /var/vm/swapfile0 (Permission denied)
strings: can't open file: /var/vm/swapfile1 (Permission denied)
strings: can't open file: /var/vm/swapfile2 (Permission denied)
strings: can't open file: /var/vm/swapfile3 (Permission denied)

--------------------------------------------

Ich weiß es hat schon jemand das gesagt, nur versteh ich dann die Aufregung nicht.

 

[?=?]

Das ganze nutzt einem ja nichts, weil man das Admin-Passwort braucht um sudo auszuführen. Oder?

. . . sicher, wenn man ein Admin Zugang braucht, um ein Admin Passwort herauszubekommen um sich darüber anschließend Zugriff auf alle Datein zu verschaffen ist das ganze witzlos.
Aber soweit ich verstanden habe geht es hier weniger darum, physichen Zugriff auf eine Datei (FileVault oder anderes verschlüsseltes Image) zu bekommen, denn damit alleine kann man die Datei zwar lesen, aber noch lange nicht entziffern.
Dies funktioniert eben nur mit dem zum verschlüsseln genutzten Passwort. Das nützt es dir eben auch nix, wenn du alle root-Kennwörter der Welt kennst

Wenn also das Verschlüsselungs Passwort irgendwo im Klartext auftaucht ist das eine deutliche Sicherheitslücke, denn Zugriff auf eine beliebige Datei zu bekommen dürfte wesentlich einfacher sein, als 128bit AES zu knacken.

Im übrigen muss jeder seine persönlichen Sicherheitsbedürfnisse selber bestimmen (am besten aufgrund informierter Entscheidungen ).
Für meine Zwecke reicht es aus, wenn nicht jeder Service-Mitarbeiter an meine persönlichen Daten (in einem verschlüsselten Image) kommt falls mein PB mal zur Reparatur muss und ein Durchschnitts-HW-Dieb sich die Nase stößt.


Gruß,

?=?

 

[andreas-s]

Das ganze nutzt einem ja nichts, weil man das Admin-Passwort braucht um sudo auszuführen.

Es gibt unzählige Möglichkeiten:
- System-CD einlegen und Passwort zurücksetzen (macht der Apple-Support genauso)
- von Firewire-Festplatte booten und Platte auslesen
- Platte in anderen Rechner einbauen
- ...


An alle die ihr Passwort mit dem genannten Befehl nicht gefunden haben: lasst mal das "-8" bei Strings weg. Und schämt euch, dass euer Passwort kürzer als 8 Zeichen ist!

 

[maceis]

Es gibt unzählige Möglichkeiten:
- System-CD einlegen und Passwort zurücksetzen (macht der Apple-Support genauso)
- von Firewire-Festplatte booten und Platte auslesen
- Platte in anderen Rechner einbauen
- ...


An alle die ihr Passwort mit dem genannten Befehl nicht gefunden haben: lasst mal das "-8" bei Strings weg. Und schämt euch, dass euer Passwort kürzer als 8 Zeichen ist!

- Bootmöglichkeit von CD kann man unterbinden.
- von FW-Platte booten ebenfalls
- in anderen Rechner einbauen wäre möglich. afaik gelten aber Dateirechte immer noch (sofern man dieses nicht abgeschaltet hat)
aber mal abgesehen davon; der swapfile ist dann futsch, oder ? und auf der Platte irgendwo mit nem Bitreader zusammngehöhrige daten zu finden und zu identifizieren - viel Glück !
---
btw:
Ob andreas-s die zweifelhafte Ehre zusteht, diesen Bug gefunden zu haben wage ich zu bezweifeln. Das Kommando wurde ja schon vor etwa 4 Wochen veröffentlicht und diskutiert

 

[andreas-s]

- in anderen Rechner einbauen wäre möglich. afaik gelten aber Dateirechte immer noch

Was mich aber nicht tangiert wenn ich auf diesem Rechner Root bin.

aber mal abgesehen davon; der swapfile ist dann futsch, oder ?

Nein, das ist eine (bzw. mehrere) Datei wie jede andere auch.

und auf der Platte irgendwo mit nem Bitreader zusammngehöhrige daten zu finden und zu identifizieren - viel Glück !

Selbst wenn die Swapfiles schon gelöscht wurden ist das absolut kein Problem; statt /var/vm/swapfile* nach "longname" zu durchsuchen durchsucht man einfach die Rohdaten der Festplatte (z.B. /dev/disk0s1). Das Ergebnis ist exakt das selbe.

Ob andreas-s die zweifelhafte Ehre zusteht, diesen Bug gefunden zu haben wage ich zu bezweifeln.

Von "zweifelhaft" kann keine Rede sein, ansonsten stimmt es natürlich dass der Bug schon seit einiger Zeit bekannt ist. (meinen Unmut über verschlüsseltes Home-Verzeichnis vs. unverschlüsselter Swap habe ich aber schon vorher kundgetan)

Das Kommando wurde ja schon vor etwa 4 Wochen veröffentlicht und diskutiert

Um so schlimmer dass Apple noch nicht reagiert hat!

 

[sgmelin]

Das ganze nutzt einem ja nichts, weil man das Admin-Passwort braucht um sudo auszuführen. Oder?

Wir drehen uns im Kreis. Wenn ich die Maschine, also auch die Platte habe kann ich mir Zugang verschaffen, ohne das Root Passwort zu kennen.

- in anderen Rechner einbauen wäre möglich. afaik gelten aber Dateirechte immer noch (sofern man dieses nicht abgeschaltet hat)

Die Dateirechte beziehen sich auf die Userkennung und root hat auf jedem Unix kompatiblen System das ich kenne die Userid "0". Und damit auch Zugriff auf alle Files auf der Platte.

der swapfile ist dann futsch, oder

Wann wird denn das Swapfile gelöscht? Beim runterfahren? Dann brauch ich nur die Maschine direkt ausschalten. Wenn es bei hochfahren lediglich mittels eines mkswap neu formatiert wird brauch ich noch nicht mal das.

 

[Tzunami]

Hi, ich konnte das selbe bei meinem iBook mit 384 Mb feststellen, jedoch nicht bei meinem G5 mit 1,5 gb, wenn man den single usermode nicht blockt, ist es ohne weitere anstrengungen möglich das Passwort auszulesen.

 

[sgmelin]

jedoch nicht bei meinem G5 mit 1,5 gb

Dann wird das PW wohl nur bei Bedarf ausgelagert, bzw. das Swapfile ist leer und wird nur proforma aus Performancegründen angelegt.

 

[abgemeldeter Benutzer]

Ist eigentlich bei irgendjemandem mal ein anderes Passwort angezeigt worden, als das von dem User mit der ID 501?

Damit wäre dann zumindestens der Workaround möglich, das man 501 deaktiviert und mit einem anderen Benutzer arbeitet.

 

[andreas-s]

Es landet halt immer das Passwort von dem User im Swap der zuletzt längere Zeit eingeloggt war.