Passwörter im Speicher schützen
-
Hi,
eine Frage, die mich nicht erst seit meiner Beschäftigung mit C++ "umtreibt", ist wie Kennwörter, die im Speicher landen, geschützt werden. Gegeben Sei eine Anwendung die Dateien mit einem vom Nutzer gesetzten Kennwort verschlüsselt. Dieses Kennwort wird selbstverständlich im einem Sha-512-Hash so lange die Anwendung inaktiv ist, gespeichert. Doch nach einem erfolgreichen Vergleich des gespeicherten Hashes mit der Nutzeringabe muss das Kennwort im Klartext ja im Speicher gehalten werden, sonst kann es von der Anwendung zum Verschlüsseln der Dateien nicht eingesetzt werden. Doch damit muss doch ein Angreifer eigentlich nur noch den ganzen RAM kopieren und dann eben nach etwas ausschau halten, was nach einem Kennwort aussieht, oder? Oder schützt das OS mich davor, daß der RAM ausgelesen wird, oder muss ich da in meinem programm eine Maßnahme ergreifen?
Ich nehme an, daß die Lösung für dieses Frag wahrscheinlich relativ bekannt ist, aber die Suchmaschine meiner Wahl hat da irgendwie nichts schönes zu Tage gefördert
-
Ich bin kein Expetre in dem Gebiet, aber so lange jemand physichen Zugang zum rechner hat kann er wirklich den Speicherinhalt kopieren. Ich denke auch das dies nicht zu verhindern ist, so lange das Benutzerkonto des betriebssystems diese Rechte hat.
Idee 1:
Das Programm nur verwenden wenn das aktuelle Benuterkonto nicht ausreichend Rechte hat um Speicher fremder programme auszulesen.Idee 2:
So lange der Hashwert nicht fürs Ent- und Verschlüsseln nicht gebraucht wird, diesen leicht verändert im Speicher halten. (z.B x abziehen). Für das Ver- und Entschlüsseln x hinzuaddieren und das Ver- und Entschlüsseln durcdhführen. Danach wieder x abziehen bis zur nächsten Verwendeung. Dies ist kein wirklicher Schutz, dennoch sollte es zumindest für etwas Verwirrung sorgen wenn Jemand versucht den Wert auszulesen.
-
MisterX schrieb:
Ich bin kein Expetre in dem Gebiet, aber so lange jemand physichen Zugang zum rechner hat kann er wirklich den Speicherinhalt kopieren. Ich denke auch das dies nicht zu verhindern ist, so lange das Benutzerkonto des betriebssystems diese Rechte hat.
Ja, ein Admin wird es immer auslesen können, sonst hätte er keine Admin-Rechte.
MisterX schrieb:
Idee 1:
Das Programm nur verwenden wenn das aktuelle Benuterkonto nicht ausreichend Rechte hat um Speicher fremder programme auszulesen.So ähnlich wird es üblicherweise auch gemacht: Das Passwort wird im Speicherbereich eines Treibers gehalten. Der Speicher eines Treibers ist nochmal eine Spur sicherer als der Speicher anderer Programme, was das Auslesen angeht. Um den auszulesen, bräuchte man dann schon einen anderen Treiber oder ähnliches.
edit: Das funktioniert aber natürlich nicht bei Verschlüsselungssystemen, die als normale User-Space-Programme ohne Admin-Rechte funktionieren sollen. In dem Fall ist man der Vertrauenswürdigkeit des Systems, also zumindest dem aktuellen User-Konto und Admin-Konten, komplett ausgeliefert. Dagegen gibt es dann z.B. Techniken wie Smart-Cards und Kartenleser mit Tastenfeld: Der Schlüssel verlässt den Kartenleser nie, am PC kann man also nichts geheimes auslesen. Das erlaubt aber wieder andere Angriffsszenarien.
MisterX schrieb:
Idee 2:
So lange der Hashwert nicht fürs Ent- und Verschlüsseln nicht gebraucht wird, diesen leicht verändert im Speicher halten. (z.B x abziehen).Das ist security through obscurity, denn es hängt davon ab, dass der Algorithmus geheim bleibt. Vermittelt ein falsches Gefühl von Sicherheit.
-
sud schrieb:
Doch damit muss doch ein Angreifer eigentlich nur noch den ganzen RAM kopieren und dann eben nach etwas ausschau halten, was nach einem Kennwort aussieht, oder?
Den Arbeitsspeicher einer laufenden Anwendung kann man nicht so einfach kopieren, da mittlerweile bei den meisten OS alle Programme in virtuellen Adreßräumen laufen und man keinen Zugriff auf die Adreßräume anderer Programme hat. Ausnahmen sind shared mem Bereiche und der Kernel, der immer auf alles zugreifen kann, das ist auch der einzige der den physikalischen Speicher sieht. Alle anderen sehen nur virtuelle Speicherabbilder.
Damit das ganze halbwegs sicher ist, sollte folgende Dinge sicherstellen. Speicher der Paßwörter enthält darf nicht ausgelagert werden, und man sollte ihn unbedingt vor Beenden überschreiben. Da sonst es theoretisch möglich ist, daß jemand das Paßwort via RAM-Anforderung lesen könnte (Speicher wird dabei meist nicht gelöscht sondern einfach nur neu zugeteilt), gleiches gilt für den Speicher in der Auslagerungsdatei/partition.
-
Wenn einer es schon auf deinen Rechner geschafft hat und unkontrolliert auf deinen Arbeitsspeicher zugreifen kann, ist doch schon alles zu spät.
-
~john schrieb:
Da sonst es theoretisch möglich ist, daß jemand das Paßwort via RAM-Anforderung lesen könnte (Speicher wird dabei meist nicht gelöscht sondern einfach nur neu zugeteilt)
Soweit ich weiß, füllen alle aktuellen Linux- und Windows-Versionen angeforderte Speicherseiten mit 0en, bevor ein Programm sie bekommt. Nicht initialisierte Seiten zu liefern wäre auch nicht akzeptabel bei modernen Multi-User-Betriebssystemen, denn es könnten ja auch private Daten von anderen Usern in der Seite stehen.
Die Auslagerungsdatei ist auch nicht das Problem, solange der Rechner läuft, denn das Betriebssystem sperrt den Zugriff darauf genauso wie auf fremde RAM-Bereiche. Die Auslagerungsdatei wird aber zum Problem, wenn der Rechner heruntergefahren wird. Falls ein Passwort ausgelagert wurde, könnte es in so einem Fall auf der Festplatte im Klartext stehen. Dagegen gibt es aber mit encrypted swap eine einfache Lösung, zumindest für Linux.
-
Christoph schrieb:
~john schrieb:
Da sonst es theoretisch möglich ist, daß jemand das Paßwort via RAM-Anforderung lesen könnte (Speicher wird dabei meist nicht gelöscht sondern einfach nur neu zugeteilt)
Soweit ich weiß, füllen alle aktuellen Linux- und Windows-Versionen angeforderte Speicherseiten mit 0en, bevor ein Programm sie bekommt. Nicht initialisierte Seiten zu liefern wäre auch nicht akzeptabel bei modernen Multi-User-Betriebssystemen, denn es könnten ja auch private Daten von anderen Usern in der Seite stehen.
Source pls
-
INTER ESSANT schrieb:
Christoph schrieb:
~john schrieb:
Da sonst es theoretisch möglich ist, daß jemand das Paßwort via RAM-Anforderung lesen könnte (Speicher wird dabei meist nicht gelöscht sondern einfach nur neu zugeteilt)
Soweit ich weiß, füllen alle aktuellen Linux- und Windows-Versionen angeforderte Speicherseiten mit 0en, bevor ein Programm sie bekommt. Nicht initialisierte Seiten zu liefern wäre auch nicht akzeptabel bei modernen Multi-User-Betriebssystemen, denn es könnten ja auch private Daten von anderen Usern in der Seite stehen.
Source pls
Zum Beispiel http://stackoverflow.com/questions/1327261/is-memory-cleared-by-the-linux-kernel-when-brk-is-reduced-then-increased-again , mit Link zum Kernel-Source.
In der manpage von mmap steht sogar explizit, was passiert, wenn man ein "anonymes" mapping anfordert, d.h. ein mapping ohne Datei dahinter:
man mmap schrieb:
MAP_ANONYMOUS
The mapping is not backed by any file; its contents are initialized to zero.
-
Christoph schrieb:
MisterX schrieb:
Idee 2:
So lange der Hashwert nicht fürs Ent- und Verschlüsseln nicht gebraucht wird, diesen leicht verändert im Speicher halten. (z.B x abziehen).Das ist security through obscurity, denn es hängt davon ab, dass der Algorithmus geheim bleibt. Vermittelt ein falsches Gefühl von Sicherheit.
Da gebe ich dir recht, aber für das 08/15 Scriptkid dürfte es doch reichen oder nicht? Zumal man diesen Wert der abgezogen wird auch bei jedem Programmstart random erzeugen könnte.
Und im Klartext würde ich das PW eh nicht im Speicher halten, sondern nur als SHA1 Hash.
100% sicher wirds eh nicht, am Ende kommt einer mit nem Keylogger und der ganze Käse ist ausgehebelt.
-
Sehe ich das richtig, daß es im Prinzip keine weitere Möglichkeit gibt, als zu schauen, daß das PW nach dem Beenden des Programms im Speicher auf jeden Fall überschrieben und auch nicht ausgelagert wird, und daß man sonst auf die Fähigkeiten des OS vertrauen muss, daß niemand anders den Speicher auslesen kann [der dazu nicht qua seines Statuses als root befugt ist]?
-
Wenn jemand admin Rechte hat dann kann er auf dem PC alles tun. Auch im Speicher anderer Prozesse rummachen. Wäre auch irgendwie blöd wenn das nicht ginge, würd mich persönlich ziemlich ärgern wenn ich auf meinem PC nicht tun könnte was ich will. Zu versuchen sich gegen einen Amin zu schützen ist imo der falsche Weg. Besser wäre es zu verhindern dass jemand der nicht soll überhaupt erst solche Rechte bekommt. Aber das wurde hier eh schon mehrmals gesagt...
-
Scorcher24 schrieb:
Christoph schrieb:
MisterX schrieb:
Idee 2:
So lange der Hashwert nicht fürs Ent- und Verschlüsseln nicht gebraucht wird, diesen leicht verändert im Speicher halten. (z.B x abziehen).Das ist security through obscurity, denn es hängt davon ab, dass der Algorithmus geheim bleibt. Vermittelt ein falsches Gefühl von Sicherheit.
Da gebe ich dir recht, aber für das 08/15 Scriptkid dürfte es doch reichen oder nicht? Zumal man diesen Wert der abgezogen wird auch bei jedem Programmstart random erzeugen könnte.
Ja, aber genau das ist security through obscurity: Du musst den Algorithmus geheimhalten. Wenn du das Programm open source stellst, was bei Verschlüsselungsprogrammen gar nicht verkehrt ist, wenn man Vertrauen schaffen möchte, dann wird sich jeder fragen "was macht der da für unnötige Berechnungen?".
Scorcher24 schrieb:
Und im Klartext würde ich das PW eh nicht im Speicher halten, sondern nur als SHA1 Hash.
Das geht hier nicht, weil man zum Entschlüsseln von Daten normalerweise das Passwort (bzw. den daraus abgeleiteten Key) im Klartext benötigt.
-
Christoph schrieb:
Scorcher24 schrieb:
Und im Klartext würde ich das PW eh nicht im Speicher halten, sondern nur als SHA1 Hash.
Das geht hier nicht, weil man zum Entschlüsseln von Daten normalerweise das Passwort (bzw. den daraus abgeleiteten Key) im Klartext benötigt.
Ja genau das ist mein Problem. Und irgendwie frage ich mich wie ich diese Sicherheitslücke "stopfen" kann, da ja sonst das Passwort mit besten Hash-Alogirthmen gesichert wird, aber dann letztlich die ganze Verwendung über "offen" im Speicher liegt.
Und klar, root kann ein Speicherabbild ziehen, aber warum soll er damit das PW auch sehen dürfen, wenn er ein Fetplattenabbild zieht, sieht er ja irgendwie auch nur den Hash? Oder ist das einfach nicht vergleichbar?
-
Wenn du mit dem Passwort arbeiten willst dann muss es spätestens zum gegebenen Zeitpunkt irgendwann zwangsweise im Speicher liegen, auch wenn das vielleicht nur ganz kurz ist und ganz egal was du sonst alles damit anstellst, ich wüsste nicht wie man das prinzipiell verhindern sollte. Selbst wenn dus mit Assembler oder sonst wie so hinbiegst dass das Passwort nur in den Registern der CPU liegt werden diese ja vom OS bei einem Context Switch irgendwo in den Speicher gesichert. Vielleicht kann man irgendwas machen damit es nur einmalig im Cache liegt und da dann irgendwelche kranken Tricks von wegen Cacheprotokoll oder was weiß Gott was abziehen...rein prinzipiell wüsste ich aber auch da nicht was man da groß machen kann außer Obfuscation. Und am Ende muss zumindest der Maschinencode in die CPU rein und dann komm ich an den ran und kann einfach deinen Algorithmus analysieren und von mir aus zurückrechnen oder was auch immer. 100% Sicherheit gibts da einfach nicht. Wenn der Angreifer physikalisch Zugang zum Rechner hat dann gibt es keinen absoluten Schutz. Selbst wenn du noch soviel Zeit investierst, zumindest irgendeine Seitenkanalattacke wird es immer geben. Und wenn ein Angreifer, wie auch immer, an ein Speicherabbild kommt dann ist es nur eine Frage von Zeit, Geduld, Wissen, Intelligenz, Motivation, usw. des Angreifers und keine Frage der prinzipellen Machbarkeit mehr.
-
Es sei denn du greifst auf solcherlei Technologie zurück: http://en.wikipedia.org/wiki/Trusted_Computing
MfG SideWinder
-
Auch da kann ein Angreifer die entsprechenden Hardwarekomponenten unter ein Elekronenmikroskop legen und die Ströme messen und was weiß ich. Auch wenn das natürlich kaum wer machen wird, 100%ige Sicherheit ist rein Prinzipiell nicht Möglich.
-
Hmm, naja mal dumm gefragt: Wie machen es Multiplayer Spiele? Da muss ja auch eine gewisse Sicherheit herrschen, vor allem im Bereich MMORPG. Und Blizzard demonstriert ja schön, wie man entgegenwirken kann, wie dem Authenticator der einen Zusatz Key generiert der nur kurz gültig ist. Aber auch hier gibts "Man in the Middle" Angriffe.
-
dot schrieb:
Auch da kann ein Angreifer die entsprechenden Hardwarekomponenten unter ein Elekronenmikroskop legen und die Ströme messen und was weiß ich. Auch wenn das natürlich kaum wer machen wird, 100%ige Sicherheit ist rein Prinzipiell nicht Möglich.
Dort geht die Sicherheit - zumindest laut Hersteller - aber soweit, dass eine Attacke länger dauert und kostspieliger ist als die gewonnene Information. Auch RSA-Verschlüsselung ist ja nur solange sicher, solange man nicht genügend Mittel und Zeit hat um die Primfaktorenzerlegung durchzuführen.
MfG SideWinder
-
Scorcher24 schrieb:
Hmm, naja mal dumm gefragt: Wie machen es Multiplayer Spiele?
Ganz einfach: Multiplayer Spiele laufen auf Servern die der absoluten Kontrolle des Hersteller unterliegen. Was auch immer dein Client lokal für Schweinereien macht, für das Spiel zählt das was der Server sagt und der sagt ganz einfach nein wenn dein Client vorgibt mit 1000000 Lebenspunkten und mit 4facher Lichtgeschwindigkeit durch die Gegend zu laufen...
-
sud schrieb:
Und klar, root kann ein Speicherabbild ziehen, aber warum soll er damit das PW auch sehen dürfen
Darf er, denn genau das bedeutet "root" bei Linux: root darf alles.
root könnte z.B. auch einfach alle Tastatureingaben abfangen, die ein normaler User vornimmt. Wenn root das geschickt genug macht, merkt der User davon gar nichts. Auch das ist ein Recht von root. Fazit ist, als User muss man root vertrauen.
