Typical security issues in C++: why the GC isn't your enemy

[Siarhei Siamashka]

On Monday, 5 December 2022 at 19:57:39 UTC, H. S. Teoh wrote:
> D's bounds checks are often touted as a major feature to 
> prevent issues with buffer overflow and out-of-bounds accesses. 
>  Interestingly, "buffer overflow" and "out of bounds..." add up 
> only to about 14% of the total issues.  Nothing to sneeze at, 
> but nonetheless not as big an issue as use-after-free bugs.

This doesn't mean that there are fewer "out of bounds" bugs in 
general. But they are less likely to become exploitable security 
vulnerabilities. The "use after free" bugs are relatively easily 
to exploit:
   1. The old buffer is freed.
   2. This part of memory is later allocated for storing some 
security sensitive information.
   3. Access via the old pointer results in leaking the sensitive 
information.

GC surely helps to mitigate the security aspect of this. But the 
bug in the application logic may still be there and only manifest 
itself as a memory leak (if the application still keeps a pointer 
to the data that is not supposed to be used anymore). A good 
coding practice in C/C++ is to explicitly set a pointer to NULL 
immediately after deallocating memory.

> Integer overflow is also sometimes brought up as something 
> important; but at least according to the above categorization 
> it only accounts for 2% of issues.  So not as big a deal as 
> some may have made it sound.

First, not every bug easily results in an exploitable security 
vulnerability. It's the same as with the "buffer overflow" vs. 
"use after free" case. And more importantly, C/C++ compilers are 
just safer than D compilers when it comes to integer overflows 
detection. Chromium developers are actively using 
[UBSAN](https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html), which even allows detecting unsigned integer overflows:

     -fsanitize=unsigned-integer-overflow: Unsigned integer 
overflow, where the result
     of an unsigned integer computation cannot be represented in 
its type. Unlike signed
     integer overflow, this is not undefined behavior, but it is 
often unintentional.

You can grep Chromium source code for `no_sanitize` or even 
`__attribute__((no_sanitize("unsigned-integer-overflow")))` if 
you don't believe me.

Many of the integer overflow bugs are caught by the C++ compiler 
via UBSAN during the development and never reach the end users. 
While D compilers don't offer any reasonable protection. Except 
for GDC, which supports `-ftrapv` option as an undocumented 
"Easter egg".