WinFuture-Forum.de: Frage zu CWDIllegalInDllSearch Registry Eintrag - WinFuture-Forum.de

Zum Inhalt wechseln

Alle Informationen zum Thema Windows 7 in unserem Special. Windows 7 Download, FAQ und neue Funktionen im Überblick.
Seite 1 von 1

Frage zu CWDIllegalInDllSearch Registry Eintrag

#1 Mitglied ist offline   d4rkn3ss4ev3r 

  • Gruppe: aktive Mitglieder
  • Beiträge: 3.921
  • Beigetreten: 03. Januar 09
  • Reputation: 501

geschrieben 09. Juli 2016 - 17:04

In Bezug auf einen heise Eintrag aus 2010
http://www.heise.de/...me-1069075.html +
http://www.heise.de/...um-1070416.html
und den dazu gehörigen KB Eintrag
https://support.micr...e-de/kb/2264107

habe ich eine Frage. Im verlinkten KB Eintrag ist für Win7 x64 das Update KB2264107 (https://www.microsof...034bcdd6d2=True) verfügbar.
Dieses ist bei meiner neuen Windows Installation mit allen aktuellen Updates nicht installiert.
Muss ich dieses installieren oder wurde das mit späteren Updates gesichert?

Einen CWDIllegalInDllSearch Eintrag unter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager habe ich nicht:
Angehängtes Bild: registry.png
"Jene, die grundlegende Freiheit aufgeben würden, um eine geringe vorübergehende Sicherheit zu erwerben,
verdienen weder Freiheit noch Sicherheit." (Benjamin Franklin)


ACTA] | IPRED | SOPA | PIPA | CISPA | INDECT | TPP | TAFTA | Stop CETA + Stop TTIP
> Mein Hells Toolbox CMD Script <
Powered by Goanna
0

Anzeige

#2 Mitglied ist offline   Samstag 

  • Gruppe: aktive Mitglieder
  • Beiträge: 4.900
  • Beigetreten: 14. Juli 07
  • Reputation: 265

geschrieben 09. Juli 2016 - 17:31

Das Update ist im SP1 (Update 790) enthalten. Die Updates darin werden alle nicht extra aufgeführt, ist aber auch kein Wunder bei über 900 enthaltenen Updates.

Dieser Beitrag wurde von Samstag bearbeitet: 09. Juli 2016 - 17:32

1

#3 Mitglied ist offline   d4rkn3ss4ev3r 

  • Gruppe: aktive Mitglieder
  • Beiträge: 3.921
  • Beigetreten: 03. Januar 09
  • Reputation: 501

geschrieben 09. Juli 2016 - 18:56

Okay.

Dann sollte der Eintrag ja etwas bewirken.
"Jene, die grundlegende Freiheit aufgeben würden, um eine geringe vorübergehende Sicherheit zu erwerben,
verdienen weder Freiheit noch Sicherheit." (Benjamin Franklin)


ACTA] | IPRED | SOPA | PIPA | CISPA | INDECT | TPP | TAFTA | Stop CETA + Stop TTIP
> Mein Hells Toolbox CMD Script <
Powered by Goanna
0

#4 Mitglied ist offline   RalphS 

  • Gruppe: VIP Mitglieder
  • Beiträge: 7.765
  • Beigetreten: 20. Juli 07
  • Reputation: 859

geschrieben 10. Juli 2016 - 00:11

Läßt sich relativ schnell testen: Du baust zwei kleine Funktionsbibliotheken - sinngemäß reicht auch eine, die Du dann einmal kopierst und die Kopie geringfügig anpaßt --- wo letztlich nur eine exportierte Funktion drin steht, die einmal 'A' ausgibt und einmal 'B' (oder sonstwas) und das bei gleichem Exportmodul (sagen wir test.dll) und gleichem exportierten Funktionsnamen (sagen wir int do_test() ). Dazu eine ausführbare Datei bauen, die bloß eine main() Routine beinhaltet, welche do_test() aufruft und dazu die test.dll dynamisch lädt.

Dann kompilierst Du das Ganze und kriegst so eine do_test.exe sowie eine test.dll, die in denselben Ordner kommt (und "A" ausgibt) und eine test.dll die stattdessen "B" ausgibt und die Du in einen ANDEREN Ordner schiebst (offensichtlich) welcher sich im Systempfad befindet (=> %PATH% Variable).

Dann die EXE-Datei aufrufen und schauen, was zurückgegeben wird. Im Beispiel: wenn A auf den Bildschirm geschrieben wird, ist das Loch da. Wenn stattdessen "B" geschrieben wird, ist das Loch gestopft.

Dieser Beitrag wurde von RalphS bearbeitet: 10. Juli 2016 - 00:12

"If you give a man a fish he is hungry again in an hour. If you teach him to catch a fish you do him a good turn."-- Anne Isabella Thackeray Ritchie

Eingefügtes Bild
Eingefügtes Bild
0

#5 Mitglied ist offline   d4rkn3ss4ev3r 

  • Gruppe: aktive Mitglieder
  • Beiträge: 3.921
  • Beigetreten: 03. Januar 09
  • Reputation: 501

geschrieben 16. Juli 2017 - 12:03

Habe damals wohl vergessen zu antworten.
Kannst du so etwas bauen?
"Jene, die grundlegende Freiheit aufgeben würden, um eine geringe vorübergehende Sicherheit zu erwerben,
verdienen weder Freiheit noch Sicherheit." (Benjamin Franklin)


ACTA] | IPRED | SOPA | PIPA | CISPA | INDECT | TPP | TAFTA | Stop CETA + Stop TTIP
> Mein Hells Toolbox CMD Script <
Powered by Goanna
0

#6 Mitglied ist offline   RalphS 

  • Gruppe: VIP Mitglieder
  • Beiträge: 7.765
  • Beigetreten: 20. Juli 07
  • Reputation: 859

geschrieben 16. Juli 2017 - 14:05

Theoretisch ja, praktisch krieg ich grad einen 0xc000:0142 zurück, wenn ich die DLLs austausch, egal wo sie sich befinden.

Was darauf hindeutet, daß das als C++ gebaut wird und nicht als C. Das sagt uns also nicht sonderlich viel. Werd mir das bei Gelegenheit mal anschaun.

Ja, das könnte auch die erwähnte Sicherheitsmaßnahme sein. Glaub ich aber nicht so recht dran.
"If you give a man a fish he is hungry again in an hour. If you teach him to catch a fish you do him a good turn."-- Anne Isabella Thackeray Ritchie

Eingefügtes Bild
Eingefügtes Bild
1

#7 Mitglied ist offline   d4rkn3ss4ev3r 

  • Gruppe: aktive Mitglieder
  • Beiträge: 3.921
  • Beigetreten: 03. Januar 09
  • Reputation: 501

geschrieben 16. Juli 2017 - 17:47

Alles klar. Dann hoffe ich das du es hinbekommst.
Wäre ein nettes Tool
"Jene, die grundlegende Freiheit aufgeben würden, um eine geringe vorübergehende Sicherheit zu erwerben,
verdienen weder Freiheit noch Sicherheit." (Benjamin Franklin)


ACTA] | IPRED | SOPA | PIPA | CISPA | INDECT | TPP | TAFTA | Stop CETA + Stop TTIP
> Mein Hells Toolbox CMD Script <
Powered by Goanna
0

#8 Mitglied ist offline   RalphS 

  • Gruppe: VIP Mitglieder
  • Beiträge: 7.765
  • Beigetreten: 20. Juli 07
  • Reputation: 859

geschrieben 17. Juli 2017 - 11:42

Kurzer Zwischenbericht:

- Als x86 funktioniert es, wenn weder im Programmverzeichnis noch im Suchpfad die fragliche DLL gefunden wird. Dann wird die DLL aus CWD genommen.

- Als x64 vergiftet mir irgendwas die Umgebung. Sieht aus, als hätte ich irgendwo eine 32er DLL im 64er Suchpfad oder irgendwie sowas. Muß ich noch weiter testen, was da los ist.

- Das, oder der 64er Linker ist schlauer als ich. :blush:
"If you give a man a fish he is hungry again in an hour. If you teach him to catch a fish you do him a good turn."-- Anne Isabella Thackeray Ritchie

Eingefügtes Bild
Eingefügtes Bild
0

#9 Mitglied ist offline   RalphS 

  • Gruppe: VIP Mitglieder
  • Beiträge: 7.765
  • Beigetreten: 20. Juli 07
  • Reputation: 859

geschrieben 18. Juli 2017 - 02:02

So, erledigt. Der 64er Linker war tatsächlich schlauer; ich hatte aus Versehen eine DllMain definiert und die hatte die falsche Signatur. Mit x86 hat das noch gepaßt. Mit x64... nicht mehr. DllMain() auskommentiert und nun paßt es.

Anbei ein rudimentäres(!) Test-Tool, einschließlich nicht minder rudimentären Quellcodes und 32 sowie 64bit binaries.

Angelegt wird ein Ordner dll-test, mit Unterverzeichnissen
>> src (für den Quellcode plus eine kleine Build-Batchdatei für MSVC);
>> x86 für die 32er binaries; und
>> x64 für die 64er binaries.

Die beiden x** Verzeichnisse enthalten jeweils ein Verzeichnis DLL1 für eine DLL-Variante namens test.dll, DLL2 für die zweite DLL-Variante desselben Namens und ein Verzeichnis EXE für eine dynamisch gelinkte ausführbare Datei namens dll-test.exe .

Wie es funktioniert:

Wie oben schon angedeutet werden DLL-Funktionen referenziert (dynamic linking; static linking würde den Objektcode kopieren).

Die EXE-Datei referenziert also eine Funktion namens do_test() aus einer Datei namens test.dll .

Die Frage ist: wo kommt das her?

Wenn man auf der Kommmandozeile ins Verzeichnis ... dll1 wechselt und von dort die EXE-Datei aufruft (per ..\exe\dll-test.exe) dann wird die EXE-Datei erwartungsgemäß aus dem aktuellen Arbeitsverzeichnis (CWD) die dort befindliche DLL laden, die darin enthaltene Funktion do_test() ausführen und "DLL #A" auf den Bildschirm schreiben.

Macht man das Ganze nun aus dem Verzeichnis ...dll2 heraus, passiert formal genau dasselbe. Die DLL ist aber eine andere. Deshalb wird der Aufruf derSELBEN Exe-Datei (es gibt ja nur die eine) ein anderes Ergebnis ausgeben (aus der zweiten DLL) und zum "Beweis" ein "DLL #B" auf dem Bildschirm ausgeben.

Dabei ist egal, gegen welche DLL ursprünglich gelinkt wurde, solange nur der Funktionsbestand in beiden DLLs gleichermaßen bereitgestellt wird (hier: nur do_test() ); denn auch der Linkvergang arbeitet mit Referenzen und schreibt diese in die zugehörige Import-Tabelle der EXE-Datei ein.

Wer MSVC installiert hat, bekommt diese Liste mit dumpbin /exports ausgegeben.

Mit einer unixoiden Umgebung und binutils kriegt man dasselbe mit
 nm -B <Pfad zur DLL-Datei> | grep ' T '
heraus (links und rechts des großen T befindet sich jeweils ein einzelnes Leerzeichen). Note: nm schreibt *alle* referenzierten Funktionen auf den Bildschirm, auch die, die gar nicht genutzt wurden. do_test sollte als Funktionsname aber in der Liste mit auftauchen.


Entsprechend kann man sich, wenn man das will, eine eigene test.dll kompilieren, die zumindest die Funktion void do_test() ohne Parameter beinhaltet, zB einen Ordner dll3 anlegen und die da rein tun und dann von hier aus die beigelegte EXE-Datei ausführen. Wichtig ist an dieser Stelle nur, daß die neue DLL irgendwelchen Code beinhaltet, daß man auch sieht, daß sie geladen wurde.

Zu kompilieren ist die DLL unter MSVC mit dem Befehl
cl /FD <dll_source.c> /LINK /OUT:test.dll 

und die entstehende Datei test.dll an einen eindeutigen Ort packen, wo sie keine andere überschreibt.

Der Code ist aber auch mit GCC und CLang kompilierbar und lauffähig (getestet). Hierzu gibt es im Untervrzeichnis "C" ein einzelnes Bash-Script namens build.sh, welches unter msys2/64 mit clang erstellt und getestet wurde. Die Parameter für GCC sind aber dieselben; jedes Auftreten von "clang" kann daher problemlos in ein "gcc" umgebaut werden. Das Script funktioniert wie bereitgestellt, wenn es aus dem src-Ordner heraus aufgerufen wird (und eine msys2-Umgebung samt clang installiert ist; cygwin sollte aber ebenfalls tun und MinGW/32 bzw msys1 jeweils mit gcc und Scriptanpassung ebenfalls).


Insbesondere sei an dieser Stelle auch darauf hingewiesen, daß die beiden Beispiel-DLLs (in 32- und 64-bit Form) aufs Byte genau gleich lang sind. Es ist daher nicht auf den ersten Blick erkennbar, welche DLL nun welche ist. Mit einer Authenticode-Signatur wäre das nicht möglich gewesen; man hätte dann die "richtige" bzw die "falsche" DLL schnell identifizieren und ggf entfernen können.

Jeder kann Quellcode bauen; MSVC ist seit Ewigkeiten als Express, später als Community Edition frei verfügbar und CLang/GCC gibt es ebenfalls schon seit Jahren auch für Windows-Systeme. DLLs erstellen ist kein Hexenwerk; wenn jemand CWD-in-search-path ausnutzen will, dann ist das ein Leichtes und " mir kann sowas nicht passieren" leider ein gravierender Trugschluß.

Angehängte Datei(en)


Dieser Beitrag wurde von RalphS bearbeitet: 18. Juli 2017 - 02:08

"If you give a man a fish he is hungry again in an hour. If you teach him to catch a fish you do him a good turn."-- Anne Isabella Thackeray Ritchie

Eingefügtes Bild
Eingefügtes Bild
1

#10 Mitglied ist offline   d4rkn3ss4ev3r 

  • Gruppe: aktive Mitglieder
  • Beiträge: 3.921
  • Beigetreten: 03. Januar 09
  • Reputation: 501

geschrieben 23. Juli 2017 - 19:44

Also bei Tests zeigen genau das an was du sagst.
Nun werd ich testen inwiefern der CWDIllegalInDllSearch Registry Eintrag dies ändert- aber das kann ich leider erst nächstes Wochenende testen.

Eventuell ist ja jemand schneller
"Jene, die grundlegende Freiheit aufgeben würden, um eine geringe vorübergehende Sicherheit zu erwerben,
verdienen weder Freiheit noch Sicherheit." (Benjamin Franklin)


ACTA] | IPRED | SOPA | PIPA | CISPA | INDECT | TPP | TAFTA | Stop CETA + Stop TTIP
> Mein Hells Toolbox CMD Script <
Powered by Goanna
0

Thema verteilen:


Seite 1 von 1

1 Besucher lesen dieses Thema
Mitglieder: 0, Gäste: 1, unsichtbare Mitglieder: 0