News for hackers. Stuff that matters.
Re:Quantitative analysis of issues found by afl in mandoc by baby on Friday June 19, 2015 @03:37PM (#9747146)
> abuse of assert() for input validation

Does anyone know what he's talking about?

Re:Quantitative analysis of issues found by afl in mandoc by mje__ on Friday June 19, 2015 @03:53PM (#9747239)
assert() is a macro that is usually disabled in production builds. Input validation is obviously most important in production, so assert() should never be used for validation.
Re:Quantitative analysis of issues found by afl in mandoc by KerrickStaley on Friday June 19, 2015 @07:36PM (#9748311)
assert() is a macro that will print an error message and abort the program if its argument doesn't evaluate to true.

assert() is usually used in debug builds to verify internal invariants of the code: "if this is false, something has gone horribly, terribly wrong; we've gone crazy and we should abort to avoid further hurting ourselves or others". It shouldn't be used to verify that user input is well-formed, since this happens under normal circumstances.

Re:Quantitative analysis of issues found by afl in mandoc by RickHull on Saturday June 20, 2015 @03:04AM (#9749260)
Furthermore, assert is specifically intended to catch internal logic bugs which would still be present even after user input validation. i.e. logic bugs which are invariant upon user input
Re:Quantitative analysis of issues found by afl in mandoc by strommen on Friday June 19, 2015 @06:21PM (#9748025)
The 7 most-severe bugs were specifically related to reading/writing the wrong place in memory. These are impossible bugs to have in managed-memory environments.

It is absolute madness to use C or C++ in a security-critical system.

Re:Quantitative analysis of issues found by afl in mandoc by xyzzy123 on Saturday June 20, 2015 @03:22AM (#9749275)
Except for maybe the kernel, libc, the browser, drivers, widely used server software, emulator suites, the window system, the office suite you have to use, the runtime libraries for the high level languages you use, and so on. </s>

(Hmm, perhaps I'm making your point for you? ...)

One thing I have noticed though is that replacing manual with automatic memory management often doesn't help as much as one might think. The bugs just tend to shift to other areas (e.g. memory corruption -> command execution, XSS or XXE etc).

I think this is because with a more forgiving language, developers tend to naturally create more complex systems. Like how car drivers go faster when they feel safer in their car.