VNX-932: Source code switches off stack protection or FORTIFY_SOURCE

Field	Value
Rule ID	VNX-932
Severity	Low
SARIF level	note
Kind	sast
Languages	C, C++
CWE	CWE-932
CAPEC	CAPEC-66
ATT&CK	T1190
CWSS vector	CWSS:1.0/TI:L/AP:RU/AL:S/IC:N/FC:LT/RP:RU/RL:S/AV:L/AS:N/IN:A/SC:A/BI:L/DI:H/EX:L/EC:N/P:L
Tags	os-hardening c cpp cwe-932
Source	internal/sast/rules/vnx-932.rego

Overview

CWE-932 is an OWASP Top Ten 2013 category with no code shape of its own; this rule reports the concrete C/C++ hardening signal it was generated for, source that turns off a compiler memory-safety defence for the code that follows: #pragma GCC/clang optimize(“no-stack-protector”/“-fno-stack-protector”), attribute((no_stack_protector)), attribute((optimize(“no-stack-protector”))), [[gnu::no_stack_protector]], #undef _FORTIFY_SOURCE that is not followed by a non-zero redefinition, #define _FORTIFY_SOURCE 0, and MSVC #pragma strict_gs_check(off) and __declspec(safebuffers). Not reported: optimisation-level pragmas and attributes (O0, O2, O3; optimize(“O0”) is the usual secure-zeroing idiom), _FORTIFY_SOURCE set to 1-3, comments and strings, and test or fuzzing code. Build-system flags (-fno-stack-protector in a Makefile) are out of scope.

Why This Matters

Stack canaries, FORTIFY_SOURCE and MSVC /GS stop many buffer overflows from turning into code execution. Switching them off in source silently removes that protection from the code that follows, whatever the build flags say.

What Gets Flagged

#pragma GCC optimize ("no-stack-protector")
__attribute__((no_stack_protector)) void decode(const char *in, char *buf) {
[[gnu::no_stack_protector]] int scan(char *line);
#undef _FORTIFY_SOURCE
#define _FORTIFY_SOURCE 0
#pragma strict_gs_check(off)
__declspec(safebuffers) void copy_name(char *dst, const char *src) {

What Is Not Flagged

#pragma GCC optimize ("O2")
__attribute__((optimize("O0"))) void secure_zero(void *p, size_t n);
#undef _FORTIFY_SOURCE
#define _FORTIFY_SOURCE 3

Remediation

1. Remove the pragma or attribute and fix whatever made it necessary.
2. Confine it to code that runs before the stack canary is initialised (early boot, a TLS setup routine) and document why.
3. For a confirmed false positive, add a vulnetix-ignore: VNX-932 comment on the line.

References

• CWE-932
• GCC: Instrumentation options (-fstack-protector)

Suppressing this rule

Put a nosec comment on the line, or on line 1 to cover the whole file. Use the comment marker of the file’s language (#, //, -- or ;):

# nosec vnx-932
// nosec vnx-932

Or record an ignore rule: vulnetix ignore add --rule vnx-932 --reason "...". See Suppressing findings.