Sie berühren einen wunden Punkt ...

In der Vergangenheit waren Computer Mainframes , in denen viele unterschiedliche Benutzer Sitzungen und Prozesse auf dem Computer starteten gleiche physische Maschine. Unix-ähnliche Systeme (z. B. Linux), aber auch VMS und seine Verwandten (und diese Familie umfasst alle Windows der NT-Reihe, daher 2000, XP, Vista, 7, 8 ...) wurden strukturiert, um das zu unterstützen Mainframe-Modell.

Somit bietet die Hardware Berechtigungsstufen . Ein zentrales Element des Betriebssystems ist der Kernel , der auf der höchsten Berechtigungsstufe ausgeführt wird (ja, ich weiß, dass es Feinheiten in Bezug auf die Virtualisierung gibt) und die Berechtigungsstufen verwaltet. Anwendungen werden auf einer niedrigeren Ebene ausgeführt und vom Kernel gewaltsam daran gehindert, den Speicher des anderen zu lesen oder zu schreiben. Anwendungen erhalten RAM von Seiten (normalerweise 4 oder 8 kB) vom Kernel. Eine Anwendung, die versucht, auf eine Seite zuzugreifen, die zu einer anderen Anwendung gehört, wird vom Kernel blockiert und schwer bestraft ("Segmentierungsfehler", "allgemeiner Schutzfehler" ...).

Wenn eine Anwendung nicht mehr benötigt wird Bei einer Seite (insbesondere beim Beenden der Anwendung) übernimmt der Kernel die Kontrolle über die Seite und gibt sie möglicherweise an einen anderen Prozess weiter. Moderne Betriebssysteme "leeren" Seiten, bevor sie zurückgegeben werden, wobei "Ausblenden" "Füllen mit Nullen" bedeutet. Dies verhindert, dass Daten von einem Prozess zu einem anderen verloren gehen. Beachten Sie, dass Windows 95/98 / Millenium keine leeren Seiten hat und Lecks auftreten können. Diese Betriebssysteme waren jedoch für einen einzelnen Benutzer pro Computer gedacht.

Natürlich gibt es Möglichkeiten, dem Zorn des Kernels zu entkommen: Anwendungen, die "genug Privilegien" haben (nicht die gleichen Privilegien wie oben), stehen einige Türen zur Verfügung. Auf einem Linux-System ist dies ptrace (). Der Kernel ermöglicht es einem Prozess, den Speicher des anderen über ptrace () zu lesen und zu schreiben, vorausgesetzt, beide Prozesse werden unter derselben Benutzer-ID ausgeführt oder der Prozess, der ptrace () ausführt, ist ein "Root" -Prozess. Ähnliche Funktionen gibt es in Windows.

Unter dem Strich sind Kennwörter im RAM nicht sicherer als das, was das Betriebssystem zulässt. Per Definition durch Speichern einiger vertraulicher Daten im Speicher Bei einem Prozess vertrauen Sie dem Betriebssystem, dass es nicht an Dritte weitergegeben wird. Das Betriebssystem ist Ihr Freund , denn wenn das Betriebssystem ein Feind ist, haben Sie völlig verloren.

Jetzt kommt der lustige Teil. Da das Betriebssystem eine Prozesstrennung erzwingt, haben viele Menschen versucht, Wege zu finden, um diese Abwehrkräfte zu durchdringen. Und sie fanden ein paar interessante Dinge ...

• Der "RAM", den die Anwendungen sehen, ist nicht unbedingt wahrer "Speicher". Der Kernel ist ein Meister der Illusionen und gibt Seiten, die nicht unbedingt existieren. Die Illusion wird aufrechterhalten, indem RAM-Inhalte gegen einen dedizierten Speicherplatz auf der Festplatte ausgetauscht werden, auf dem in größeren Mengen freier Speicherplatz vorhanden ist. Dies wird als virtueller Speicher bezeichnet. Anwendungen müssen sich dessen nicht bewusst sein, da der Kernel die Seiten bei Bedarf zurückbringt (aber die Festplatte ist natürlich viel langsamer als der Arbeitsspeicher). Eine unglückliche Folge ist, dass einige Daten, die angeblich im RAM gespeichert sind, auf ein physisches Medium gelangen, auf dem sie bis zum Überschreiben verbleiben. Insbesondere bleibt es dort, wenn die Stromversorgung unterbrochen wird. Dies ermöglicht Angriffe, bei denen der Bösewicht die Maschine greift und damit davonläuft, um die Daten später zu überprüfen. Oder es kann zu Undichtigkeiten kommen, wenn eine Maschine außer Betrieb genommen und bei eBay verkauft wird und der Systemadministrator vergessen hat, den Festplatteninhalt zu löschen.

  Linux bietet ein System namens mlock (), das verhindert, dass der Kernel bestimmte Seiten an den Swap Space sendet. Da das Sperren von Seiten im RAM die verfügbaren RAM-Ressourcen für andere Prozesse erschöpfen kann, benötigen Sie einige Berechtigungen (erneut root), um diese Funktion zu verwenden.

  Ein erschwerender Umstand ist, dass es nicht unbedingt einfach ist, den Überblick darüber zu behalten, wo Sie sich befinden Passwort ist wirklich im RAM. Als Programmierer greifen Sie über die von der Programmiersprache bereitgestellte Abstraktion auf RAM zu. Insbesondere Programmiersprachen, die Garbage Collection verwenden, können Objekte im RAM transparent kopieren (da dies für viele GC-Algorithmen wirklich hilfreich ist). Die meisten Programmiersprachen sind daher betroffen (z. B. Java, C # /. NET, Javascript, PHP, ... die Liste ist fast endlos).

• Ruhezustand bringt die gleichen Themen mit aller Macht zurück. Der Ruhezustand muss von Natur aus den gesamten RAM auf die Festplatte schreiben - dies kann Seiten enthalten, die gesperrt wurden, und sogar den Inhalt der CPU-Register. Um Lecks im Ruhezustand zu vermeiden, müssen Sie drastische Maßnahmen wie die Verschlüsselung der gesamten Festplatte ergreifen. Dies bedeutet natürlich, dass Sie das Entsperrkennwort eingeben, wenn Sie den Computer aktivieren.

• Das Mainframe-Modell geht davon aus, dass es mehrere Prozesse ausführen kann, die einander feindlich gegenüberstehen und dennoch vollkommenen Frieden und Isolation bewahren. Moderne Hardware macht das sehr schwierig. Wenn zwei Prozesse auf derselben CPU ausgeführt werden, teilen sie sich einige Ressourcen, einschließlich des Cache-Speichers. Speicherzugriffe sind im Cache viel schneller als anderswo, aber die Cache-Größe ist sehr begrenzt. Dies wurde ausgenutzt, um kryptografische Schlüssel wiederherzustellen, die von einem Prozess von einem anderen verwendet werden. Es wurden Varianten entwickelt, die andere cacheähnliche Ressourcen verwenden, z. Verzweigungsvorhersage in einer CPU. Während sich die Forschung zu diesem Thema auf kryptografische Schlüssel konzentriert, die hochwertige Geheimnisse sind, könnte sie wirklich auf alle Daten zutreffen.

  In ähnlicher Weise können Grafikkarten direkten Speicherzugriff ausführen. Ob DMA nicht zum Lesen oder Schreiben von Speicher aus anderen Prozessen missbraucht werden kann, hängt davon ab, wie gut undokumentierte Hardware, Closed-Source-Treiber und Kernel zusammenarbeiten, um die entsprechenden Zugriffskontrollen durchzusetzen. Ich würde mein letztes Shirt nicht darauf wetten ...

Fazit: Ja, wenn Sie ein Passwort im RAM speichern, Sie vertrauen dem Betriebssystem, um dies vertraulich zu behandeln. Ja, die Aufgabe ist schwierig, auf modernen Systemen sogar nahezu unmöglich. Wenn einige Daten streng vertraulich sind, sollten Sie das Mainframe-Modell wirklich nicht verwenden und potenziell feindlichen Entitäten nicht erlauben, ihren Code auf Ihrem Computer auszuführen.

(Dies bedeutet übrigens, dass virtuelle Maschinen gehostet werden und Cloud Computing kann letztendlich nicht sicher sein. Wenn Sie die Sicherheit ernst nehmen, verwenden Sie dedizierte Hardware.)

Ich denke, das Betriebssystem erledigt seine Arbeit und vermeidet Prozesse, um auf den zugewiesenen Speicher anderer zuzugreifen. Aber ich denke das ist irgendwie machbar.

Ja, es ist möglich, auf den Speicher eines anderen Prozesses zuzugreifen. Unter Windows bedeutet dies, dass Sie SE_DEBUG_PRIVILEGE haben und ReadProcessMemory () verwenden, um die gewünschten Informationen zu extrahieren.

Sie können Machen Sie dasselbe mit einem Windows-Treiber, obwohl es aufgrund einiger Komplikationen mit dem aktuell in der unteren Hälfte ausgelagerten Speicher etwas schwieriger ist, das Problem zu beheben.

In beiden Fällen müssen Sie Zugriff haben einem Administratorkonto oder einem Prozess, der falsch SE_DEBUG_PRIVILEGE zugewiesen wurde, oder einem Prozess mit diesem Privileg, der dazu gebracht werden kann, das zu tun, was Sie benötigen kann eskalieren, um diese Berechtigungen zu erhalten. Realistischer stellen wir sicher, dass nur vertrauenswürdige Benutzer über diese Berechtigungen verfügen können. Wenn Sie Zugriff auf ein Administratorkonto haben, können Sie ein Kennwort ganz einfach direkt aus dem Prozessspeicher eines anderen Kontos lesen.

Unter Linux können Sie dasselbe mit ptrace ( ) und die Option PTRACE_PEEK_DATA .

Sie fragen sich möglicherweise, warum diese Funktionen überhaupt vorhanden sind? Tatsächlich sind sie unglaublich praktisch zum Debuggen von Prozessen. Möglicherweise möchte ein Administrator dies tun. Im Gegensatz dazu sollten normale Benutzer nicht voneinander isoliert sein müssen und sollten voneinander isoliert sein.

Aus diesem Grund wird seit einiger Zeit davon ausgegangen, dass es im Allgemeinen keine gute Idee ist, alles unter dem Administratorkonto auszuführen.

Ich arbeite in der Unterhaltungselektronik und die Sicherheit ist hier etwas anders als in der Serverumgebung. Hier müssen wir davon ausgehen, dass sich das Produkt in einer feindlichen Umgebung befindet. Aus Gründen der Abonnentenverwaltung werden die Schlüssel sicher aufbewahrt. Die erste Verteidigungslinie besteht darin, dass der SoC versteckte Register hat, auf die selbst das Betriebssystem nicht zugreifen kann. Sie werden zur Herstellungszeit eingebrannt und Chipsicherungen werden durchgebrannt, die den Zugriff verhindern. Außerdem sehen wir selbst keine Schlüssel, da dies in der Produktion unsicher wäre. Stattdessen werden sie mit einem Stapelschlüssel vorverpackt, den wir nicht kennen. Das wissen nur der Chiphersteller und die Person, die den Schlüssel erstellt hat (der Master) Schlüssel kann nach Verwendung im Chip zerstört werden). Sobald der Chip mit Geheimnissen geladen ist, kann er gesperrt und niemals * entsperrt werden.

Wenn Sie nicht auf die Schlüssel zugreifen können, wie entschlüsseln Sie dann etwas? Mit einem kryptografischen Co-Prozessor auf dem SoC können Sie Schlüsselpositionen laden, ohne den darin enthaltenen Wert zu kennen. Sie sehen auch nie den Mikrocode des Kryptoprozessors, weil Sie dann selbst zum Zeitpunkt der Herstellung nichts injizieren können.

Wenn Sie Schlüssel oder Zertifikate haben, die nicht in die großzügigen Chipregister passen, müssen Sie diese im RAM und / oder NVM speichern, jedoch aufgrund des Kryptoprozessors Sie müssen diese Werte nicht verfügbar machen. Der RAM oder NVM selbst kann vom Chip mit einem Schlüssel verschlüsselt werden, der nur ihm selbst bekannt ist.

Im Gegensatz zu Computern haben sichere eingebettete Systeme auch eine gewisse physische Sicherheit. RAM-Verbindungsspuren dürfen sich nicht auf der Oberfläche der Leiterplatte befinden ("vergrabene Durchkontaktierungen"). Dies liegt daran, dass Sie, wenn sich Elemente im RAM befinden, den Zugriff beschränken müssen, den Zugriff beschränken müssen. Es ist möglich, die CPU zu verlangsamen oder einzufrieren und dann den RAM zu prüfen.

Schließlich war es für Smartcards möglich, die Transaktionen zwischen dem SoC und der Karte abzufangen. Dies wird als "Kartenfreigabe" bezeichnet. Die Lösung hierfür besteht darin, die Transaktionen zwischen der Karte und dem SoC zu verschlüsseln und aneinander zu binden, damit sie nicht ausgetauscht oder freigegeben werden können.

Ich kenne diesen DRM / Inhaltssicherheit ist bei einigen Leuten in den Interwebs unbeliebt, aber ich dachte, ich würde einige hochrangige Konzepte aus einer Branche mit bestimmten Sicherheitsanforderungen teilen.

* Theoretisch.

Auf der Linux-Plattform wird einige Arbeit geleistet, um den Zugriff auf den Speicher eines laufenden Prozesses selbst durch einen Superuser zu verbieten. Mit SELinux können Sie dies ab Fedora 17 tun: SELinux Deny Ptrace.

Welche Sprache / Plattform verwenden Sie?

Wenn es sich um .NET handelt, überprüfen Sie das Steuerelement PasswordBox und die Klasse SecureString.

Die SecureString-Klasse bietet eine Möglichkeit, das Kennwort im Speicher zu speichern, ohne es für jedermann zugänglich zu machen - selbst für Hacker, die einen Blick in den Speicher Ihrer Anwendung werfen.

Das PasswordBox-Steuerelement ist ein Textfeld, das enthält den SecureString, sodass Sie das Kennwort von Ende zu Ende sicher aufbewahren können.

Nein, im Klartext im RAM gespeicherte Passwörter sollten nicht als sicher angesehen werden. Auf den x86- und x86-64-Architekturen mit Schnittstellen wie FireWire, ExpressCard und Thunderbolt, auf die direkt zugegriffen wird, können diese Schnittstellen im Allgemeinen verwendet werden, um den Speicherschutz des Betriebssystems zu umgehen und somit Klartextkennwörter aus dem Speicher abzurufen.

Die Verwendung von FireWire zum Abrufen von Klartextkennwörtern ist nicht nur ein theoretischer Angriff. Es wird jetzt Software verkauft, um Klartextkennwörter für BitLocker-, PGP- und TrueCrypt-verschlüsselte Festplatten zu erhalten. ElcomSoft entschlüsselt BitLocker-, PGP- und TrueCrypt-Container

Es gibt einen separaten Thread zu security.stackexchange, der darauf eingeht So verringern Sie DMA-Basisangriffe Deaktivieren Sie Firewire / Thunderbolt sicher und korrigieren Sie die DMA-Exposition unter Linux. Außerdem hat Microsoft einen Knowledge Base-Artikel zur Abschwächung von Angriffen über Firewire und Thunderbolt auf BitLocker Blockieren des SBP-2-Treibers und der Thunderbolt-Controller, um 1394 DMA- und Thunderbolt DMA-Bedrohungen für BitLocker zu reduzieren

Mehr Details zu diesem Angriff finden Sie auf Wikipedia DMA-Angriff.

Zusätzlich zu allen Software-Angriffen, bei denen Betriebssystem-Schwachstellen ausgenutzt werden, kann ein Angreifer, wenn er physischen Zugriff auf Ihren Computer hat, möglicherweise Ihre Schlüssel direkt aus Ihrem Speicher lesen.

Wie kann sich Kälte auswirken? Boot-Angriffe werden minimiert?

Sie werfen ein gültiges Problem auf, das in sicherheitsrelevanter Software häufig behoben wird. Wenn sensible Objekte wie Schlüssel nicht mehr benötigt werden, geben einige Programme den Speicher nicht einfach an die Speicherverwaltungsbibliothek oder das Betriebssystem zurück, sondern löschen zuerst die sensiblen Bits durch Überschreiben.

Natürlich einige Programme müssen die Tasten dauerhaft halten. Zum Beispiel ssh-agent . Diese Programme sind also anfällig. Wenn Sie ein einfacher Benutzer auf einem Mehrbenutzercomputer sind, ist der dynamische Speicher Ihres ssh-agent für jeden anfällig, der über Root-Rechte verfügt und einen beliebigen Teil des Arbeitsspeichers des Computers sehen kann. P. >

Und selbst Programme, die kurzzeitig Schlüssel verwenden, weisen immer noch ein Fenster der Verwundbarkeit auf. Eine Mikrosekunde kann eine Ewigkeit in der CPU-Zeit sein. Ein böswilliger Superuser kann das Programm bei einer Anweisung sogar auf unbestimmte Zeit anhalten, während dieses Programm vertrauliche Daten in Klartextform irgendwo im Speicher hat.

Führen Sie daher als Faustregel keine sicherheitsrelevanten Daten aus Computer auf dem Computer, wenn auf diesem Computer Benutzer oder Software vorhanden sind, denen Sie nicht vertrauen, und ein Betriebssystem, dem Sie nicht vertrauen, um zu verhindern, dass diese Benutzer oder Software ihre Berechtigungen so erweitern, dass sie auf Ihre Schlüssel oder Klartextdaten zugreifen können.

Wenn Sie einen sicheren Client verwenden, vertrauen Sie diesem Programm und der gesamten Plattform, auf der es ausgeführt wird, bis hin zur Hardware und allen Maschinenanweisungen in jedem Programm, das vorinstalliert wurde oder das Sie anschließend installiert haben.

(Das sogenannte "Trusted Computing" behebt dies nicht; es ändert nur, wer die Bösewichte sind.)

Selbst wenn die Schlüssel verschlüsselt sind, kann ein Cod-Boot-Angriff Ihr Passwort abrufen: Überprüfen Sie dieses Video des laufenden Kaltstart-Angriffs. http://www.youtube.com/watch?v=JDaicPIgn9U

Es besteht ein gewisses Maß an Vertrauen in die Sicherheit des Betriebssystems und der ausgeführten Anwendungen, es sei denn, Sie haben natürlich die Zeit, den gesamten Quellcode zu lesen und sicherzustellen, dass keine Exploits vorhanden sind. Wenn Sie diese Zeit hätten, wäre kein Vertrauen notwendig, würden Sie wissen. Das ist aber nicht wahrscheinlich. Wenn alles möglich ist, ist es am besten, proprietäre Projekte auf einem Computer auszuführen und alles, was vertrauenswürdig ist, auf einem anderen Computer laufen zu lassen. Die physische Trennung macht den Trick ziemlich gut im Vergleich zu glaubensbasierten Lösungen.

Eine etwas relevante Studie muss durchgeführt werden, um sicherzustellen, dass selbst der Superuser nicht auf ein Geheimnis zugreifen kann, das im Speicher eines anderen Prozesses gespeichert ist. Ich habe das Unterfangen nie wirklich beendet, es ist also nur ein Ausgangspunkt. Dies verhindert physische Angriffe wie Kaltstartangriffe nicht.

Geheimnisse vor Root unter Linux schützen

Dies löst Ihr Problem nicht, obwohl ein Trick, mit dem Sie die Zeit minimieren können, in der ein Passwort oder ein anderes Geheimnis im Speicher gespeichert wird, darin besteht, es anschließend auf Null zu setzen.

Verwenden Sie keine garantierte Methode Sie schreiben in denselben Speicher, anstatt ein neues Objekt mit einem anderen Wert zuzuweisen. In Java würden Sie beispielsweise ein Byte [] anstelle eines String verwenden, um ein Geheimnis zu bewahren.

Da dies für eine Reihe von Betriebssystemen mit unterschiedlichen Schutzstufen gelten kann, sollten Sie Folgendes beachten:

1. Unabhängig davon können Sie nicht verhindern, dass ein Kennwort vorhanden ist irgendwann in Erinnerung. Wenn jemand Live-Zugriff auf den Speicher Ihrer Anwendung hat, können Sie ihn nicht davon abhalten, ihn zu sehen.

2. Kennwörter sind im Allgemeinen wertvoller als nur das, was sie schützen - Benutzer verwenden Kennwörter wieder und Durch das Akzeptieren der Kennwortanmeldung übernehmen Sie eine gewisse Verantwortung für die Geheimhaltung des Kennworts, auch wenn die von ihm geschützten Daten kompromittiert sind. Sie können den Schaden eines Angriffs auf den kalten Speicher (flüssiger Stickstoff oder Ruhezustand) etwas abmildern, indem Sie das Kennwort Ihres Benutzers mit einer langsamen Hash-Funktion (PBKDF, scrypt, bcrypt) haschen und den Hash zur Authentifizierung verwenden.

3. Das Löschen des Benutzerpassworts aus dem Speicher ist eine gute Vorgehensweise. Es gibt viele Fallstricke, wenn Sie dies richtig machen. Stellen Sie daher sicher, dass Sie eine geeignete Bibliothek verwenden: Windows Linux-Beispiel

ol>