Comment by thomashabets2
3 days ago
Not that remarkable. Nobody in history has been able to write correct C code, and that includes OpenBSD developers.
I pointed an AI at the smallest two tools in OpenBSD I could think of, cat and find, and found multiple bugs. One of which was a buffer overflow (albeit unlikely to be exploitable). IIRC these bugs had existed since at least the NetBSD/OpenBSD split.
Everything in C is UB: https://news.ycombinator.com/item?id=48203698
I looked for bugs in Linux coreutils on a Russian Elbrus PC.
It has a very interesting protected mode of operation where every memory pointer is tagged.
So, I just ran tests and quickly found a number of memory-related bugs.
I’ve submitted some patches, but they were never accepted. These tools’ maintainers seemed very inertial to me. So maybe this is why many (low importance, I assume) issues persists there for a long time.
It’s clear from anyone trying to adopt MTE on ARM that there are just _a lot_ of memory-related bugs all over the place.
Yes. And they are mostly being considered to be unimportant by their maintainers.
Where did you report those coreutils issues?
To some mailing list and to some maintainers. As I recall it was also a separate report for tar. But it’s been 7 years already..
1 reply →
I feel like this is the elephant in the room. People keep acting surprised these large codebases are full of bugs and exploits. C isn't a safe language and moving to safe languages is going to be the only lasting solution.
No language is safe, but I assume you mean memory safety in particular. Alternatives are to formally verify the C code to be memory safe or to add some memory safety features to C. Both certainly simpler and cheaper than rewriting everything.
Whether memory safety is really that important is also not clear. Most people get hacked because they run old software or insecure configurations. So a language such as Rust which creates more supply chain risks seems problematic.
>Nobody in history has been able to write correct C code
Except possibly D.J. Bernstein https://cr.yp.to/ ? Not necessarily all perfect, but designed for extreme simplicity and defense in depth, AFAIU.
It has needed some fixing over the years. errno was one thing. There have been a number of things in that vein, where Bernstein relied upon 1989 C or even K&R semantics and suchlike.
But compared to some other code from the 1990s, it has lasted the test of time quite well.
* https://jdebp.uk/Softwares/djbwares/
He surely also had to face his share of C issues, here advocacy for "Boring C" in 2015,
https://groups.google.com/g/boring-crypto/c/48qa1kWignU/m/o8...
There have been exploitable vulnerabilities in DJB code.
His apps were some of the worst i've ever seen, usability wise.
As I understand, sacrifices were made to achieve the, for C programs, exceptional security.
No. I tried his code too.
Nobody.