You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Enable Security Protocols in MSVC for BinSkim (microsoft#1672)
### Updates
This PR explicitly enables stack protection, control flow guard, CET
shadow stack, and Spectre mitigations to pass BinSkim checks. We also
reorder MSVC compiler options to ensure all binaries, including external
ones such those from ORT Extensions, meet our security standards. Among
other results, this also means warnings will be treated as errors now,
hence we also added external fixes, like this one in ORT Extensions:
microsoft/onnxruntime-extensions#986.
**Stack Protection**
- Our application code should not disable stack protection for
individual functions. The stack protector (/GS) is a security feature of
the Windows native compiler which makes it more difficult to exploit
stack buffer overflow memory corruption vulnerabilities. Disabling the
stack protector, even on a function-by-function basis, can compromise
the security of code.
- This means removing all occurrences of `__declspec(safebuffers)` from
not just our code but also 3rd party source code. Since the latter is
not viable, we explicitly enable stack protection (/GS) to pass BinSkim
checks.
**Control Flow Guard**
- Also, we must enable CFG at build time to prevent attackers from
redirecting execution to unsafe locations. CFG injects a check before
every indirect call to ensure the target is safe. If the check fails,
the OS closes the program.
- To do this, we must pass /guard:cf on both the compiler and linker
command lines. Binaries also require the /DYNAMICBASE linker option in
order to enable CFG. Although we have these set in our Windows CMake
config presets, they may not have worked due to (1) incomplete
propagation (sometimes the flags defined in presets don’t propagate into
all targets or certain configurations like third-party libs,
subprojects, or custom targets), (2) explicit linker flags for our
targets, or (3) static libraries and DLLs. Hence, we explicitly enable
them in our top CMakeLists.txt. This guarantees all targets (DLLs, EXEs,
etc.) get these flags regardless of presets, avoids missing flags due to
custom or overridden flags in some targets, and is easy to audit and
maintain in one place.
**Control-flow Enforcement Technology**
- BinSkim currently throws a warning as we miss the Control-flow
Enforcement Technology (CET) Shadow Stack mitigation.
- To resolve this issue, we must pass /CETCOMPAT on the linker command
lines. Please note however that /CETCOMPAT is not supported on ARM64
machines, so we skip it there; BinSkim also does not require it there.
**Spectre mitigations**
- We also have a BinSkim warning for not enabling code generation
mitigations for speculative execution side-channel attack (Spectre)
vulnerabilities. Spectre attacks can compromise hardware-based
isolation, allowing non-privileged users to retrieve potentially
sensitive data from the CPU cache.
- To resolve the issue, we must provide the /Qspectre switch on the
compiler command-line (or /d2guardspecload in cases where the compiler
supports this switch and it is not possible to update to a toolset that
supports /Qspectre). This warning should be addressed for code that
operates on data that crosses a trust boundary and that can affect
execution, such as parsing untrusted file inputs or processing query
strings of a web request.
### Validation
- [x] Successful local and CI builds
- [x] Following the merging of this PR, we will close our BinSkim TSA
issues, after which TSA automatically scans our code and artifacts for
security issues to ensure the problems are fixed. If they do not
reappear, we are set.
---------
Co-authored-by: Sayan Shaw <[email protected]>
0 commit comments