Tips for more effective fuzz testing with AFL++

Writing safer C is a matter of skill.

Writing safe C is a matter of either radically different (much, much slower) process or better tooling or both. Skill is not sufficient.

Sometimes writing shitty code is a result of competence, not incompetence. I've seen much better programmers than I ever will be writing terrible code because it was the fastest way to get a prototype running and find out whether the problem was worth writing good code for.

It doesn't really matter, the most skilled programmers are usually working on harder stuff, so the bug rate remains fairly consistent.

I think it's mostly a testing thing. Valgrind is a friend a lot of people haven't heard of for c/c++. Setting up good regression tests is an art. Maintaining them is even harder.

C++ actually has numerous footguns that even experienced developers are completely unaware of. Main reason being is that C++ follows three models in parallel

* the C++ standard

* the CPU arch details

* the OS details

The standard itself delegates a large chunk of functionality to be "platform specific" which will inherently depend either on the CPU or the underlying OS. In fact C++ itself is entirely silent about the ISA other than loosely specifying the virtual machine the language is supposed to run on. So you can get scenarios where some code is perfectly safe on one arch (say alignment doesn't matter) while being severe UB/a failure condition on another (alignment matters and you fault the second you touch misaligned data). There are also other issues like integer over/underflow, fp issues, SIMD issues, memory access issues, stack/heap issues; all of which you MUST address.

Other languages don't quite have these problems because the compiler/runtime handles them and they instead give you a unified interface behind which to write your code.

> It's a matter of how many fucks the devs gave about doing quality work.

It's more a matter of how much management cares about quality, and how much time and how many resources they're willing to devote to it.

And that's a function of how much the quality of the code actually matters in the market.

Has there ever existed a C or C++ codebase of significant size that hasn't had exploitable memory corruption issues? I don't think we can keep saying it's a question of the dev's passion or skill or whatever, if no dev has ever managed to do it.

That's not to say memory corruption issues are the only kind of issues, and rewriting a mature C/C++ codebase into a memory safe language may well introduce more issues than it fixes...

Yea, one of the reasons I rolled my own libc equivalent is how actually awful glibc (and the STL) are. If you actually read the glibc source you'll find countless comments such as "TODO: we need to account for X failure state" or ridiculous UB prone codepaths (signal trampolines, TLS, threading for instance). As in, these are things that can and SHOULD be guarded by the libc itself instead they just allow plain UB to occur.

The STL is awful by extension because it delegates ALL of this work to libc (anything that interacts with the OS) and they integrate this deeply into every single container.