Fix vunerablity to DLL Search Order Hijacking by delay loading version.dll

[AustinWise]

Hypothetically if the user's current directory contains a malicious DLL
named version.dll, this DLL will be loaded instead of the one in System32.

I checked the list of DLLs referenced by rufus.exe against the KnownDLLs
list visible in Sysinternal's winobj.exe. On both Windows 7 and Windows 11,
version.dll was the only DLL not on the KnownDLLs list and thus vunerable
to this attack.

To confirm that this work, I used dumpbin.exe /IMPORTS to make sure
version.dll is delay loaded. I then put a breakpoint in the delay load hook
and confirmed that the hook is used. This can be triggered by loading a
Windows installation ISO file.

I also removed kernel32_path, since kernel32.dll is on the KnownDLLs
list and is not vulnerable to this attack.

For information about KnownDLLs, see this article.
For information about delay-load DLL hooks, see this article

[AustinWise]

This implementation was inspire by dotnet/coreclr@c64a137

[pbatard]

Thanks for the PR.

As you've seen, I've been trying to mitigate these sideloading vulnerabilities, but Microsoft makes it quite difficult to plug them all, especially when linking libraries during compilation (a process which you'd think Microsoft would have hardened by default against side-loading but which they don't).

And as you can also see, trying to service both MSVC and MinGW compilation is tricky, because things that apply to MSVC, such as <DelayLoadDLLs> don't port too well for MinGW (and you should bear in mind that the main executable I release is the MinGW built one rather than the MSVC built one). So far, I'm not seeing a working equivalent of <DelayLoadDLLs> for MinGW, so I fear that the solution will be not not link with version.lib at all, but hook into the DLL at runtime... But if you have other suggestions, I'll take them.

[AustinWise]

Oh, that's too bad. A 10 year old stack overflow post says there is no GCC equivalent, but I'll spend some time next weekend digging into GCC and ld to see if it has grown support in the intervening years.

[pbatard]

Yeah, I saw the same stackoverflow entry, which is why I fear the only solution that'll apply to both compilers is not to link with version.lib, but hook into the relevant version.dll calls at runtime, after we have set the DLL lookup directories and removed current dir.

[AustinWise]

I did figure out a way in MinGW to create a delay-load import library for an existing DLL. See this repo for the complete example:

https://github.com/AustinWise/delay-load-mingw

I'm thinking that the effort involved in maintaining the MSVC compiler flags and generating a custom import library for GCC is more effort than it is worth. I think it is simpler to just LoadLibrary version.dll to call the three functions that Rufus uses from it.

[pbatard]

I'm thinking that the effort involved in maintaining the MSVC compiler flags and generating a custom import library for GCC is more effort than it is worth. I think it is simpler to just LoadLibrary version.dll to call the three functions that Rufus uses from it.

Yes, I agree. I'm planning to take care of that when I have some time. But I'm also still planning to apply your delayed loading proposal for MSVC, as it's definitely something worth to have there.

[pbatard]

Sorry for the delay. I have now altered Rufus so that we manually load the calls we need from version.dll, which should take care of the issue for both MinGW and MSVC. And I have also applied your patch and made sure we set all the libraries we reference as delay loaded in the MSVC project settings. This is most likely and overkill, but since your patch allows us to delay-load, and it shouldn't hurt, we might as well use that feature where we can.

Thanks again for your contribution!