Does anyone know if the GNU tools, the coreutils, have been through security audits and fuzzing? They’re the most used tools on the planet, I’d say, and relying on the 90’s “many eyes make all bugs shallow” doesn’t seem to cut it anymore...
We put a lot of effort into the test suite which makes it easy for others to test various experimental security checkers. This has been detailed in the "third party testing" section at: http://www.pixelbeat.org/docs/coreutils-testing.html
wow pretty awesome to see such a QA pipeline in Open Source projects. I'm used to this in expensive R&D pipelines in the Telco space[0]. Is there a reason you're not using oss-fuzz[1]?
I recently did a lot of work using AFL-fast[2] (poking mostly Perl & Lua and crappy IoT products). My experience is that AFL-fast yielded far better results (in a fraction of the time) when compared to AFL.
The «Fuzz Revisited: A Re-examination of the Reliability of UNIX Utilities and Services» paper in 1995 reported on exactly that. It made a bit of a splash at the time because the GNU command-line tools did noticeably better than the commercial ones.
Audits and fuzzing don't really make sense if it's a documented feature. Also the many eyeballs principle seems to hold given that the Debian folks found the bug.
Having said that, a lot of the core command line tools (not just the GNU coreutils) that are run against untrusted input could certainly be improved. I'd prefer the OpenBSD method though - if it can't exec then I don't need to worry about the bugs the auditor/fuzzer didn't find.
FreeBSD's patch runs red, a change we picked up from DragonFly BSD. That said OpenBSD's change to internally handle ed-style diffs is the best approach and I expect FreeBSD will migrate to that.
Amazing how an ancient vuln can still be found hidden in plain sight.