Arno Welzel:
Hier habe ich was gefunden:
<
https://firmwaresecurity.com/tag/rufus/>
Zitat:
"I wish Stefan was less of an <EXPLETIVE> in how he reported it."
Und die Bugmeldung dazu:
<
https://www.openwall.com/lists/oss-security/2018/05/31/1>
Wie üblich also: DLL Injection - die natürlich voraussetzt, dass Malware
*vorher* passend präparierte DLLs plaziert hat. Wenn die Malware das
schafft, braucht sie aber kaum noch eine "Schrottsoftware", um das dann
auszunutzen - sie kann auch einfach selber Admin-Rechte anfordern. Die
Wahrscheinlichkeit, dass ONUs das einfach abnicken, ist recht hoch.
Und ich dachte, es gäbe mal was wirklich ernstes zu berichten wie
Malware im Tool selbst, die dann auf den Stick geschrieben wird o.Ä..
Können wir uns darauf einige, dass Windows selbst(!) unsicher ist
diesbezüglich? LoadLibray() ist nun mal von Microsoft selber(!) so
definiert, dass es keinen absoluten Pfad braucht, sondern ggf. einfach
alles lädt, was in PATH auffindbar ist. Jeden Entwickler unfähig zu
bezeichnen und dessen Software als "üblen Schrott", nur weil sie
LoadLibrary() so benutzen, wie es von Microsoft selber(!) dokumentiert
ist, fördert nicht unbedingt die Akzeptanz einer sinnvollen Maßnahme,
seinen Code abzusichern und LoadLibrary() nur mit konkreten Pfadangaben
zu verwenden.
Siehe auch:
<
https://docs.microsoft.com/en-us/windows/win32/api/libloaderapi/nf-libloaderapi-loadlibrarya>
Zitat:
"When no path is specified, the function searches for loaded modules
whose base name matches the base name of the module to be loaded. If the
name matches, the load succeeds. Otherwise, the function searches for
the file.
The first directory searched is the directory containing the image file
used to create the calling process (for more information, see the
CreateProcess function). Doing this allows private dynamic-link library
(DLL) files associated with a process to be found without adding the
process's installed directory to the PATH environment variable. If a
relative path is specified, the entire relative path is appended to
every token in the DLL search path list. To load a module from a
relative path without searching any other path, use GetFullPathName to
get a nonrelative path and call LoadLibrary with the nonrelative path.
For more information on the DLL search order, see Dynamic-Link Library
Search Order."
Die Angabe eines absoluten Pfades ist nirgends vorgeschrieben. Dass sich
daraus logischerweise als Folge ergibt, dass auch böse DLLs von
Angreifern geladen werden könnten, die statt der erwünschten DLL in
einem Ordner abgelegt werden, die im PATH liegen, ist die Folge davon.
Das müsste Microsoft beheben und nicht die Entwickler von Anwendungen.
Aber Microsoft tut das aus gutem Grund nicht - dann würden nämlich viele
Anwendungen schlicht nicht mehr funktionieren.
Der Zug ist abgefahren - das hätte man schon von Anfang an anders machen
müssen.