Sicherheitsrisiko DLL-Suchpfad und /DELAYLOAD

An die MS-Profis: Gleiches Suchpfadproblem wie bei LoadLibrary?

geeky

Probiers doch einfach aus (und teile uns das Ergebnis mit)
Ich vermute mal einfach, dass das Problem da auch auftreten wird.

SetDllDirectory(TEXT(""));
SetEnvironmentVariable(TEXT("PATH"),NULL);

...direkt als erstes in der WinMain dürfte sich aber auch da drauf auswirken...

Martin Richter

Natürlich!

BTW: Das habe ich in meinem Posting in http://www.c-plusplus.net/forum/viewtopic-var-t-is-272805.html auch schon geschrieben...

Das ist schlecht, denn dem Linker werde ich für Delayload wohl nur hartkodierte Pfade nennen können (ob ein kompletter Pfad angenommen wird, muss ich noch testen - oder weiß das jemand?).

Außerdem muss ich höllisch aufpassen, dass nicht irgendwelche für Delayload vorgesehene Strukturen oder Klassen bereits vor Aufruf von SetDLLDirectory initialisiert werden. Mal abgesehen davon, dass SetDLLDirectory erst ab Windows XP mit SP1 vorhanden ist und ein einfacher Update für Software auf älteren Systemen damit nicht möglich ist.

hi

Dass mit dem Sicherheitsrisiko mit LoadLibrary() kann man leicht umgehen, in dem man die DLL-Datei Hash't und dan vergleicht mit dem Originalen Hash der DLL.

Dan wirds auch nichts mehr mit DDL Hijacking.

Nur ein Tip ... aber das sollte klar sein.

lowbyte

Martin Richter

Bei uns müssen alle Module signiert sein.
Bevor ich ein Modul lade prüfe ich ob die Signatur vorhanden und gültig ist. Erst dann wird diese geladen...

Hi

@Martin Richter
Das ist aber nicht bei allen so ... man sieht es ja zu genüge

So wie du auch sicher weist, gibt es dutzende Hersteller (Programmierer) von grossen Firmen, die sowas nicht machen.

Firefox
Deamon tool
Google earth

Diese List geht bis ins unfassbare !

lowbyte

Martin Richter

lowbyte_ schrieb:

So wie du auch sicher weist, gibt es dutzende Hersteller (Programmierer) von grossen Firmen, die sowas nicht machen.

Firefox
Deamon tool
Google earth

Diese List geht bis ins unfassbare !

Da gebe ich Dir recht und ich verstehe es nicht!
Aber es war ja auch nur ein Vorschlag.

Seit dem die Zertifizierung für Vista und Windows 7 eine Signatur von DLL/EXE Dateien fordert haben wir uns einfach gesagt: "Das ist auch mehr Sicherheit, wenn wir selbst diese Signatur prüfen!"

hi

@martin

das ist auch gut so martin...
ich wollte damit nur sagen...das ich es fast nicht glauben kann, das auf solche fehler bzw. sicherheitsrelevanten sachen nicht geachtet wird.
ich signiere jede dll,exe bzw. prüfen.

lowbyte

http://www.heise.de/security/meldung/Malware-von-Amts-wegen-vertrauenswuerdig-Update-1026771.html

Und nun?

hi

wir reden hier nicht von digitalen certfikaten von software!
wir reden hier von einer hash signatur einer dll.die man zbsp. mit einem hash algorithmus wie md5 ,sha1 ,sha2 etc.berechnet.
bsp:
zuerst berechnest du den hash eines originalen files, speicherst den hash. dan hashst du die zu prüfende datei(die ja gleich sein sollte), und vergleichst sie miteinander. wen sie nicht gleich sind die hash's der beiden dateien, dann wurde sie verändert. das kann sein durch updates, oder durch manipulation.
so kann man sich zbsp. gegen dll hijacking weren, bzw.unterbinden.

lowbyte

Ich weiß, was ein Hash ist - und bin sicher, dass Martin sehr wohl von digitalen Zertifikaten redet. Was diese Hash-Idee angeht: woher kennst Du bei Fertigstellung Deiner Software die Hashes erst zukünftig erscheinender DLLs? Oder willst Du bei jedem Update einer Fremd-DLL eine neue Version Deiner Software erstellen?

hi

ja da hast du recht.
aber was ich meinte ist..die haus-eigenen dll's.
der rest ist mir schon klar.!
lowbyte

Ich vermute, dass die hauseigenen DLLs im Anwendungsverzeichnis liegen. Da macht eine Hash-Prüfung aber wenig Sinn, denn wenn Dir jemand dort eine falsche Dll unterschieben kann, hat er auch kein Problem, gleich die Exe selbst auszutauschen.
Abgesehen davon hätte ich auch bei eigenen Applikationen keine Lust, nach Update einer DLL zusätzlich noch die Exe zu aktualisieren und notwendigerweise neu zu testen.

hi

bei manchen szenarien ist es durchaus nötig.
du sagtes das wenn man die dll ersetzen könnte man auch gleich die exe ersetzen.
stimmt. doch wen du sie digital signierst, hast du das gleiche problem. es ist sommit unnötig. weil sich die zert. spoofen lassen. bzw. sich leicht eine vertrauenswürdiges zertifikat beschafen lässt.
ich habe für solche sachen meine eigenen methoden...die weot über zertfikate und hash hinausgehen.

lowbyte

Hi

@M17

Sorry wollte mich hier nicht profilieren. Mein Methoden brauchen dich ja auch nicht zu intressieren. Es ging ja eigentlich um das Sicherheitsproblem mit "LoadLibrary()" und "DLL-Suchpfad und /DELAYLOAD". Das eigentliche Problem ist wenn die DLL von einem Netzlaufwerk geladen wird, dann ist es nämlich egal ob die DLL digital Signiert ist oder nicht, da sie theoretisch gespooft oder beschaft werden kann. Dann wäre man froh hätte man ein Hash, den man prüfen könnte. Ist ja keine grosse Sache sowas implementieren. Und ich denke bei den paar DLL's die verwendet werden von einer Software, ist es ja nicht die Hölle sowas beim nächsten Update-Zyklus zu patchen.

Bei einer Malware die sich zbsp. über ein geöffneten E-Mail Anhang einschleichen würde, um dan die DLL in dein Proc/Directory zu kopieren, wären deine Ansichten Komplett richtig, da der Malware bei Vista/Win7 die Richlinien in die Quere kommen (Ausser er bricht über eine Sicherheitslücke ins System ein). UAC gibts nätürlich bei XP/2000 nicht, daher wird er sich dort sowiso einschleichen.

Im grossen und ganzen eine ganz grosse ******* ! Ich kann es nicht anders beschreiben. VLC und ein anderen Hersteller den ich gerade vergessen habe, bieten bereits ein Patch an. Man kann nur hoffen das andere Hersteller schnell folgen werden.

lowbyte

Martin Richter

m17 schrieb:

http://www.heise.de/security/meldung/Malware-von-Amts-wegen-vertrauenswuerdig-Update-1026771.html

Und nun?

Das ist ein Problem! Definitiv!

Wir prüfen auch den Namen des Zertifikat-Gebers. Also ob wir oder die Firma von der wir ein Tool beziehen bekannt und korrekt ist.
Für ein Addin System wäre dies jedoch problematisch....

Grundsätzlich:
Aber nichts ist leichter zu blocken und zu erkennen als ein Modul, dass mit einem "gefälschten" Zertifikat versehen wurde.
Viren können "mutieren". Zertifikate sind doch eher begrenzt. Ist ein Zertifikat einmal verbrannt muss man ein neues haben. Nichts ist leichter für einen Virenscanner Zertifikate zu testen und "gefälschte/gestohlene" ein für alle Mal zu blockieren. Mutationen sind ausgeschlossen...

Irgendwo habe ich mal eine ähnliche disskussion angestoßen und zwar wie überprüft man ob das Programm durch mein Zertifikat signiert wurde? Ich meine ich kann ja auch meine eigene CA aufsetzen und in windows installieren und dann sagen mir die Windows Funktionen auch das es eine gültig signierte Datei ist.

So wie ich mir den PE-Header angeguckt habe, dürfte es auch nicht sonderlich schwer sein eine digitale Signatur auszutauschen. Und einen ggf. gespeicherten Hash auszutauschen per Hexeditor. Wie schützt man sich davor?

Martin Richter

Denn Namen des Zertifikates kannst Du ermitteln. Siehe WinTrust Doku CERT_NAME_SIMPLE_DISPLAY_TYPE

Danke für den Tipp!