[Breaking change]: .NET 9 enables CET support by default

[janvorli]

Description

In .NET 9 Preview 6, the apphost and singlefilehost started to be marked as Intel CET compatible (they are compiled with /CETCOMPAT option). It was done to enhance security of .NET applications. That imposes a limitation on shared libraries that .NET applications can load and interop with. They are not allowed to set thread context to a location with instruction pointer that is not present on the shadow stack or in a table of allowed continuation addresses for exception handling.

Version

Other (please put exact version in description textbox)

Previous behavior

Shared libraries loaded into .NET process were able to set thread context using SetThreadContext, RtlRestoreContext/NtContinue or using their exception handlers to any location in the process address space.

New behavior

Shared libraries loaded into .NET process are only allowed to set thread context using SetThreadContext, RtlRestoreContext/NtContinue or using their exception handlers to locations that are present on the shadow stack or in a table of allowed continuation addresses for exception handling (generated by /EHCONT compiler option or the SetProcessDynamicEHContinuationTargets API). Trying to change a thread context to any other location results in termination of the process.

Type of breaking change

• Binary incompatible: Existing binaries might encounter a breaking change in behavior, such as failure to load or execute, and if so, require recompilation.
• Source incompatible: When recompiled using the new SDK or component or to target the new runtime, existing source code might require source changes to compile successfully.
• Behavioral change: Existing binaries might behave differently at run time.

Reason for change

Enabling CET for .NET applications enhance the security of the .NET applications by adding hardware-enforced stack protection that offers robust protection against ROP exploits (return oriented programming).

Recommended action

Workarounds:

• Adding <CETCompat>false</CETCompat> to the .csproj of the application opts out of the CET
• Use the Windows Security app, group policy etc. to opt out of the hardware supported stack enforcement for the specific .NET application as described in https://learn.microsoft.com/en-us/defender-endpoint/enable-exploit-protection for details.

Feature area

Interop

Affected APIs

No response

---

Associated WorkItem - 320279

[jkotas]

In the description, we can include a link to https://techcommunity.microsoft.com/t5/windows-os-platform-blog/developer-guidance-for-hardware-enforced-stack-protection/ba-p/2163340 that provides additional technical details.

The primary recommended actions should be ones that do not compromise security: fix the native library to be CET compatible, or to request the fix from the native library maintainer; or avoid dependency on the offending native library.