3 ms·
Whenever I see a C networking library, my first questions are: 1. How many security-critical CVEs has it had in the past? 2. How extensively has it been fuzze
by ekidd 9y ago
Whenever I see a C networking library, my first questions are:
1. How many security-critical CVEs has it had in the past?
2. How extensively has it been fuzzed?
3. Is this one of the rare C code bases that actually has pretty solid security (like Dovecot https://www.helpnetsecurity.com/2017/01/17/dovecot-security-audit/ https://www.helpnetsecurity.com/2017/01/17/dovecot-security-... or various OpenBSD tools)?
I ask because once upon a time I just about broke my heart trying to write secure networking code in C. I inspected every line. I chose my dependencies carefully. I wrote extensive, malicious tests with tons of malformed data. I added recursion limits to prevent stack overflow. I ran everything through Electric Fence and used the best open source validation tools available in 2001. And despite months of effort for a very simple protocol, I wound up being affected by at least 6 CVEs in 15 years (http://people.canonical.com/~ubuntu-security/cve/pkg/xmlrpc-c.html http://people.canonical.com/~ubuntu-security/cve/pkg/xmlrpc-...), many of them in the third-party XML parser I used. But if somebody directly fuzzed my code, I bet they'd find at least one more issue somewhere.
There are a few people I trust to write mostly secure networking software in C. But the more time I spend fuzzing protocol parsers, the more I realize that—even though I like to think I'm unusually careful and paranoid—I'll never be one of those people.
So how does libhttp look from a security perspective? If it's truly paranoid and thoroughly fuzzed, it might be very useful for embedded work.
- duneroadrunner 9y ago> (http://people.canonical.com/~ubuntu-security/cve/pkg/xmlrpc-... http://people.canonical.com/~ubuntu-security/cve/pkg/xmlrpc-...) It looks like some of those CVEs are dated not that long ago. If code safety is still a concern with this project, you/someone might consider conversion to SaferCPlusPlus (essentially a memory-safe subset of C++). There is an "auto-conversion helper tool"[1] still in development, but already functional. [1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus-AutoTranslation https://github.com/duneroadrunner/SaferCPlusPlus-AutoTransla... (Feel free to post any questions to the github "issues" section.)
- ekidd 9y ago> If code safety is still a concern with this project, you/someone might consider conversion to SaferCPlusPlus (essentially a memory-safe subset of C++). Thank you for the pointer! I haven't been a maintainer of xmlrpc-c in over a decade now, and I'm not even sure who's maintaining it or using it. The sourceforge mailing list archives seem to be down, so I have no way to contact the current maintainers. The packages in Ubuntu which use xmlrpc-c are freeipa-client, rtorrent, opennebula, certmonger, flowgrind and cobbler-enlist. I also remember 2 or 3 commercial users from 15 years ago. If any of these people are interested, I'd consider writing a drop-in replacement in Rust that preserves the same C ABI, and spend at least a week of CPU time fuzzing it.