Frage:
Lesen des physischen Speicherrahmens, der zuvor einem anderen Prozess gehörte, um den Inhalt seiner Speicherseite zu lesen
KOLANICH
2016-01-13 17:50:45 UTC
view on stackexchange narkive permalink

Ich hatte ein Gespräch mit @ anger32, der angibt, dass das Nullstellen eines physischen Speicherseitenrahmens beim Übergeben der von diesem Rahmen gesicherten Seite an einen anderen Prozess nicht in der Verantwortung von Betriebssystemen wie Windows und Linux liegt (obwohl dies der Fall ist) Wenn Sie dies tun, garantieren sie nicht, dass dies geschieht. Sie sind jedoch für Betriebssysteme mit einem Zertifikat verantwortlich, das es ihnen ermöglicht, mit Verschlusssachen zu arbeiten.

Ist es möglich, den folgenden Angriff auf einen anderen auszuführen (möglicherweise mehr) privilegierter) Prozess?

  1. ordnet genügend Speicherseiten zu und verbraucht genügend CPU-Zeit, um zu verhindern, dass der Zeroing-Thread mit der niedrigsten Priorität (zumindest unter Windows) CPU-Zeit erhält.

  2. Ein anderer Prozess speichert vertrauliche Daten im Speicher.

  3. Kontextwechsel erfolgt

  4. Wir fragen das Betriebssystem nach einer Speicherseite. Das Betriebssystem entfernt diese Prozessseite und gibt uns die neue Seite, die von demselben Seitenrahmen unterstützt wird, ohne sie auf Null zu setzen.

  5. Wir scannen die Seite für Geheimnisse.

  6. ol>

    Er gibt auch an, dass es wa gibt Sie können den Speicher eines anderen Prozesses lesen, der mit mmap , seinen Flags und physischen Adressen unter Linux in Konflikt gerät. Kennst du welche? Ist es wirklich möglich, unter Linux den Speicher eines anderen Prozesses abzurufen, beispielsweise den Speicher des Prozesses eines anderen Benutzers oder einer SELinux-Domäne? Wenn ja, sieht es nach einer sehr gefährlichen Sicherheitslücke aus.

Ihre kleinen Änderungen bringen dies immer wieder an den Anfang der Startseite. Wenn Sie Änderungen vornehmen, würde ich Sie bitten, eine Reihe von Änderungen zusammen vorzunehmen, anstatt alle 30 Minuten eine.
Ich bezweifle sehr ernsthaft, dass Linux den Arbeitsspeicher nicht auf Null setzt, bevor es an einen neuen Prozess übergeben wird. Denn… wenn nicht… dann könnte ein nicht privilegierter Prozess möglicherweise vertrauliche Informationen lesen, die zu einem anderen Prozess gehören. Es sind nicht nur Betriebssysteme, die von einigen Unternehmen mit einem Gütesiegel ausgezeichnet wurden, die dafür verantwortlich sind, Prozesse voreinander zu schützen. ALLE Betriebssysteme sollten dies tun, und ich würde diejenigen, die dies nicht tun, als verrückt und für den allgemeinen Gebrauch ungeeignet betrachten.
War das nicht die Schwäche einer früheren Windows-Version?
"Das Betriebssystem ist nicht dafür verantwortlich, den Speicher eines Prozesses zu schützen." - Wenn er dies wirklich ohne "nach dem Beenden des Prozesses" angegeben hat, sollte er mit dem Erlernen der Sicherheitsgrundlagen beginnen. Wenn ein Betriebssystem dies nicht tut, kann jeder Benutzer einen beliebigen Code ausführen (oder Informationen lesen, um dies zu tun, falls er nur über Ro-Zugriff verfügt).
Nein, hat er nicht, sorry. Die Frage wurde behoben. Er meinte, die Speicherseiten nach Betriebssystem auf Null zu setzen.
Es ist durchaus plausibel, dass die Windows 9x-Reihe dies nicht getan hat, da sie nicht als sicher konzipiert wurde.
@BlacklightShining: Es als * verrückt * zu bezeichnen ist ein bisschen stark, viele eingebettete Betriebssysteme sind kaum mehr als das Ausführen von Bibliotheken und tun so etwas nicht. Die Bereinigung des freigegebenen Speichers vor der Wiederverwendung ist für jedes * Mehrbenutzer * -Betriebssystem mit Sicherheit erforderlich. Wenn Sie im Allgemeinen auf Mehrbenutzersystemen arbeiten, stimme ich zu, dass Betriebssysteme ohne diese Funktion * nicht für den allgemeinen Gebrauch geeignet * sind, aber es kann durchaus sinnvoll sein, eines in speziellen Fällen zu verwenden, in denen es nicht möglich ist, beliebigen Code zu laden, der etwas Schädliches bewirken könnte die restlichen Daten.
Der GPU-Speicher wird nicht zuverlässig auf Null gesetzt (zumindest unter einigen Betriebssystemen), und die GPU-Anbieter scheinen nicht bereit zu sein, dies in ihren Treibern zu beheben, obwohl sie jahrelang über diese Sicherheitslücke Bescheid wissen.
(Die nächste Person, die eine wesentliche Änderung vornimmt, entfernt bitte das Tag 'Sandbox' und erwägt auch, das Tag 'Zugriffskontrolle' zu entfernen und relevante Betriebssystem- / Speicher-Tags hinzuzufügen. Tun Sie dies vorerst nicht, um die folgende Frage nicht erneut zu beantworten Mikes Kommentar)
Verwandte https://charliehorse55.wordpress.com/2016/01/09/how-nvidia-breaks-chrome-incognito/
* "Sie garantieren nicht, dass dies passieren wird *" - Zitieren / Beweise erforderlich. Diese Prämisse scheint fehlerhaft. Ihre Frage * sollte * lauten: Garantieren sie, dass der Speicher auf Null gesetzt wird, bevor er von einem anderen Prozess wiederverwendet wird? Gehen Sie nicht davon aus, dass dies nicht garantiert ist (es sei denn, Sie haben gegenteilige Beweise).
@Sebb Um fair zu sein, liegt es nicht unbedingt in der Verantwortung, den Prozessspeicher zu schützen, insbesondere auf Systemen ohne MMU.Es reicht oft aus, den Kernel einfach vor dem Userspace zu schützen, selbst wenn ein Userspace-Prozess mit einem anderen Userspace-Prozess in Konflikt geraten kann.
Sieben antworten:
Dog eat cat world
2016-01-13 18:45:45 UTC
view on stackexchange narkive permalink

Ich war selbst einmal neugierig darauf und habe unter Linux ein kleines Programm geschrieben, das den gesamten verfügbaren Speicher malloc'ed und auf die Festplatte kopierte.

Es stellte sich heraus, dass alles auf Null gesetzt wurde, bevor es war übergeben an meine Bewerbung.

Später überprüfte ich auch den Kernel-Code und konnte bestätigen, dass es der Kernel war, der dies tat.

-

Ich denke Es ist durchaus sinnvoll, dass es in der Verantwortung des Betriebssystems liegt, sicherzustellen, dass alte Daten nicht einem anderen Prozess zur Verfügung gestellt werden. Wo sonst würden Sie eine solche Sicherheitsmaßnahme implementieren?

Bearbeiten:

Ich erinnere mich nicht, ob ich gegen SWAP-Speicher getestet habe. Aufgrund der Festplatten-E / A, die erforderlich ist, um den zugewiesenen Speicherplatz (Speicher) auf Null zu setzen, wird sie möglicherweise anders implementiert.

"Wo sonst würden Sie eine solche Sicherheitsmaßnahme implementieren?" Sie könnte durch einen Prozess vor dem Beenden implementiert werden, bei dem der Speicher für vertrauliche Daten auf Null gesetzt wird. Aber es ist definitiv am sinnvollsten für das Betriebssystem, damit umzugehen.
Wenn ein Kontextwechsel auftritt, kann der Prozess den Speicher vor dem Wechsel nicht auf Null setzen. Manuelles Nullstellen wird durchgeführt, um zu verhindern, dass Daten verloren gehen, wenn jemand, der außerhalb der Grenzen ausgenutzt wurde, vuln liest. Aber es kann [nicht genug] sein (http://www.daemonology.net/blog/2014-09-06-zeroing-buffers-is-insufficient.html).
Gibt es einen Hinweis, ob dies auch unter Windows oder einem anderen Betriebssystem zutrifft? Die Tatsache, dass Linux dies tut, bedeutet nicht, dass es in der Verantwortung des Betriebssystems liegt. Es könnte nur eine nette zusätzliche Funktion von Linux sein
Wie ich weiß, funktioniert Windows (http://blogs.msdn.com/b/tims/archive/2010/10/29/pdc10-mysteries-of-windows-memory-management-revealed-part-two.aspx) ).
P.S. Laut dem verlinkten Beitrag hat Windows, wenn ich es richtig verstanden habe, wirklich keine Verantwortung, nullte Seiten zu geben.
@KOLANICH Wenn ich das richtig lese (Flussdiagramm und nächster Absatz), werden auf jeder Seite, die an eine Benutzeranwendung gesendet wird, alte Daten überschrieben. Der Kernel kann sie möglicherweise sehen. Freie, aber schmutzige Seiten können entweder auf Null gesetzt und für normale Zuordnungen verfügbar gemacht werden, für Speicherzuordnungsdateien verwendet werden (in diesem Fall werden die alten Daten von der Datei überschrieben, bevor sie an die Anwendung übergeben werden) oder für Zuweisungen vom Kernel verwendet werden. Was im letzteren Fall passiert, wird nicht besprochen: Möglicherweise bereinigt der Kernel sie selbst. Es ist auch möglich, dass Code auf Kernel-Ebene implizit vertrauenswürdig ist (ich hoffe, dass dies nicht der Fall ist).
Die physischen Seiten werden nicht auf Null gesetzt, sondern der angezeigte Speicher wird einer Seite auf Null zugeordnet. Die Seiten enthalten wahrscheinlich alle ihre Daten, bis sie festgeschrieben werden. Dies geschieht beim ersten Schreiben, sofern sie nicht ausdrücklich festgeschrieben werden.
@DanNeely: Sie hoffen, dass der Code auf Kernelebene nicht implizit vertrauenswürdig ist? Nun ... ich denke, das könnte man so sagen, denn in Wirklichkeit ist es ** ausdrücklich vertrauenswürdig **. Kernel-Code hat uneingeschränkten Zugriff auf das gesamte System. Es müssen keine Daten aus nicht bereinigten Zuordnungen ausgewählt werden, da es jede gewünschte Seite direkt durchsuchen oder sogar ändern kann (als direkte Folge der Fähigkeit von Ring 0, Seitentabellen neu zu konfigurieren).
@BenVoigt Implementierungen von TEEs wie SGX können dies weniger wahr machen.
Lie Ryan
2016-01-13 18:37:09 UTC
view on stackexchange narkive permalink

Unter Linux können Prozesse einen anderen Prozessspeicher lesen, wenn eine der folgenden Bedingungen erfüllt ist:

  1. Der Prozess hatte Root-Berechtigung oder er kann / proc / $ PID / lesen. mem oder / dev / mem sind standardmäßig nur für / proc / $ PID / mem und / dev / mem zugänglich root
  2. Der übergeordnete Prozess kann fork () / clone () so, dass er einen Teil oder den gesamten Speicher seiner untergeordneten Prozesse
  3. Ein übergeordneter Prozess kann ein untergeordnetes Element so aufteilen, dass der untergeordnete Prozess einen Teil oder den gesamten Speicher des übergeordneten Speichers lesen kann.
  4. Ein Prozess kann einen gemeinsam genutzten Speicherbereich einrichten.
  5. Ein Prozess kann nicht in den Speicher eines beliebigen, nicht verwandten Prozesses lesen oder schreiben, es sei denn, der Prozess wird mit erhöhten Rechten ausgeführt. In allen anderen Fällen müssten Sie entweder der übergeordnete Prozess sein oder der Zielprozess musste absichtlich den gemeinsam genutzten Speicherbereich einrichten.

    Dieser übergeordnete Prozess kann auf einen untergeordneten Prozessspeicher zugreifen. Dies ist das bestimmende Merkmal der meisten Unix-Systeme. In Unix-Systemen (einschließlich Linux) werden neue Prozesse mithilfe des Systemaufrufs fork () erstellt. fork () erstellt eine Kopie des vorhandenen Prozesses, indem ein neuer Eintrag in der Betriebssystem-Prozesstabelle erstellt wird, und richtet den neuen virtuellen Prozessspeicher als Kopie beim Schreiben des virtuellen Speichers des übergeordneten Prozesses ein. Dies bedeutet, dass der neue Prozess den Speicher des übergeordneten Elements lesen kann. Zu diesem Zeitpunkt führt der neue Prozess jedoch noch den Code des übergeordneten Elements aus, sodass dies kein Sicherheitsproblem darstellt. Der neue Prozess kann dann einen der Systemaufrufe exec * () aufrufen, um eine neue ausführbare Datei in ihren eigenen Speicher zuzuordnen und zum Startsymbol dieser ausführbaren Datei zu springen. Die Neuzuordnung bedeutet, dass jetzt der einzige Eintrag in der Auslagetabelle im neuen virtuellen Prozessspeicher die neue ausführbare Datei ist. Wenn der neue Prozess versucht, in den neu zugeordneten Bereich zu lesen / schreiben, verursacht dies einen Seitenfehler, und das Betriebssystem paginiert den entsprechenden Teil der ausführbaren Datei, der exec * () in den Speicher geschrieben wurde. Wenn der neue Prozess versucht, in einen nicht zugeordneten Speicherbereich zu lesen / schreiben, führt dies zu einem Segmentierungsfehler. Bei fortgeschritteneren Verwendungen von Fork und Exec kann ein Prozess den untergeordneten Prozessspeicher so verzweigen und dann zuordnen, dass der übergeordnete Speicher des Kindes nach exec * () ganz oder teilweise darauf zugreifen kann

    Wenn unter Linux ein Prozess Speicher (z. B. mit malloc) vom Betriebssystem zuweist, ruft der Prozess mmap () auf, um eine anonyme Zuordnung zuzuweisen. Anonyme Karte wird entweder aus dem RAM oder Swap bereitgestellt. Anonyme mmap wird vom Kernel mit Null gefüllt, es sei denn, der angeforderte Prozess MAP_UNINITIALIZED , der aus Leistungsgründen nur auf sehr eingeschränkten eingebetteten Systemen berücksichtigt wird, musste der Kernel kompiliert werden, um dies zu ermöglichen dies.

    Für Hochsicherheitsszenarien ermöglicht Linux außerdem, dass ein Prozess mithilfe von mlock und / oder MAP_LOCKED anfordert, dass der gesamte oder ein Teil seines Speichers nicht ausgetauscht werden kann. Gesperrter Speicher wird immer aus dem RAM bereitgestellt und normalerweise verwendet, um zu verhindern, dass Verschlüsselungsschlüssel und Speicher, die für die Entschlüsselung verwendet werden, in einen dauerhaften Speicher übertragen werden.

Alles nette Informationen, aber nicht relevant für die Frage, ob eine Race Condition Task die Page Zeroing Task ** implizite ** Datenübertragung zwischen Prozessen ermöglicht. Sie diskutieren die ** expliziten ** Übertragungen, für die ebenfalls eine explizite Sicherung vorgesehen ist. Das Sichern unerwarteter Kanäle ist natürlich viel schwieriger.
@BenVoigt: Die Frage basiert auf der impliziten Annahme, dass der Speicher auf Null gesetzt werden muss, wenn sie ein- und ausgelagert werden. Was passiert, ist etwas komplizierter. Bei dieser Speicherzuweisung handelt es sich eigentlich nur um eine Seitentabelle und eine vmm-Operation. Das tatsächliche Laden des zugeordneten Speichers mit zugeordneten Daten oder das Nullstellen erfolgt während eines Seitenfehlers. Während eines Seitenfehlers befindet sich der Prozess / Thread / die Aufgabe in einem nicht ausführbaren Zustand. Sie wird nicht geplant, sodass keine Parallelitätsfehler auftreten können. In der ersten Hälfte meiner Antwort wird versucht, dieses Missverständnis zu beheben, indem erklärt wird, wie der virtuelle Speicher in modernen Betriebssystemen funktioniert.
@BenVoigt: Der vorletzte Absatz befasst sich mit der eigentlichen Frage. Gemäß der Kerneldokumentation wird garantiert, dass alle anonymen Speicher erstellt werden, wenn der Benutzerprozess sie direkt nach dem Mapping liest. Die eigentliche Nullung erfolgt nicht bei Ausführung des neuen Prozesses, sondern bei Speicherlesevorgängen / Seitenfehlern.
Ben Voigt
2016-01-14 04:26:03 UTC
view on stackexchange narkive permalink

Der von Ihnen beschriebene Angriff funktioniert unter Windows nicht. Das Verhungern des Threads zum Nullstellen der Seite verhindert nicht das Nullstellen, sondern verzögert es nur. Das Vorhandensein der Hintergrundaufgabe zum Nullstellen der Seite ist eine Leistungsoptimierung.

Grundsätzlich funktioniert ein naiver Speichermanager mit Datenschutzgarantie folgendermaßen:

  • Reservieren Sie eine Seite aus dem Freigegebene Liste
  • nullt es
  • stellt sie dem Anwendungscode zur Verfügung (setzt den Seitentabelleneintrag so, dass der Zugriff auf Ring 3 möglich ist)

Die optimierte Version sieht aus eher wie:

  • eine Seite aus der Liste mit den Nullwerten abrufen. Wenn es eine gibt
  • Wenn der erste Schritt erfolgreich war, fahren Sie mit dem letzten Schritt fort.
  • reservieren Sie a Seite aus der freigegebenen Liste
  • Null es
  • für den Anwendungscode verfügbar machen (Seitentabelleneintrag festlegen, um den Zugriff auf Ring 3 zu ermöglichen)

Verhungern Der Nullungsthread führt zu einer langsamen Zuordnung, da die Nullung noch nicht durchgeführt wurde. Dies führt nicht zu Datenverlusten, da die Datenstruktur auf Null gesetzt und übrig gebliebene Seiten getrennt bleiben. Wenn dem Allokator die vorab auf Null gesetzten Seiten ausgehen, muss das Nullstellen just-in-time durchgeführt werden.

davidb
2016-01-13 17:59:22 UTC
view on stackexchange narkive permalink

Es ist absolut möglich, den Speicher eines anderen Prozesses zu lesen, aber dies ist nur mit Administratorrechten möglich , und natürlich lässt das Betriebssystem keinen Prozess auf einen zugreifen Speicherplatz des Speichers, der diesem Prozess nicht zugewiesen ist.

Für administrative Benutzer ist dies natürlich möglich. In Windows ist diese Funktionalität beispielsweise standardmäßig implementiert, um einen Prozess zu debuggen. Sie können dies mit dem Task-Manager tun, wie hier beschrieben.

Es ist jedoch auch möglich, den gesamten Speicher einschließlich aller Prozesse und alles, was zu diesem Zeitpunkt im Speicher gespeichert ist, zu sichern. Dies ist nicht mehr so ​​einfach, da Windows-Systeme diese Funktionalität standardmäßig nicht mehr bereitstellen. Zu diesem Zweck lädt die Anwendung ihre eigenen Speichertreiber, mit denen sie direkt und nicht über das Betriebssystem auf den Speicher zugreifen können.

Auf älteren Linux-Systemen können wir den Speicher direkt über das Speichergerät im / dev Partition. Dies ist nicht mehr möglich, aber es gibt Kernelmodule, mit denen man auch den gesamten Speicher sichern kann. Dies erfordert auch Root-Rechte. Sie können dies auch manuell für einen Prozess tun, wie hier beschrieben.

// BEARBEITEN : Ich habe gerade einen leitenden Entwickler mit 40 Jahren Erfahrung gefragt Dies. Die Antwort lautet: Es beruht auf verschiedenen Faktoren. Er sagte mir, dass die Variablen in C ++ und Java initialisiert werden, was bedeutet, dass eine Anwendung, die in C ++ oder Java geschrieben wurde, die alten Informationen nicht erhalten kann, da sie durch Initialisieren dieser Variablen überschrieben werden. Aber C tut dies nicht, dann ist es möglicherweise möglich, aber dann hängt es immer noch vom Betriebssystem ab.

Dies erfordert Root-Berechtigungen. Ich meinte unprivelegierten Code, der gleich oder mehr privilegierte gehackt hat. Zum Beispiel der Angriff auf folgende Weise: Wir führen einen eigenen Prozess aus, der Privilegierte speichert die Daten im Speicher, der Kontextwechsel erfolgt, wir fragen nach einer Seite, das Betriebssystem entfernt die Speicherseite des Privilegierten Prozesses und gibt uns eine Seite, die darauf gesichert ist Seitenrahmen ohne Nullstellen (der Mann besteht darauf, dass das Nullstellen nicht in der Verantwortung liegt), und wir können ihn nach Geheimnissen durchsuchen.
Siehe Bearbeiten ... Ich habe gerade einen erfahrenen Kollegen gefragt ...
Der erfahrene Mitarbeiter irrt sich in Bezug auf C ++ - Sie können von C ++ aus auf nicht initialisierten Speicher zugreifen, obwohl es selten einen guten Grund dafür gibt.
Simon Richter
2016-01-14 04:37:06 UTC
view on stackexchange narkive permalink

Technisch gesehen könnte ein Betriebssystem Seiten von Prozessen recyceln, die denselben Sicherheitskontext haben, da alle Informationen, die der neue Prozess daraus sammeln könnte, auch direkt für den Prozess zugänglich wären.

Dies ist jedoch vollständig Dies ist unpraktisch, da sich der Sicherheitskontext eines Prozesses im Laufe der Zeit ändern kann. Wenn Berechtigungen gelöscht werden (was ein gängiges Muster ist), müssen die im Prozess enthaltenen Daten weiterhin vor Personen geschützt werden, die weniger Zugriffsberechtigungen als der ursprüngliche Berechtigungssatz haben.

Angesichts der Tatsache, dass Berechtigungen auch sehr detailliert sein können, ist der Aufwand, zu verfolgen, welchen Prozessen eine Seite unterzogen werden kann, ohne sie zuvor zu bereinigen, erheblich höher als das einfache Löschen jeder an das Betriebssystem zurückgegebenen Seite. Insbesondere, da die Computerspeicherarchitektur große sequentielle Schreibvorgänge stark bevorzugt.

Einige eingebettete Architekturen verwenden für diese Aufgabe auch den DMA-Controller, wodurch die CPU-Zeit zum Einrichten des Controllers und auf einige Zyklen reduziert wird Bestätigen Sie den Abschluss.

Ob ein Prozess davon ausgehen kann, dass frisch zugeordnete Seiten gelöscht werden, ist ein Vertrag zwischen ihm und dem Betriebssystem. Dies wird jedoch normalerweise nicht angenommen, und es gibt normalerweise wenig Grund, dies zu tun, da Prozesse müssen weiterhin verfolgen, welche Daten in ihrem Adressraum sie für gültig halten, und dies nur für alles, was wirklich Informationen enthält.

Wenn eine Aufgabe Seiten schnell zuordnet, ändert und die Zuordnung aufhebt, wird dies der Fall sein Wenn Sie die Systemlast erhöhen, werden Prozesse möglicherweise angehalten, während Sie darauf warten, dass ein Prozess mit niedriger Priorität eine Seite löscht. Betriebssysteme müssen darauf achten, dass hier nicht versehentlich eine Prioritätsinversion eingeführt wird, indem die Priorität der Nullstellungsaufgabe vorübergehend auf die der Aufgabe mit der höchsten Priorität erhöht wird, die versucht, eine Seite zuzuordnen.

Man muss sich nie mit der Priorität des Hintergrund-Zeroing-Threads herumschlagen, da es durchaus möglich ist, das Zeroing im aktiven Kontext als Fallback durchzuführen.
@BenVoigt, Je nach Einrichtung Ihres Betriebssystems ist die Implementierung möglicherweise aufwändiger, insbesondere wenn Sie bereits über Code für die Prioritätsinversion in Sperren verfügen.
billc.cn
2016-01-15 23:57:36 UTC
view on stackexchange narkive permalink

Die meisten Betriebssysteme müssen zertifiziert sein, um für bestimmte Zwecke / in bestimmten Organisationen verwendet zu werden. Die meisten von ihnen verwenden das Framework Common Criteria für verschiedene Sicherheitsstufen. Bei einigen Stufen muss das Betriebssystem eine Seite löschen, bevor sie an einen anderen Prozess übergeben wird. Ein indirekter Verweis auf diese Anforderung, in dem Folgendes angegeben ist:

Ein Grund, warum Seiten mit Nullinitialisierung erforderlich sind, besteht darin, verschiedene Sicherheitsanforderungen zu erfüllen, z. B. die allgemeinen Kriterien. Die meisten Common Criteria-Profile geben an, dass Prozesse im Benutzermodus initialisierte Seitenrahmen erhalten müssen, um zu verhindern, dass sie den Speicherinhalt eines vorherigen Prozesses lesen. Daher gibt der Speichermanager Seitenrahmen im Benutzermodus auf Null, es sei denn, die Seite wird aus einem Sicherungsspeicher eingelesen. In diesem Fall bevorzugt der Speichermanager die Verwendung von Seitenrahmen ungleich Null und initialisiert diese mit den Daten von der Festplatte oder vom Remotespeicher.

(von Windows Internals, Teil 2, 6. Ausgabe. Von Mark E. Russinovich, David A. Solomon, Alex Ionescu. Copyright © 2012 David Solomon und Mark Russinovich)

Um eine solche Funktion zu aktivieren, muss die Speicherverwaltungsarchitektur meistens entsprechend gestaltet werden, und dies ist nicht sinnvoll Um diese Funktion in einer "zivilen" / unsicheren Version für nicht offensichtliche Leistungssteigerungen auszuschließen.

Insbesondere ist es wichtig, dass Kernelseiten und Seiten anderer Benutzer nicht an nicht privilegierte Prozesse weitergegeben werden irgendwann geklärt. Es ist auch ineffizient, eine Seite auf Null zu setzen, es sei denn, sie überschreitet tatsächlich die Grenzen (falls eine Seite wieder demselben Prozess / Kernel zugewiesen wird). Der einzig sinnvolle Zeitpunkt dafür ist der Zeitpunkt der Zuweisung. Da dem Empfänger nicht vertraut werden kann, muss das Betriebssystem die Verantwortung dafür tragen. (Natürlich wird das Betriebssystem der realen Welt alle Arten von Optimierungen vornehmen, um die Verzögerung der Seitenzuweisung zu verringern.)

Alexey Vesnin
2016-01-13 22:28:05 UTC
view on stackexchange narkive permalink

Die einzige Möglichkeit, das auszuführen, wovon Sie sprechen, ist ein Kaltstartangriff , wenn Sie den Kernel durch Ausschalten zerstören. ODER Sie können versuchen, mit kexec () -Aufrufen zu spielen, dies funktioniert jedoch in den meisten Fällen nicht.

Bei dieser Frage geht es nicht um Kaltstart. Ein Kaltstartangriff ist der letzte Ausweg und erfordert die Kontrolle über die Hardware, nicht nur über einen einzelnen unprivelegierten Prozess. Könnten Sie etwas über `` `kexec``` klarstellen, wenn Sie damit spielen können, um Zugriff auf den Speicher zu erhalten, auf den Sie keinen Zugriff haben dürfen, handelt es sich um eine eindeutige Sicherheitslücke?
@KOLANICH werfen Sie einen Blick auf einige praktische Beispiele [hier] (https://www.linux.com/community/blogs/129-servers/413862)
Ich sehe hier keine vuln, da kexec Root-Rechte erfordert.
@KOLANICH ist keine Vuln von nicht privilegierten Benutzern - der Speicher wird vom Kernel mit Null gefüllt


Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
Loading...