FileVault ist unsicher

[sgmelin]

Ja, ich denke es ist einfach eine Designfrage. Man schreibt einfach keine Passwörter im Klartext auf die Platte.

 

[maceis]

Ja, ich denke es ist einfach eine Designfrage. Man schreibt einfach keine Passwörter im Klartext auf die Platte.

Das seh´ich auch so. Zumal jedes System das mit swaps arbeitet auch einen gewissen Anteil von Daten vor dem Auslagern schützen muss (Stichwort: wired) und somit die Technologie dazu bereits vorhanden ist.

...
wenn man den single usermode nicht blockt, ist es ohne weitere anstrengungen möglich das Passwort auszulesen
...

Wenn man den SU nicht blockt, ist IMHO an so etwas wie Sicherheit sowieso nicht zu denken.

---

Aber eins würde mich jetzt noch interessieren:
Die ganze Diskussion führt zu einem Punkt, der da heisst, wenn man physikalischen Zugriff auf eine Maschine hat, kommt man auch an die Daten (was ja weder neu noch apple-spezifisch ist) und wenn man die Möglichkeit hat auf der Platte nach "longname" zu greppen, kommt man möglicherweise an das geswapte login-Passwort eines Admin.
Wo ist nun aber der Kurzschluss zu dem angeblich unsicheren FileVault (s. Thread-Titel)?

 

[andreas-s]

Aber eins würde mich jetzt noch interessieren:
Die ganze Diskussion führt zu einem Punkt, der da heisst, wenn man physikalischen Zugriff auf eine Maschine hat, kommt man auch an die Daten (was ja weder neu noch apple-spezifisch ist) und wenn man die Möglichkeit hat auf der Platte nach "longname" zu greppen, kommt man möglicherweise an das geswapte login-Passwort eines Admin.
Wo ist nun aber der Kurzschluss zu dem angeblich unsicheren FileVault (s. Thread-Titel)?

Man kommt (bei der mickrigen Standard-Speicherausstattung des Powerbook und dank der häufigen Verwendung des Schlafmodus sogar mit recht guter Wahrscheinlichkeit) an das Login-Passwort des Hauptbenutzers - das ist genau das Passwort mit dem das Filevault-Diskimage verschlüsselt ist. Also einfach die Datei /Users/username/username.sparseimage mit dem neu ergreppten Passwort mounten -> FileVault geknackt.

 

[?=?]

Ja, ich denke es ist einfach eine Designfrage. Man schreibt einfach keine Passwörter im Klartext auf die Platte.

Ich glaube nicht, dass hier (Swapfile) irgendjemand mit Absicht Passwörter im auf Klartext auf die Platte schreibt.

Ein "harmloser" Teil des Systems nimmt bei der Anmeldung die Tastatureingabe entgegen um sie zu verschlüsseln und den verschlüsselten Wert mit dem auf der Platte gespeicherten zu vergleichen.
Ein ganz anderer Teil (Memory-Management) entscheidet, dass sich der betreffende Speicherbereich hervorragend dazu eignet, ausgelagert zu werden, weil er lange nicht mehr angesprochen wurde (...seit dem Login, typische "last recently used"-Strategie).

Leider ist die Login-Routine anscheinend so gestrickt, dass sie weder
a) sofort nach dem verschlüsseln das Klartext-Passwort im RAM löscht,
noch
b) per entsprechendem System-Call vorab dafür sorgt, dass der betroffene RAM Bereich, der das Klartetxt-Passwort enthält non-swappable ist.

Das sind in diesem Zusammenhang genauso "klassische" Fehler wie nicht korrekt behandelte String-Längen in C-Programmen, die Buffer-Overflow Exploits ermöglichen.


Gruß,

?=?

 

[sgmelin]

Ich glaube nicht, dass hier (Swapfile) irgendjemand mit Absicht Passwörter im auf Klartext auf die Platte schreibt

Ob das mit Absicht ist oder nicht ist völlig irrelevant es ist eine potentielle Schwachstelle.

Ein "harmloser" Teil des Systems nimmt bei der Anmeldung die Tastatureingabe entgegen um sie zu verschlüsseln und den verschlüsselten Wert mit dem auf der Platte gespeicherten zu vergleichen.

Warum nimmt man dann nicht gleich diesen Wert? Oder wirft das PW nach dem Login sofort weg. Wenn ich mal drin bin ist es doch eh egal.

Das sind in diesem Zusammenhang genauso "klassische" Fehler wie nicht korrekt behandelte String-Längen in C-Programmen, die Buffer-Overflow Exploits ermöglichen.

Absolut. Umso wichtiger ist es, dieses Problem aus der Welt zu schaffen. Da es ja wohl eine recht einfache Methode zu geben scheint. Und wenn das wohl schon länger bekannt ist, dann wird es Zeit, das Apple endlich in die Rille kommt.

 

[xtian]

Bin mir jetzt nicht 100% sicher, aber liegt das Speichern des Passwortes in der Swap-File nicht an der Terminal.app? Denn dort gibt man ja das PW für 'sudo' ein, ich könnte mir schon vorstellen, daß das so läuft. Ein Blick in mein System zeigt mir, das Terminal.app gut 100Mb swapt und dabei habe ich nur ein Terminal offen. Beim nächsten Neustart kann ich mich ja mal gleich als Root anmelden und da das 'grepen' direkt nach dem Login machen. Meine Theorie: es dürfte kein PW im Klartext in der Swapfile stehen! Aber wie so immer, Theorie und Praxis liegen oft weit aus einander.

xtian

P.S.: Eigentlich habe ich ja gar keine Lust meinen Rechner runterzufahren...

 

[sgmelin]

Bin mir jetzt nicht 100% sicher, aber liegt das Speichern des Passwortes in der Swap-File nicht an der Terminal.app?

Das würde auf einen sehr schlechten Auslagerungsalgorithmus schliessen lassen, da dies ja erst kürzlich benutzt wurde und das älteste zuerst ausgelagert werden sollte.

 

[andreas-s]

Bin mir jetzt nicht 100% sicher, aber liegt das Speichern des Passwortes in der Swap-File nicht an der Terminal.app? Denn dort gibt man ja das PW für 'sudo' ein, ich könnte mir schon vorstellen, daß das so läuft. Ein Blick in mein System zeigt mir, das Terminal.app gut 100Mb swapt und dabei habe ich nur ein Terminal offen.

Es liegt nicht am Terminal. Ich habe einen neuen User angelegt, FileVault aktiviert, mich unter dem Usernamen angemeldet und mit su zum Admin-Account und darüber zu Root gewechselt (ohne mein eigenes Passwort einzugeben). Dann hab ich "ein bisschen" Speicher gefressen (ruby -e 'Array.new(500000000, 1)'), hab das ganze abgebrochen als das System hörbar zu swappen angefangen hat und voila, das Passwort war im Swap auffindbar.

Beim nächsten Neustart kann ich mich ja mal gleich als Root anmelden und da das 'grepen' direkt nach dem Login machen. Meine Theorie: es dürfte kein PW im Klartext in der Swapfile stehen!

Wird es mit Sicherheit auch nicht.

 

[maceis]

...
an das Login-Passwort des Hauptbenutzers - das ist genau das Passwort mit dem das Filevault-Diskimage verschlüsselt ist.
...

Danke für die Nachhilfe. Ihr seht schon: Ich benutze FileVault eh nicht (hab´s noch nie aktiviert).
Wenn ich Daten "schützen" möchte, leg ich die in einem eigenen verschlüsselten Image ab (mit anderem als dem Login-Passwort). Scheint mir irgendwie übersichtlicher und sicherer.
Dieser Fred bestätigt mich in dieser Annahme .

Nach meiner bescheidenen Ansicht, sollten Klartext-Passwörter weder im swapfile noch im RAM stehenbleiben (wozu auch ?).

 

[xtian]

Es liegt nicht am Terminal. Ich habe einen neuen User angelegt, FileVault aktiviert, mich unter dem Usernamen angemeldet und mit su zum Admin-Account und darüber zu Root gewechselt (ohne mein eigenes Passwort einzugeben). Dann hab ich "ein bisschen" Speicher gefressen (ruby -e 'Array.new(500000000, 1)'), hab das ganze abgebrochen als das System hörbar zu swappen angefangen hat und voila, das Passwort war im Swap auffindbar.

Das gibt mir jetzt wirklich zu denken! Das Passwort des neuen Users wurde nur einmal, beim Anmelden, eingegeben?

xtian

P.S.: Und ja, ich habe meinen Denkfehler kurz nach dem Neustart selbst entdeckt Aber so ein Reset tut auch mal gut...

 

[abgemeldeter Benutzer]

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

Nö, bei mir ist ein User im Swap, der nach dem Neustart noch überhaupt nicht angemeldet war.

P.S. Mittlerweile ist der andere Benutzer, also der, der als einziger angemeldet ist dazugekommen.

 

[?=?]

. . ., FileVault aktiviert, . . .

Ich wette, dass ist ein genereller Fehler und das Passwort lässt sich auch finden, wenn FileVault nicht aktiviert ist.
Bloß durch zu gleichzeitige Verwendung des Login-Passworts als (ggf. indirekter) Schlüssel für den FileVault-Zugriff wirds besonders heikel.

Gruß,

?=?

 

[sgmelin]

Ich wette, dass ist ein genereller Fehler und das Passwort lässt sich auch finden, wenn FileVault nicht aktiviert ist.

Selbstverständlich. Ich habe FileVault nicht aktiviert und sehe das PW.

 

[TerminalX]

Habt ihr weitergelesen, oder nur die erste Seite?

>> I'm impressed that grepping the swapfiles on a running Powerbook
>> produced the actual password of the administrator (and root) several
>> times . . . .
>> I've noticed OpenBSD uses encrypted swapfiles to prevent trolling
>> through the swap space for goodies, and reports only trivial
>> performance impact; are there steps one can take currently to use
>> encrypted swap under MacOS X?


> I know of no such way at this time.
>
>File defects with Apple [1] and/or report it to their security folks
>[2].
>
>I wonder how strong the encryption used by OpenBSD really is... sounds
>like it isn't very strong if it is that fast, anyone??? Anyway one way
>to help deal with this would be for applications (including Apples) to
>lock pages that contain such data so they are never swapped out (this
>what is usually done). So I consider this a defect of Apple login
>process and possible the authentication framework.
>
>As a side note I never see this stuff on my systems because of the
>amount of RAM I have and my usage pattern.


What I want to know is, what happens to your keystrokes before ssh or gpg
(or a future authentication framework) reads them into an mlocked buffer?
And then there are those who copy and paste passwords thinking that
copying from a file stored in encrypted form makes it safe. The thing is,
none of this would matter given encrypted swap (and no core dumps).

Ich mach erst seit einem Jahr Englisch in der Schule. *schähm* Ich hab paar Probleme diesen Text zu verstehen. Kann mir jemand helfen?
Was ich verstanden hab:
-Also OpenBSD benutzt irgendwie verschüsselte SwapFiles, doch Mac OS X nicht.
-Der Fehler scheint beim Apple login Prozess und dem authentication framework zu liegen.

Ich glaube, dass war das Wichtigste, oder hab ich noch was wichtiges vergessen?

Gruß,
Dayzd

 

[sgmelin]

Der Fehler scheint beim Apple login Prozess und dem authentication framework zu liegen.

Wie schon mehrfach erwähnt, wenn die Speicherbereiche, in denen Passwörter liegen vom Swapping ausgenommen werden, dann ist das Problem hinfällig, wenn man es denn als Problem einstufen kann. Denn wie wir bereits mehrfach festgestellt haben gehört eine Menge Energie dazu, sich das Passwort anzueignen. Ich will es jetzt nicht verharmlosen, aber einen solchen Wind zu machen ist schon ziemlich heftig.

 

[andreas-s]

Das nennst du "eine Menge Energie"? Wenn jemand ein Notebook "findet" auf dem Filevault aktiviert ist, dann bekommt er mit sehr hoher Wahrscheinlichkeit das Passwort dafür gleich frei Haus dazu; wenn du keine Angst davor hast dass dein Notebook gestohlen wird, wozu dann überhaupt noch FileVault?

Filevault ist kaputt, daran lässt sich nichts rumdiskutieren. Es erfüllt seinen Zweck nicht, nämlich die Daten bei physikalischem zugriff auf das Gerät zu schützen. Und dass Apple behauptet es wäre geeignet um "trade secrets" abzusichern obwohl dieses Problem seit Wochen bekannt ist, ist fast schon grob fahrlässig.

 

[vuuduu]

Das nennst du "eine Menge Energie"? Wenn jemand ein Notebook "findet" auf dem Filevault aktiviert ist, dann bekommt er mit sehr hoher Wahrscheinlichkeit das Passwort dafür gleich frei Haus dazu; wenn du keine Angst davor hast dass dein Notebook gestohlen wird, wozu dann überhaupt noch FileVault?

Filevault ist kaputt, daran lässt sich nichts rumdiskutieren. Es erfüllt seinen Zweck nicht, nämlich die Daten bei physikalischem zugriff auf das Gerät zu schützen. Und dass Apple behauptet es wäre geeignet um "trade secrets" abzusichern obwohl dieses Problem seit Wochen bekannt ist, ist fast schon grob fahrlässig.

da gebe ich dir 100%ig recht, insbesondere deswegen, da in mehr als 50% der fälle root und fv passwort identisch sein dürften.

ich verstehe hier die verharmlosung des problems seitens einiger user wirklich nicht und kann mir das nur mit der im apple bereich leider gern vorhandenen rosaroten brille erklären... ich erwarte von apple in osx 10.3.5 mindestens eine verschlüsselung der swapfiles wie oben an openbsd gezeigt, eigentlich jedoch eine überarbeitung der kritischen systemroutinen, so dass die entsprechenden speicherbereiche nicht mehr ausgelagert werden.

wenn ein entsprechendes feature wie filevault mit klarem focus auf geschäftliche nutzer mit sensiblen daten nicht das gewünschte ergebnis bringt, dann gehört das geradegezogen. schnellstmöglich. punkt.

mfg
vuuduu

 

[sgmelin]

ich verstehe hier die verharmlosung des problems seitens einiger user wirklich nicht und kann mir das nur mit der im apple bereich leider gern vorhandenen rosaroten brille erklären...

Das hat nix mit der rosaroten Apple Brille zu tun. Ich benutze bereits seit fast acht Jahren Notebooks im Aussendienst und bin häufig mit dem Zug oder dem Flieger unterwegs. Und mir ist noch gar nie was weggekommen. Weder ein Notebook (und ich habe immer IBM Notebooks der Oberklasse) noch ein Palm oder ein Handy. Zudem sind auf meinen Portablen gerätschaften nur Daten, die keinem bösen Menschen etwas nutzen. Alles andere befindet sich auf anderen Datenträgern. Ein Memorystick für den Schlüsselbund mit allen wichtigen Daten wie Kreditkartennummern, Passwörtern o.ä. ist die einfachste und sicherste Methode.
Davon das Swapfile zu verschlüsseln halte ich nichts. Auch wenn von einem geringen Impact auf das System gesprochen wird kann mir niemand weiss machen, dass man das nicht merkt. Und wenn die Kiste auf die Platte zugreift, dann ist sie eh schon so lahm, daß ich wirklich das letzte Quäntchen Performance haben will. Das Leck ist da. Daran gibt´s nix zu deuteln. Apple sollte sich schleunigst daran machen es zu stopfen. Und die beste Methode ist die, die auch Du präferierst, nämlich den Passwortteil nicht mehr auszulagern.
Aber wir sollten uns nicht verrückt machen. Wenn hier schon so empfindlich damit umgegangen wird, sollte auch jeder mal sein Passwort überprüfen. Ich halte jede Wette, daß 95% aller Benutzer ein Passwort haben, welches man mit Leichtigkeit knacken kann. Wir sollten also nicht mit zweierlei Maß messen. Entweder sicher, oder nicht. Und dann wird das Passwort gefälligst auch jede Woche gewechselt, mit Speicherung und verbot der letzten 52 Passworte und mindesten zwei Ziffern und beachteter gross/kleinschreibung mit mehreren unterschiedlichen Konsonanten hintereinander!

 

[vuuduu]

Weder ein Notebook (und ich habe immer IBM Notebooks der Oberklasse) noch ein Palm oder ein Handy. Zudem sind auf meinen Portablen gerätschaften nur Daten, die keinem bösen Menschen etwas nutzen. Alles andere befindet sich auf anderen Datenträgern. Ein Memorystick für den Schlüsselbund mit allen wichtigen Daten wie Kreditkartennummern, Passwörtern o.ä. ist die einfachste und sicherste Methode.

Dann ist das FileVault Leck für Dich persönlich auch nicht relevant, einverstanden.

...Ich halte jede Wette, daß 95% aller Benutzer ein Passwort haben, welches man mit Leichtigkeit knacken kann. Wir sollten also nicht mit zweierlei Maß messen. Entweder sicher, oder nicht. Und dann wird das Passwort gefälligst auch jede Woche gewechselt, mit Speicherung und verbot der letzten 52 Passworte und mindesten zwei Ziffern und beachteter gross/kleinschreibung mit mehreren unterschiedlichen Konsonanten hintereinander!

Bei der Wette gehe ich mit, den Rest halte ich für meine persönliche Anforderung übertrieben. Mein Passwort hat mehr als acht Zeichen, steht nicht im Wörterbuch und besitzt vier Zahlen bzw. Sonderzeichen.

Mein Powerbook ist auch mit funktionierendem FileVault gg. Geheimdienste o.ä. ungeschützt, die haben hunderte Möglichkeiten daran zu kommen, wenn sie sich dafür interessieren würden. Aber die restlichen 99% aller möglichen Angreifer möchte ich gerne von meinen persönlichen und geschäftlichen Daten fernhalten, das Passwort wäre sicher genug, meine Eigenintelligenz ist sicher ausreichend, nur das Tool versagt leider. Vielleicht sollte ich auch wieder auf externe Datenträger umsteigen

 

[maceis]

da kann ich sgmelin nur zustimmen.

Abgesehen davon Sicherheit immer ein Gesamtkonzept und nicht durch einen einzelnen Faktor zu gewährleisten.
Und, wie jeder weiß: Absolute Sicherheit gibt es nicht und schon gar nicht im IT-Bereich.
Zum Thema Verschlüsselung der swapfiles bei Open-BSD habe ich übrigens gelesen, dass die Verschlüsselung gar nicht so stark sein soll (hat sicher auch was mit Performance zu tun).