Hi,
This is in relation to bug #14339 [1] which has been opened for 12
years, and which directly affects the ability of Windows developers to
produce applications that are not subject to DLL side loading
vulnerabilities.
I initially reported this problem on the MinGW mailing list [2] before
discovering that a relevant bug had already been opened for this
specific issue.
Note that, whereas 2 workarounds are known (adding an explicit reference
to the internal call or altering the '__declspec(dllimport)' qualifier),
these are problematic to use in practice (per the notes from the code
sample at [3]) as one can not simply use common 32/64-bit references
since they have different decorations, and trying to alter/remove
'__declspec(dllimport)' can be very tricky for headers that are
themselves included in 'windows.h' (as is the case of 'virtdisk.h' for
MinGW for instance).
As I commented on the bug report, the end result is that this
longstanding bug does have a very detrimental impact on the ability to
produce safe executables on Windows, as the expectation is that
developers will prefer to leave MinGW applications vulnerable to side
loading, rather than invest a lot of time and effort trying to work
around an uncooperative ld...
So, could the priority of this 12 year-old bug be raised?
Thank you,
/Pete
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=14339
[2]
https://sourceforge.net/p/mingw-w64/mailman/mingw-w64-public/thread/ea87573f-65ea-44a2-b4bb-ca96c0a136ab%40akeo.ie/#msg58793876
[3] https://github.com/pbatard/delayload
