SecureZeroMemory vermisst

[himitsu]

Bin ich nur blind, oder warum kann ich diese Prozedur nicht finden?

Delphi-Quellcode:

Procedure SecureZeroMemory(Destination: Pointer; Length: LongInt); StdCall;
  External '???' Name 'RtlSecureZeroMemory';

da soll sie ja angeblich sein (vermutlich ntdll.dll, oder eventuell auch kernel32.dll / user32.dll),
aber nichts ... nirgends ... im gesamten WinXP nicht :shock:

http://msdn.microsoft.com/library/de...zeromemory.asp

[Olli]

http://www.osronline.com/DDKx/kmarch/k109_4nci.htm
http://jedi-apilib.sourceforge.net/native

[himitsu]

Die OSR-Seite kannte ich schon ... dat is ja eine der weingen Seiten, die Goole liefert, allerdings wäre diese wohl besser http://www.osronline.com/DDKx/kmarch/k109_3bqq.htm , denn ich suche nicht das "normale" ZeroMemory, sondern eben das "Sichere" und genau dieses ist nicht zufinden.
Selbst in den JEDI's ist es nicht drin, bis auf so'nen TODO Eintrag.

[Frickeldrecktuxer_TM]

Zitat:

Zitat von himitsu

Die OSR-Seite kannte ich schon ... dat is ja eine der weingen Seiten, die Goole liefert, allerdings wäre diese wohl besser http://www.osronline.com/DDKx/kmarch/k109_3bqq.htm

Wenn du sie kanntest, warum hast du sie dann nicht gelesen?

Zitat:

This routine is available on Windows Server 2003 and later. (Because the routine is declared inline, the body of the routine can be included in earlier versions of the operating system.)

Steht so auch im MSDN.

http://www.gcdev.com/ntddk.h:

Zitat:

Code:

FORCEINLINE
PVOID
RtlSecureZeroMemory(
    IN PVOID ptr, 
    IN SIZE_T cnt
    ) 
{
    volatile char *vptr = (volatile char *)ptr;
    while (cnt) {
        *vptr = 0;
        vptr++;
        cnt--;
    }
    return ptr;
}

Frag mich nicht, ob das der Original-Header von Microsoft ist (laut Copyright ist er es) oder warum eine Gamecube-Seite Header aus dem DDK veröffentlicht, aber so schwierig ist es auch nicht, die Funktion selber in Delphi zu implementieren, schließlich macht sie auch nicht mehr als ZeroMemory()

[himitsu]

Gut, dann wa ich wohl irgendwie blid :wall:

aber wie bekomm ich jetzt das

FORCEINLINE und volatile nach Delphi?

Code:

FORCEINLINE
PVOID
RtlSecureZeroMemory(
    IN PVOID ptr, 
    IN SIZE_T cnt
    ) 
{
    [b]volatile[/b] char *vptr = ([b]volatile[/b] char *)ptr;
    while (cnt) {
        *vptr = 0;
        vptr++;
        cnt--;
    }
    return ptr;
}

Der Rest ist leicht ... beziehungsweise ich hab da auch 'ne ASM-Version :roll:

[edit]
OK, FORCEINLINE ist wohl sows wie INLINE in Delphi, also erstmal egal.

[Frickeldrecktuxer_TM]

Zitat:

Zitat von himitsu

FORCEINLINE

Gar nicht. Inlining ist beim DCC meines Wissens nach nach wie vor nur eine Empfehlung.

Zitat:

Zitat von himitsu

volatile

Optimierung des Compilers lokal ausschalten. WIMRE {$O-} und {$o+}. Ansonsten den Compiler sonstwie dazu überreden, die Variable nicht wegzuoptimieren. Da Optimierung immer implementationsabhängig ist, musst du schauen, wie du deinen Compiler dazu überreden kannst, die Variable nicht wegzuoptimieren. Die nächste Version des gleichen Compilers kann sich da schon wieder vollkommen anders verhalten, wenn sie will.
Zweite Alternative: Soweit ich weiß kann der Delphi-Linker auch C-Objects einbinden. Wie das genau geht, weiß ich nicht, aber du könntest die Funktion in C schreiben, in eine lib kompilieren und sie irgendwie dem DCC unterjubeln.

[himitsu]

Asoooooo :shock:
hatte das im MSDN so verstanden, daß Windows dazu veranlasst wird es nicht zu optimieren, also z.B. den Speicher nich in irgend 'ner Cache zu lassen, sondern den Speicherbereich wirklich zu überschreiben ... na dann isses ja "sinnlos" dieses nach Delphi zu holen, weil wenn man ZeroMemory als DelphiFunktion aufruft, dann wird diese Funktion ja vom Compiler nicht wegoptimiert -.-''

Da such ich jetzt seit letzter Woche danach und dann sowas ... blödes C++ :roll:

In Delphi gibt's ja kein INLINE mehr, also wird die Funktion nicht integriert und deren Inhalt kann demnach nicht wegoptimiert werden.

[Olli]

Zitat:

Zitat von himitsu

Selbst in den JEDI's ist es nicht drin, bis auf so'nen TODO Eintrag.

Tja, könnte es vielleicht eine Bedeutung gehabt haben, daß ich dir genau diese Seite verlinkt habe? Ja! Ich wollte dir nämlich zeigen, daß es sich um ein Makro oder eine Inline-Funktion handeln muß. Um die riesige HTML-Seite nicht direkt zu verlinken, habe ich dir nur den Einstieg zu ihr geliefert. Wenn du in der dortigen Liste RtlSecureZeroMemory suchst, wirst du es nämlich garnicht finden, was wie bei einigen anderen "Funktionen" darauf hinweist, daß sie nicht in den entsprechenden DLLs sondern direkt (z.B. über Makros) implementiert sind.

[Frickeldrecktuxer_TM]

Zitat:

Zitat von himitsu

hatte das im MSDN so verstanden, daß Windows dazu veranlasst wird es nicht zu optimieren, also z.B. den Speicher nich in irgend 'ner Cache zu lassen, sondern den Speicherbereich wirklich zu überschreiben ...

Nö, wie denn? Windows kann in deinem Code nicht optimieren. Und wenn dein Code eine I/O-Operation ausführt, wird garantiert, daß diese auch stattfindet, es sei denn die entsprechende Operation gibt einen entsprechenden Fehler zurück. Aber grundsätzlich gilt: Wenn eine Operation fehlerfrei abläuft, ist sie auch fehlerfrei abgelaufen.
ZeroMemory() und SecureZeroMemory() sind aber inline-Funktionen, das heißt ein C-Compiler würde den Code direkt aus dem Header einfügen und danach den Optimizer drüberlaufen lassen. Unter umständen sieht er dann, daß Variablen Werte zu gewiesen werden, die später nicht mehr benutzt werden und könnte dadurch ein ZeroMemory() komplett wegoptimieren. Durch die volatile-Anweisung in SecureZeroMemory() wird einem C-Compiler nun gesagt, daß die verwendete Variable "flüchtig" ist, also sich willkürlich auch mal ändern kann, auch wenn der Compiler das vom restlichen Code nicht unbedingt als richtig empfindet. Für den Optimizer bedeutet das dann, daß er die Variable nicht anfassen darf, weil ihr Verhalten vom Programmierer als unvorhersehbar gekennzeichnet ist, also kann auch der Optimizer nicht vorhersehen, wie sich die Variable verhalten wird. Das ist der ganze Trick hinter SecureZeroMemory(). Caches haben damit nichts zu tun. Wenn der Speicherbereich im Cache des Prozessors ist, muss er im RAM und im Cache geändert werden (Write-Through) oder wird nur im Cache geändert und bei Gelegenheit auch im RAM (Write-Back). Die Architektur stellt dabei bereits sicher, daß nicht zwei verschiedene Informationen benutzt werden (z.B. der DMA-Controller, der aus dem RAM liest, während die Seite zuvor im Prozessor-Cache geschrieben wurde). Interessant sit das auch bei Mehrprozessorsystemen.

Zitat:

Zitat von himitsu

In Delphi gibt's ja kein INLINE mehr, also wird die Funktion nicht integriert und deren Inhalt kann demnach nicht wegoptimiert werden.

Ich dachte Delphi2006 hat das inline-Schlüsselwort wieder eingeführt?

[Dax]

Zitat:

Zitat von Frickeldrecktuxer_TM

Ich dachte Delphi2006 hat das inline-Schlüsselwort wieder eingeführt?

Das hat Delphi 2005 schon getan :)

[Frickeldrecktuxer_TM]

Zitat:

Zitat von Dax

Zitat:

Zitat von Frickeldrecktuxer_TM

Ich dachte Delphi2006 hat das inline-Schlüsselwort wieder eingeführt?

Das hat Delphi 2005 schon getan :)

Na, um so besser.

Zitat:

Zitat von Olli

könnte es vielleicht eine Bedeutung gehabt haben, daß ich

Deine Beiträge werden doch von niemandem mehr ernstgenommen :mrgreen:

[himitsu]

Welcher "nicht-C-ler" soll den sowas ahnen ... in Pascal/Basic/CCBasic/ASM... gib's sowas doch nicht -.-''

Und ja ... gefunden hatte ich es nicht.
Es gibt ja och nicht gerade viel dazu zu finden ... selbst Google spuckt nur eine mickrige Seite aus :shock:

INLINE: ohhh, es ist wieder da :shock: ... arbeite doch mit D7 und dann eventuell wieder mit D2008 :zwinker:

Frickeldrecktuxer_TM: nicht den Code ... wenn es 'ne WinAPI-Funktion gewesen wär, dann hätte Windows das SpeicherManagement optimieren können ;)

[Frickeldrecktuxer_TM]

Zitat:

Zitat von himitsu

Welcher "nicht-C-ler" soll den sowas ahnen ... in Pascal/Basic/CCBasic/ASM... gib's sowas doch nicht -.-''

Deswegen empfiehlt es sich, bei systemnaher Programmierung auch die Sprache zu beherrschen, in der das System entwickelt wurde. Wenn ich an meinem Auto rumschrauben will, reicht es mir auch nicht, wenn ich weiß, wie ich meinen Fahrradreifen flicke und die Kette wieder einspanne.

Zitat:

Zitat von himitsu

Frickeldrecktuxer_TM: nicht den Code ... wenn es 'ne WinAPI-Funktion gewesen wär, dann hätte Windows das SpeicherManagement optimieren können ;)

Da gibt es diesbezüglich nichts zu optimieren. Die Prozessorcaches sind nicht beeinflussbar, und ein Caching von RAM innerhalb des RAM ist irgendwie... nicht sinnvoll.

[himitsu]

Na etwas C kann ich och, so isses ja nicht ;)

Aber vom Namen und der "groben" Beschreibung her sah es halt so aus, als wenn man damit "sicherstellen" kann, daß die Daten wirklich im Speicher überschrieben werden und somit wirklich weg sind ... tja, aus der Traum :cry:

[Frickeldrecktuxer_TM]

Zitat:

Zitat von himitsu

als wenn man damit "sicherstellen" kann, daß die Daten wirklich im Speicher überschrieben werden und somit wirklich weg sind...

Genau das ist doch auch der Fall.

[himitsu]

Eben nicht, denn wenn ich jetzt die ganzen Erklärungen zusammenfasse, dann wird nur sichergestellt, das der Code nicht wegoptimiert und somit ausgeführt wird, aber da die Cache nicht beeinflußt wird, wird eben nicht sichergestellt, daß der Inhalt auch aus dem Ram raus ist.

Wenn man z.B. etwas damit löscht und danach den Speicherblock freigibt, dann kann es eben vorkommen, das im RAM, oder der PageFile was zurück bleibt.

Zumindestens kenn ich jetzt 'nen Trick, wie man zumindestens verhindert, das Speicher immer im RAM bleibt und nicht in die PageFile ausgelagert wird ... zumindestens das werd' ich erstmal implementieren ... ein Sicherheitsloch weniger :stupid:

[Frickeldrecktuxer_TM]

Zitat:

Zitat von himitsu

Eben nicht, denn wenn ich jetzt die ganzen Erklärungen zusammenfasse, dann wird nur sichergestellt, das der Code nicht wegoptimiert und somit ausgeführt wird, aber da die Cache nicht beeinflußt wird, wird eben nicht sichergestellt, daß der Inhalt auch aus dem Ram raus ist.

*seufz* Doch, genau das stellt die Architektur bereits sicher. Und zwar abhängig von ebenjener über Write-Through instantan oder über Write-Back verzögert.
Wenn der Prozessor den Speicherbereich mit Nullen füllt, tut er das im Cache. Wenn jetzt jemand anderes (Prozess) gerne auf die Seite zugreifen möchte und das Passwort auslesen will, geschieht die Read-Operation ebenfalls im Cache, es sei denn die Cache-Line wurde in der Zwischenzeit aus anderen Gründen geleert (spätestens dann ist auch im RAM der Bereich mit Nullen und nicht mit dem Klartextpasswort). Das Szenario einer rein softwaregestützten Spionage ist also abgedeckt. Hardwaregestützt könnte man mit einem weiteren Prozessor (und der DMA-Controller ist im Prinzip nichts anderes), der sich nicht den Cache teilt (also geht das nichtmal unbedingt mit allen Multi-Core-Architekturen) die gleiche Adresse aus dem RAM auslesen. Da das auch aus anderen Gründen vollkommen legitim geschehen kann, muss ebenfalls durch die Architektur sichergestellt sein, daß auch der zweite Prozessor die Nullen sieht und nicht das Klartextpasswort. Das geschieht über Cache-Kohärenz-Protokolle, die dafür sorgen, daß alle Caches in sich stimmig sind.
Das einzige Problem, das existieren kann, ist, daß die Seite ausgelagert wurde, nachdem das Passwort in sie geschrieben wurde aber bevor der Speicherbereich wieder genullt wurde. Für diesen (je nach Anwendungsfall unwahrscheinlichen) Fall musst du für die entsprechende Seite das Paging verhindern. Ob und wie das unter Windows geht, weiß ich nicht, aber das weißt du ja anscheinend.

[Olli]

himitsu, sei dir versichert, daß jegliche Usermode-Implementation in Sachen Speicher keinen Einfluß auf die von dir genannten Dinge hat ;)

[himitsu]

OK, wenn das mit der 'Cache stimmt, dann kann man also einen Bereich sicher löschen ... und das es nicht in die PageFile ausgelagert wird ist möglich, jedenfalls sollte es möglich sein (laut MSDN) werd' dafür mal entsprechende Funktionen in die Klasse "Memory" aus http://www.delphipraxis.net/internal...=551192#551192 einfügen und's bei Zeiten testen ._.

Das ReadProcessMemory konnte man ja auch noch sperren, da dieses ja anscheinend nur lesen kann, wenn man die nötigen Rechte für den Prozess hat (irgendwo stand dazu hier mal was ... weiß aber nicht mehr wo -.- )

[add]
Ohh, da isses ja ... http://www.delphipraxis.net/internal...=539309#539309

man muß also nur verhindern, daß andere Prozesse an ein Handle mit PROCESS_VM_WRITE und PROCESS_VM_OPERATION für WriteProcessMemory/ReadProcessMemory rannkommt -.-''

[Frickeldrecktuxer_TM]

Zitat:

man muß also nur verhindern, daß andere Prozesse an ein Handle mit PROCESS_VM_WRITE und PROCESS_VM_OPERATION für WriteProcessMemory/ReadProcessMemory rannkommt -.-''

Du möchtest verhindern, daß dein Prozess debuggt wird: http://luckie-online.de/Developer/Ar...acking_1.shtml

[himitsu]

Für das erschweren den Debuggens hab ich auch schon einiges, aber man kann doch dennoch per WriteProcessMemory/ReadProcessMemory an den Speicher rankommen? (jedenfalls braucht man keinen Debugger dafür) :gruebel:

[Frickeldrecktuxer_TM]

Zitat:

Zitat von himitsu

WriteProcessMemory/ReadProcessMemory an den Speicher rankommen? (jedenfalls braucht man keinen Debugger dafür) :gruebel:

Du brauchst Debugging Privileges (nicht das SeDebugPrivilege) um überhaupt OpenProcess() mit passendem Access Mode aufrufen zu können.
Wenn der Angreifer Admin-Rechte hat: no chance, 100%ige Sicherheit wirst du da nicht kriegen.

[Olli]

Zitat:

Zitat von Frickeldrecktuxer_TM

100%ige Sicherheit wirst du da nicht kriegen.

Eben. Gutes Schlußwort.

[himitsu]

na dann erstma danke ^^

ich weiß ... 100% geht nicht (leider) ... obwohl ... ich kenn da die Beste Verschlüsselung überhaupt ... die nennt sich 15t TNT und ein Zünder :roll: