4. Frage zu Dynamic-Link Library Security Problem

Frage zu Dynamic-Link Library Security Problem

  • M

    Hallo

    In den Medien wird ja in letzte Zeit von einer DLL-Lücke in Anwendungen geredet.

    Kann mir jemand mal genau erklähren was da das Problem ist ?

    http://msdn.microsoft.com/en-us/library/ff919712(VS.85).aspx

    Eigentlich verstehe ich das schon ein bisschen aber ich versteh nicht warum das erst jetzt Problem bereitet.
    Bzw verstehe es das wohl noch nicht ganz.

    1 mal zu Reihenfolge:
    1. The directory from which the application loaded.
    2. The system directory.
    3. The 16-bit system directory.
    4. The Windows directory.
    5. The current directory.
    6. The directories that are listed in the PATH environment variable.

    Wo ist zuerst einmal der Unterschied zwischen 1 und 5 ?

    Soweit ich verstanden habe ist das Problem ja wenn man bloß mit LoadLibrary("myDll.dll");
    die dll lädt. Windows nach der Reihenfolge die Verzeichnisse absucht.

    Angenommen die dll wird erst bei 2 gefunden. Dann könnte ich bei 1 eine Dll ablegen dann würde statt der Original Dll die bei 1 abgelegt Dll geladen werden. Ist das soweit richtg ?

    Aber dazu muss ja zumindest mal die dll für das Programm mindestens nicht bei 1 liegen. Ich müsste die Rechte haben im Directory etwas zu verändern. (Was ich vielleicht in vielenn Fällen habe).
    Aber wenn ich die habe dann kann ich ja auch gleich die dll austauschen. Aber das Problem exestiert doch schon lange ?

    Also es müsste ein Programm/Prozess sein der mit Adminrechten gestartet wird. Der Installiert ist und dessen dlls in 2 liegen.
    Jetzt müsste ich das Recht haben um bei 1 für das Programm eine dll ab zulegen. Jetzt würde die dll geladen werden mit Adminrechten.

    Geht es darum ? Und bei Relative Pfaden tritt das auch nicht auf ?

    Grüße
    Martin

    0
  • E

    http://blogs.technet.com/b/srd/archive/2010/08/23/more-information-about-dll-preloading-remote-attack-vector.aspx

    0
  • M

    Hmm ok also so ganz klar ist es mir aber immer noch nicht.
    Mein Frage ist damit mal nicht beantwortet. Also noch mal die Frage:
    Was ist der unterschied zwischen "The directory from which the application loaded." und "The current directory."
    Ich denke mal es geht um das "current working directory".

    Wenn ich eine Programm(Exe) starte meine ich,dass das zuerst mal das die gleich sind.
    Jetzt wird wohl erwartet das der Benutzuer irgendwo ein Dokument mit dem gestarteten Programm auswählt.
    Damit ändert sich wohl das "current working directory". Jetzt müsste aber das Programm nach dem öffnen des Dokuments, weil ab jetzt ist ja das Verzeichnis neu gesetzt, mit LoadLibrary arbeiten um die falsche Dll zu laden. Und dazu müsste erstmal die dll nicht im Verzeichnis liegen in der die Anwendung liegt. Weil die erste dll die gefunden wird, wurd geladen.

    So in etwa richtig verstanden ? 🙄

    Also wenn meine Programme schon nach dem Start die Dlls laden, bin ich davon eigentlich nicht betroffen. 😕

    0
  • M

    Nachtrag:
    Achso zum Problem wird das wenn ich ein Programm habe das so eine Art "Pluginsystem" habe.
    Bei dem Funktionen erst geladen werden wenn ich sie brauche. Bzw wo dlls unter umständen gar nicht da sind weil das Plugin fehlt. 😕
    Erst da sollte ich mir dann wirklich gedanken darüber machen ??

    0
  • Mod

    Du hast es ziemlich genau zusammengefasst was das Problem sein kann.
    Ich habe das einbeziehen des Current Working Directories nie verstanden.

    Du bist auch dann nicht betroffen, wenn alle Deine DLLs immer im Applikation Verzeichnis liegen...

    Grundsätzlich kann es sichelrich aberandere Komponenten geben, wie z.B. COM Module oder ähnliches, die evtl. auch wieder optional DLLs laden...

    Zur Sicherheit kann man einfach SetDLLDirectory einsetzen und gut ists...

    PS: Grundsätzlich darf man aber auch Delay-Load Komponenten hier nicht vergessen.

    0
  • M

    Achso ja klar.
    Wenn ich irgend ein Bibliothek aufsetze die auch so etwas in der Art macht. Dann natürlich auch indirekt.

    Ok dann soweit mal klar.
    Thx

    0
  • G

    Man kann zusätzlich noch die PATH-Umgebungsvariable im Prozess killen - sofern man die nicht tatsächlich mal brauchen sollte.
    Dann besteht der Suchpfad im Prinzip nur noch aus dem eigenen Programm-Verzeichnis und den Windows-Ordnern

    Dieses Mini-Testprogramm:

    SetDllDirectory(TEXT(""));
SetEnvironmentVariable(TEXT("PATH"),NULL);
HMODULE dll=LoadLibrary(TEXT("dummy2832380123.dll"));

    ergibt unter Win7 (32bit-exe) dann nur noch diese Suchreihenfolge:

    E:\dlltest_unmanaged\Debug\dummy2832380123.dll
C:\Windows\SysWOW64\dummy2832380123.dll
C:\Windows\system\dummy2832380123.dll
C:\Windows\dummy2832380123.dll
    0
Anmelden zum Antworten