Should format string and memory safety reqs be Level 1?

[tghosth]

We currently have an explanation of the thinking around L1 which can be found here.

There are a few major areas where we have differing opinions about whether a particular type of control falls into the category of L1 for version 5.0.

This issue is to discuss format string and memory safety requirements from the current chapter 5.

The requirements being considered for L1 are below (ignore the level marking below).

#	Description	L1	L2	L3	CWE
5.2.13	[MODIFIED, MOVED FROM 5.4.2] Verify that format strings which might resolve in an unexpected or malicious way when used are sanitized before being processed.		✓	✓	134
5.4.1	Verify that the application uses memory-safe string, safer memory copy and pointer arithmetic to detect or prevent stack, buffer, or heap overflows.		✓	✓	120
5.4.3	Verify that sign, range, and input validation techniques are used to prevent integer overflows.		✓	✓	190
5.4.4	[ADDED] Verify that dynamically allocated memory and resources are properly released, and that references or pointers to freed memory are removed or set to null to prevent dangling pointers and use-after-free vulnerabilities.		✓	✓	416

Personally I am a little split on this issue.

On the one hand, memory safety issues still seem very prevalent as do format string vulnerabilities. These are considered relatively basic having been around for years and the fixes require more defensive coding but are less labour insensitive than some other requirements that might have a wider process or business impact.

On the other hand, how many web applications (which is the scope of ASVS) are written in non-memory safe code. Does that make these requirements too niche to make it into L1.

[jmanico]

My initial reaction is to agree that memory issues are mostly not a web thing, but that is changing:

• Memory vulnerabilities are absolutely relevant when discussing WebAssembly. Wasm brings languages like C and C++ into the web world. (Out-of-Bounds Read/Write in WebAssembly)
• Years and years of Java PermGen issues to fight.
• Memory leaks in Node.js
• Spectre and Meltdown impacting browsers and servers
• Resource Abuse Attacks: Tools like slowloris or XML Bombs