Hallo.

Da im Moment ja grade die DLL Hijacking-Lücke sehr präsent ist, wollte ich einfach mal wissen: Ist Delphi dafür anfällt?
OK das ist jetzt ein bisschen blöd formuliert, da ja jeder Entwickler selber dafür verantwortlich ist.

Aber: Sind evtl in den VCL Sourcen oder anderen mitgelieferten PAS-Files solche verwundbaren LoadLibrary-Aufrufe drinnen?
Weiß da jemand Bescheid?

MfG
Matze

Ich glaube das ganze geht so, dass, wenn du ein Dokument (Word, Video, was auch immer) irgendwo öffnest (z.B. Doppelklick in Explorer), dann wird das Current Directory auf das Verzeichnis gesetzt, wo das Dokument ist und dann das Programm geöffnet, das dieses File öffnen kann. Wenn jetzt in diesem Verzeichnis auch noch eine DLL sitzt, die die Applikation braucht, dann wird diese möglicherweise geladen.

Bei den KnownDLLs (kernel32, etc.) sollte dies vermutlich kein Problem darstellen. Mir ist nicht bewusst, dass Delphi DLLs braucht, die nicht in KnownDLLs eingetragen sind. Wenn du aber eigene hast, musst du aufpassen, dass du einen hinreichend qualifizierten Pfad angibst. Ansonsten kannst du die DLLs auch signieren.

Du musst natürlich auch ein Programm haben, welches wie oben geschrieben indirekt geöffnet werden kann.

matze hat folgendes geschrieben :

Da im Moment ja grade die DLL Hijacking-Lücke sehr präsent ist, wollte ich einfach mal wissen: Ist Delphi dafür anfällt? OK das ist jetzt ein bisschen blöd formuliert, da ja jeder Entwickler selber dafür verantwortlich ist. Aber: Sind evtl in den VCL Sourcen oder anderen mitgelieferten PAS-Files solche verwundbaren LoadLibrary-Aufrufe drinnen? Weiß da jemand Bescheid?

Interessant zu dem Thema:

msdn.microsoft.com/e...ff919712(VS.85).aspx

Wenn ich das richtig in Erinnerung habe (ist schon ein paar Tage her), so ist prinzipiell jedes Programm betroffen, welches ein LoadLibrary ohne explizite Pfadangabe macht und sein aktuelles Verzeichnis nicht explizit setzt, so dass es durch den Anwender festgelegt werden kann (File Open / File Save Dialog oder einfach das aktuelle Verzeichnis des aufrufenden Prozesses, z.B. des Explorer-Fensters).

Dagegen hilft laut dieses Artikels der Aufruf von SetDllDirectory('') beim Programmstart. Da ich von dieser Funktion noch nie gehoert hatte, vermute ich mal, dass ich sie auch im RTL/VCL Code noch nicht gesehen habe (und ein Grep auf den Sourcecode gibt mir recht).

Das wuerde bedeuten, dass jeglicher Aufruf von LoadLibrary in der RTL/VCL unsicher ist und davon gibt es diverse:

C:\Program Files\CodeGear\RAD Studio\5.0\source\database\src\pas\dbx\driver\DBXDynalink.pas
816 FLibraryHandle := THandle(LoadLibrary(SDBX_ADAPTER_NAME));

C:\Program Files\CodeGear\RAD Studio\5.0\source\database\src\pas\dbx\driver\DBXDynalinkNative.pas
117 FLibraryHandle := THandle(LoadLibrary(SDBX_ADAPTER_NAME));

C:\Program Files\CodeGear\RAD Studio\5.0\source\Indy-renamed\Indy10\Protocols\IdGlobalProtocols.pas
927 lh:=LoadLibrary('ntdll.dll'); {do not localize}

C:\Program Files\CodeGear\RAD Studio\5.0\source\Indy-renamed\Indy10\Protocols\IdSSLOpenSSLHeaders.pas
4721 If hIdIndySSL = 0 Then hIdIndySSL := LoadLibrary(SSL_Indy_DLL_name) else exit;
4723 if hIdCrypto = 0 then hIdCrypto := LoadLibrary(SSLCLIB_DLL_name);
4724 If hIdSSL = 0 Then hIdSSL := LoadLibrary(SSL_DLL_name) else exit;
4725 // If hIdIndySSL = 0 Then hIdIndySSL := LoadLibrary(SSL_Indy_DLL_name);

C:\Program Files\CodeGear\RAD Studio\5.0\source\Indy-renamed\Indy10\Protocols\IdSSLOpenSSLHeadersNET.pas
5075 LIdCrypto := LoadLibrary(SSLCLIB_DLL_name);
5084 LIdSSL := LoadLibrary(SSL_DLL_name);

C:\Program Files\CodeGear\RAD Studio\5.0\source\Indy-renamed\Indy10\System\IdWinsock2.pas
4904 @TransmitFile := GetProcAddress(LoadLibrary('WSOCK32.dll'), 'TransmitFile'); {Do not Localize}
5087 hWS2Dll := LoadLibrary( WINSOCK2_DLL );

C:\Program Files\CodeGear\RAD Studio\5.0\source\Indy-renamed\Indy10\System\IdWship6.pas
272 hWship6Dll := LoadLibrary( Wship6_dll );

C:\Program Files\CodeGear\RAD Studio\5.0\source\Indy-renamed\Indy9\IdSSLOpenSSLHeaders.pas
4479 If hIdIndySSL = 0 Then hIdIndySSL := LoadLibrary(SSL_Indy_DLL_name) else exit;
4481 if hIdCrypto = 0 then hIdCrypto := LoadLibrary(SSLCLIB_DLL_name);
4482 If hIdSSL = 0 Then hIdSSL := LoadLibrary(SSL_DLL_name) else exit;
4483 // If hIdIndySSL = 0 Then hIdIndySSL := LoadLibrary(SSL_Indy_DLL_name);

C:\Program Files\CodeGear\RAD Studio\5.0\source\Indy-renamed\Indy9\IdWinSock2.pas
4241 hWS2Dll := LoadLibrary( WINSOCK2_DLL );

C:\Program Files\CodeGear\RAD Studio\5.0\source\Win32\IBX\IBIntf.pas
994 IBLibrary := LoadLibrary(PChar(IBASE_DLL));
1158 IBXMLLibrary := LoadLibrary(PChar(IBXML_DLL));
1227 IBInstallLibrary := LoadLibrary(PChar(IB_INSTALL_DLL));

C:\Program Files\CodeGear\RAD Studio\5.0\source\Win32\rtl\common\ComServ.pas
462 OleAutHandle := SafeLoadLibrary('OLEAUT32.DLL');

C:\Program Files\CodeGear\RAD Studio\5.0\source\Win32\rtl\win\Mapi.pas
439 MAPIModule := LoadLibrary(PChar(MAPIDLL));

C:\Program Files\CodeGear\RAD Studio\5.0\source\Win32\rtl\win\PsAPI.pas
215 hPSAPI := LoadLibrary('PSAPI.dll');

C:\Program Files\CodeGear\RAD Studio\5.0\source\Win32\Samples\Source\IBCtrls.pas
209 LibHandle := LoadLibrary('gds32.dll');

C:\Program Files\CodeGear\RAD Studio\5.0\source\Win32\vcl\AxCtrls.pas
4136 OlePro32Dll := SafeLoadLibrary('olepro32.dll');

C:\Program Files\CodeGear\RAD Studio\5.0\source\Win32\vcl\ComCtrls.pas
4225 ShellModule := SafeLoadLibrary(ShellDllName);
11864 FRichEditModule := LoadLibrary(RichEditModuleName);

C:\Program Files\CodeGear\RAD Studio\5.0\source\Win32\vcl\Controls.pas
12175 IMM32DLL := LoadLibrary(Imm32ModName);

C:\Program Files\CodeGear\RAD Studio\5.0\source\Win32\vcl\ExtActns.pas
1301 UrlMonHandle := LoadLibrary(UrlMonLib);

C:\Program Files\CodeGear\RAD Studio\5.0\source\Win32\vcl\GraphUtil.pas
647 MsImgHandle := LoadLibrary(msimg32);

C:\Program Files\CodeGear\RAD Studio\5.0\source\Win32\vcl\Menus.pas
3090 DLLHandle := SafeLoadLibrary(DLLName);

C:\Program Files\CodeGear\RAD Studio\5.0\source\Win32\xml\oxmldom.pas
1713 UrlMonHandle := LoadLibrary(UrlMonLib);

Das ist jetzt Delphi 2007, ich will nicht ausschliessen, dass auch neuere Delphi-Versionen betroffen sind.

Wer sicherstellen will, dass seine programme nicht betroffen sind, ruft einfach beim Programmstart als moeglichst erstes

Delphi-Quelltext    ausgeblendet	markieren
1: SetDllDirectory('');

auf. Beschreibung von msdn.microsoft.com/e...686203(v=VS.85).aspx :

Parameter:

The directory to be added to the search path. If this parameter is an empty string (""), the call removes the current directory from the default DLL search order. If this parameter is NULL, the function restores the default search order.

Einziges Problem: Wie kann ich sicherstellen, dass dieser Aufruf ausgefuehrt wird, bevor einer der potentiell unsicheren LoadLibrary Aufrufe aus der RTL/VCL stattfindet.

Meiner Ansicht nach muesste der Aufruf dafuer in der INITIALIZATION Section einer Unit stehen, die als erste in der Uses-Liste der .DPR-Datei steht und die ihrerseits keine weitere Unit einbindet. Selbst dann wird natuerlich system.pas und der Memory-Manager vorher eingebunden. Man muesste also pruefen, ob da ein Problem besteht. Ausserdem ist SetDllDirectory nirgends deklariert, d.h. man muss erstmal herausfinden, in welcher Windows DLL sie steht (laut Beschreibung kernel32.dll) und diese Funktion dann selbst deklarieren:

function SetDllDirectoryA(lpPathName: PAnsiChar): LongBool;

bzw.

function SetDllDirectoryW(lpPathName: PWideChar): LongBool;

twm

Naja, es kommt ja immer noch auf die Anwendung darauf an. Wenn man die Anwendung sowieso nur durch Doppelklick auf das Exe starten kann, dann ist es nicht betroffen.

dummzeuch hat folgendes geschrieben :

Dagegen hilft laut dieses Artikels der Aufruf von SetDllDirectory('') beim Programmstart.

Da wär ich jetzt nicht so sicher. Wenn du DLLs direkt importierst (nicht zu einer späteren Zeit über LoadLibrary), dann werden die offenbar schon geladen, bevor du eine Zeile eigenen Code ausführen kannst, d.h. bevor irgend welche Units geladen sind. Wenn du in SysInit einen Breakpoint auf _InitExe setzt, dann sieht man im EventLog schon, dass bereits eine Menge DLLs geladen wurden.

delfiphan hat folgendes geschrieben :

Naja, es kommt ja immer noch auf die Anwendung darauf an. Wenn man die Anwendung sowieso nur durch Doppelklick auf das Exe starten kann, dann ist es nicht betroffen.

Das kann man nicht verhindern, das es auch anders geht. Ich brauch nur eine Verknüpfung erstellen und das Feld "Ausführen in" anders setzen und schon hab ich das falsche Verzeichnis wenn ichs ned prüfe.

lg elundril

This Signature-Space is intentionally left blank.
Bei Beschwerden, bitte den Beschwerdebutton (gekennzeichnet mit PN) verwenden.

delfiphan hat folgendes geschrieben :

Du musst natürlich auch ein Programm haben, welches wie oben geschrieben indirekt geöffnet werden kann.

Du kannst das Verzeichnis direkt z.B. bei ShellExecute angeben.

Ja, einverstanden. Aber dann hast du die Pfade selbst so gesetzt. Hättest ja auch gleich die DLL überschreiben können, sofern du darauf schreibzugriff hast. Solange ein Remoteangreifer den Pfad nicht setzen kann ist es für ihn relativ schwierig, diese Lücke auszunützen.

Die Sicherheitslücke wird meistens so ausgenützt, dass du eben ein .doc auf einem Share öffnest und auf diesem Share im gleichen Ordner eine DLL ist. Oder du im Browser ein Medienfile abspielst und blöderweise zuvor noch eine DLL in das gleiche Cacheverzeichnis runtergeladen wurde.

Hi, schaut euch mal dazu die Diskusion im Delphi Treff mit an. Find ich auch sehr interresant zu diesem Thema!

Gruss Alf

Fix für das Problem dürfte sein:

Delphi-Quelltext    ausgeblendet	markieren
1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: Unit FixKnownAppIssues; interface implementation function SetDllDirectoryW(lpPathName: ^WideChar): Integer; stdcall; external 'kernel32.dll' name 'SetDllDirectoryW'; initialization SetDllDirectoryW(''); end.

Wer sich grad wundert, warum ich nicht die Windows.pas für DWORD und Longbool einbinde: Weil ich sonst implizite Abhängigkeiten drinnen hätte und die Unit damit relativ spät in der Ladereihenfolge kommt.

Die Unit bitte im Projekt-File als erste Unit (noch vor ShareMem oder anderen Memory-Managern) einbinden.

Bzgl. Indy: der Aufruf der ntdll.dll dürfte sicher sein, weil KnownDLL. Anders sieht's bei der Anbindung von SSL aus.

Genauso msimg32.dll und urlmon.dll. Hab das aber grad nicht nachgeprüft. Auch der Punkt mit ShellDllName (shell32.dll) sollte sicher sein.

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

Also habe ich das richtig verstanden, wenn ich eine Anwendung öffne die sagen wir mal eine blabla.dll benötigt und laden will, dass Windows dann zunächst in der "Current Directory" danach sucht.
Jetzt könnte ein Angreifer eine dll mit dem selben Namen in dieses Verzeichnis gelegt haben und mein Programm würde diese statt der originalen laden.

Ist das so richtig? (Habe noch keine Ahnung von dll-Kram. )

Ja, das hast du schon richtig verstanden. Und weshalb das dann zu Angriffen von außen taugt, wurde ja auch bereits beschrieben.

Benny,

eine Frage: unter Delphi 7 bekomme ich bei der Kompilierung meines Projects einen Fehler:

Delphi-Quelltext    ausgeblendet	markieren
1: 2: 3: 4: 5: function SetDllDirectoryW(lpPathName: ^WideChar): Integer; stdcall; external 'kernel32.dll' name 'SetDllDirectoryW'; [Fehler] FixKnownAppIssues.pas(7): Bezeichner erwartet, aber '^' gefunden [Fehler] FixKnownAppIssues.pas(11): Inkompatible Typen: 'WideChar' und 'String' [Fataler Fehler] Project1.dpr(6): Verwendete Unit 'FixKnownAppIssues.pas' kann nicht compiliert werden

Unter welcher Delphi-Version hast Du das erstellt ?


Ich habe eine Lösung gefunden ( forum.delphi-treff.d...;p=212667#post212667 )

trm hat folgendes geschrieben :

Unter welcher Delphi-Version hast Du das erstellt ?

Vermutlich unter einem Virtuellen Delphi im Kopf.

Delphi will Argumente immer in echten Typen haben, nicht in ad-hoc-Typen. Also entweder selber deklarieren oder gleich PWideChar verwenden.

Martok hat folgendes geschrieben :

trm hat folgendes geschrieben : Unter welcher Delphi-Version hast Du das erstellt ? Vermutlich unter einem Virtuellen Delphi im Kopf.

DBrain 42.

Martok hat folgendes geschrieben :

Delphi will Argumente immer in echten Typen haben, nicht in ad-hoc-Typen. Also entweder selber deklarieren oder gleich PWideChar verwenden.

Bzgl. PWideChar bitte meine Erklärung im Post beachten. Wenn der nicht aus System oder SysInit kommt, bleibt nur: Kurz selber deklarieren. Gehört dann in den Implementation-Teil über die Funktionsdeklaration. NICHT ins Interface, sonst gibt's Probleme mit der Sichtbarkeit durch andere Units.

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

BTW: Könnte man das nicht besser mit:

Delphi-Quelltext    ausgeblendet	markieren
1: 2: SetDllDirectoryW(''); SetDllDirectory(ExtractFilePath(ParamStr(0)));

lösen?

Dann hat man wirklich das Programmverzeichnis, aber nicht das Ausführen in verzeichnis drin.
Vorausgesetzt man kriegt das obige vor die LoadLibrary aufrufe.

IMHO wäre das DIE Lösung für einen Patch der kernel32.dll LoadLibrary Funktion, da es genau das macht, was man erwartet.

Flamefire hat folgendes geschrieben :

IMHO wäre das DIE Lösung für einen Patch der kernel32.dll LoadLibrary Funktion, da es genau das macht, was man erwartet.

Das wäre ein "contract-breaking" change. Das kann die Microsoft (zu mindest in einem Patch) nicht einfach so tun. Das würde dazu führen, dass u.U. gewisse Programme nicht mehr funktionieren, was wieder dazu führen würde, dass gewisse Leute nicht mehr updaten.

Solche DLL Mixups habe ich selbst auch schon erlebt, da muss man sehr vorsichtig sein.

Ich denke mal, dass das Problem schon seit vielen Jahren bekannt ist (daher gibt's auch obige Funktion schon länger). Wer auf sicher gehen will soll mit signierten DLLs arbeiten.

warum? Es ging doch darum, dass im Anwendungsverzeichnis nach der DLL gesucht wird. Haltes es eher für einen Fehler, dass stattdessen in einem anderen gesucht wird.
Oder wo wird gezielt das Ausführungsverzeichnis geändert, um woanders anch ner DLL zu suchen (oder das erwartet)

Es ist ein Fehler, aber den kann die Microsoft jetzt nicht einfach so beheben. Bei normalen Programmen kann man das sicher ändern; aber Microsoft kann keinen Patch rausgeben, das dazu führt, dass plötzlich etwas nicht mehr funktioniert. Dazu gehören auch schlecht gecodede Programme, die mit den DLLs vielleicht ein durcheinander haben und nur funktionieren, wenn LoadLibrary eben genau so funktioniert, wie sie eben funktioniert. Die Option "LoadLibrary anpassen" haben sich die Leute in Redmond sicher sehr gut überlegt.

Die Leute erwarten, dass Patches nichts "kaputt" machen. Wenn die MS zugibt, dass es ihr Fehler war und der Fix dazu führt, dass ein Programm nicht mehr funktioniert, haben sie sicher irgendwelche Klagen am Hals. Lieber dokumentieren sie, was die Funktion genau macht und stellen zusätzliche Funktionen bereit und überlassen es den Softwarefirmen, das Problem zu beheben.

delfiphan hat folgendes geschrieben :

Es ist ein Fehler, aber den kann die Microsoft jetzt nicht einfach so beheben.

Warum ist es ein Fehler ?

Ich finde es super, wenn Programme in ihrem eigenen Verzeichnis nach DLL's suchen !
Dann kann man die auch selber mitliefern, wenn benötigt.

Ein Beispiel:
Anwendung A benötigt die QT-Library und kopiert sie, weil noch nicht vorhanden nach System32.
Anwendung B benötigt ebenfalls die QT-Library und kopiert sie, weil neuer, nach System32.
Anwendung C benötigt ebenfalls die QT-Library, kopiert sie aber nicht, weil eine neuere Version bereits im System32 existiert.

Da neuere Versionen nicht unbedingt abwärtskompatibel sein müssen, insbesondere dann, wenn die Software-Entwickler in eine Release noch eigene Features einkompiliert haben, würde jetzt ein heilloses Deasaster entstehen.

Dank des so gescholtenen Fehlers, kann man aber die benötigten DLL's einfach in das Verzeichnis des Programmes kopieren, welches mit den aktuellsten Lib's nicht arbeiten will.
Oder jeder Applikation ihre eigenen DLL's spendieren.

Am Besten wäre es aber, wenn Windows endlich Hardlinks transparent und dokumentiert unterstützen würde.
Dann könnte jede Anwendung im eigenen Verzeichnis alle DLL's beherbergen, inkl. Derer von MS (weil hardlinked).
Bei der Deinstallation wäre klar, ob noch jemand die DLL verwendet und die letzte deinstallation könnte korrekt aufräumen.

Leider wird mit jeder Installation und nachfolgender Deinstallation aber das System nicht wieder in dem Zustand zurück gelassen, wie es vor der Installation aussah.
Jeder hat Angst etwas zu löschen, was Andere noch benötigen (könnten).

Es ist ein Fehler, weil jetzt jedes Programm praktisch SetDllDirectory mit zu mindest leerem String als Argument übergeben soll. Diese neue Reihenfolge müsste bei LoadLibrary schon standard sein.