I have a debug mode in my code base, where I wrap malloc, free, and realloc with debug versions that over allocate all allocations that are made, and put magic numbers before and after the memory blocks. These are periodically checked to make sure nothing has been overwritten that shouldn't be. You can find this code on my website, www.gamepipeline.org as part of the "forge" library.
The system tells me very precisely what has gone wrong with buffer over-runs, and it also make memory leaks and double frees trivial to find.
Visual studios debug mode does something similar with buffer overruns on the stack, but I tend not to put very many buffers on the stack so that much more rare as an issue.
If you want to go even more hardcore, windows has "gflags" that you can turn on to find overruns using memory protection.
LLVM also have the "Checked C" compiler that also finds these issues.
My own system is so good that, I haven't used gflags in a few years and I also haven't tested Checked C so I cant vouch for it, but there are loads of possibilities in this space that i hope to explore further in the future.
This testing-based approach is great at finding buffer overflows that occur within your test suite. But especially for code like curl that runs on untrusted data, you need a more adversarial mindset. Unless your tests cover every possible input, a clever attacker might always find input data that you didn't think to test.
These sound good, and I've used things like asan and ubsan which do a lot of the same thing. The issue is not everyone's running in a traditional environment where you have the conveniences of things like... an OS.
I sometimes write code for micro controllers, and I tend to wrap all system calls so that I can run the same code on my PC just to get access to better tools. On small hardware platforms its common that you are forced to use C because of the limited resources, so the options are limited.
The system tells me very precisely what has gone wrong with buffer over-runs, and it also make memory leaks and double frees trivial to find.
Visual studios debug mode does something similar with buffer overruns on the stack, but I tend not to put very many buffers on the stack so that much more rare as an issue.
If you want to go even more hardcore, windows has "gflags" that you can turn on to find overruns using memory protection.
LLVM also have the "Checked C" compiler that also finds these issues.
My own system is so good that, I haven't used gflags in a few years and I also haven't tested Checked C so I cant vouch for it, but there are loads of possibilities in this space that i hope to explore further in the future.