Windows executables: only load imported DLLs from System32

[AustinWise]

By using the /DEPENDENTLOADFLAG link.exe flag, we can tell the Windows loader to only look for referenced DLLs in the System32 directory. This prevents DLL injection.

While this would not have prevented this month's CVE (see #84637), it could prevent DLL injection bugs from being introduced in native code.

Questions

Is there a better way to apply this flag in the CMake files? Ideally it would be the default and tests that don't work with it would opt out.

When I added this flag, I got this error message from LINK.exe:

LINK : fatal error LNK1268: inconsistent option 'DEPENDENTLOADFLAG:0x800' specified with /USEPROFILE but not with /GENPROFILE

How can this be worked around? Currently I have commented out applying PGO to make the build pass.

[ghost]

Tagging subscribers to this area: @hoyosjs
See info in area-owners.md if you want to be subscribed.

Issue Details

---

By using the /DEPENDENTLOADFLAG link.exe flag, we can tell the Windows loader to only look for referenced DLLs in the System32 directory. This prevents DLL injection.

While this would not have prevented this month's CVE (see #84637), it could prevent DLL injection bugs from being introduced in native code.

To demonstrate the effectiveness of this approach, this PR is split into 3 commits. The first adds a test for DLL injection. The second reverts the delay loading for version.dll introduced in dotnet/coreclr#24449. The this causes the test to fail. Lastly the /DEPENDENTLOADFLAG flag is added and the test starts passing again.

Author:	AustinWise
Assignees:	-
Labels:	area-Infrastructure-coreclr, community-contribution
Milestone:	-

[AustinWise]

Leaving this as draft for now to see if it breaks anything.

[jkotas]

/DEPENDENTLOADFLAG

The docs say that this flag is effective on newer Windows 10 RS1+ only. It does not hurt to add it, but I do not think we can depend on it as long as we support Windows Server 2012: https://github.com/dotnet/core/blob/main/release-notes/8.0/supported-os.md#windows. I would expect the tests to fail on Windows Server 2012.

[AustinWise]

I finally got a chance to look at the failures. It appears that some tests (like for IJW) are impacted by this change. I think I will rework this to only target the main product DLLs and EXEs, like coreclr.dll and dotnet.exe.

/DEPENDENTLOADFLAG

The docs say that this flag is effective on newer Windows 10 RS1+ only. It does not hurt to add it, but I do not think we can depend on it as long as we support Windows Server 2012: https://github.com/dotnet/core/blob/main/release-notes/8.0/supported-os.md#windows. I would expect the tests to fail on Windows Server 2012.

Opps, I did not check the minimum server version of Windows. In that case I will revert the changes to delay loading version.dll and let this be a defense-in-depth change before I mark this ready for review.

[AustinWise]

I removed the test because it was pretty hacky. I think the ideal test would enumerate all loaded modules and make sure this flag is set in non-operating-systems module. I'm not 100% sure on how to write such a test.

In the absence of tests, I manually verified that the follow executable have the dependent load flag using LINK.EXE /DUMP /HEADERS /LOADCONFIG file.dll:

• coreclr.dll
• clrjit.dll
• createdump.exe
• apphost.exe
• dotnet.exe
• singlefilehost.exe
• comhost.dll
• hostfxr.dll
• hostpolicy.dll
• ijwhost.dll
• nethost.dll

Which I think covers the main product executables.

[AustinWise]

I wrote a program to check for files missing this flag:

https://github.com/AustinWise/CheckDependentLoadFlags

I'm satisfied that I've covered the main product DLLs, so I will open this for review.

[elinor-fung]

cc @blowdart @GrabYourPitchforks

[AustinWise]

I identified some further revision I'd like to do, so I'm marking this as draft again. Sorry for the churn.

[ghost]

Draft Pull Request was automatically closed for 30 days of inactivity. Please let us know if you'd like to reopen it.