Re:Why CVE-2022-3602 was not detected by fuzz testing
by nicoburns on Monday November 21, 2022 @01:45PM
(#33696263)
> The actual solution is that open source, widely used code is a target for hackers.
The long term solution is likely using languages which are A. Memory safe, and B. make formal verification viable. Being widely used and open source isn't an issue if there are no exploitable bugs in the code.
Re:Why CVE-2022-3602 was not detected by fuzz testing
by KingLancelot on Monday November 21, 2022 @03:22PM
(#33697423)
I see a lot of people pushing memory safe languages, far more people than actually write systems code.
What is your primary language?
Re:Why CVE-2022-3602 was not detected by fuzz testing
by pjmlp on Monday November 21, 2022 @03:36PM
(#33697590)
Many of those people have experience writing systems programming code before UNIX and C got widespread outside Bell Labs.
Mac OS was originally written in Object Pascal + Assembly, just to cite one example from several.
Re:Why CVE-2022-3602 was not detected by fuzz testing
by KingLancelot on Monday November 21, 2022 @04:35PM
(#33698305)
Nice deflection, but you still didn’t answer the question.
Have you ever written in a memory safe language like you’re telling others to do?
Re:Why CVE-2022-3602 was not detected by fuzz testing
by pjmlp on Monday November 21, 2022 @05:50PM
(#33699264)
Yes, my dear, plenty of times since 1986.
Turbo Pascal, Turbo Basic, Modula-2, Ada, Oberon, ...
Re:Why CVE-2022-3602 was not detected by fuzz testing
by dang on Monday November 21, 2022 @06:53PM
(#33699894)
Please don't break the site guidelines just because another comment is bad. That only makes things worse.
Re:Why CVE-2022-3602 was not detected by fuzz testing
by dang on Monday November 21, 2022 @06:52PM
(#33699892)
We've banned this account for breaking the site guidelines. Please don't create accounts to do that with. If you've decided you want to use HN as intended, that's fine, but in that case please review https://news.ycombinator.com/newsguidelines.html and be sure you're sticking to the rules.
Re:Why CVE-2022-3602 was not detected by fuzz testing
by nicoburns on Monday November 21, 2022 @06:11PM
(#33699506)
My primary language is JavaScript, but I use Rust when I need to write more low-level (or higher performance) code. I certainly haven't been writing kernel code or anything like that, but I think it's fair to say that I practice what I preach when it comes to using memory safe languages.
Re:Why CVE-2022-3602 was not detected by fuzz testing
by hn_acc_2 on Monday November 21, 2022 @01:59PM
(#33696404)
There are a limited number of people willing to spend a limited amount of time fuzzing, reviewing, and scrutinizing crypto libraries. The more libraries exist, the more their efforts are divided, and the total scrutiny each library receives decreases. How would this help the problem?
Re:Why CVE-2022-3602 was not detected by fuzz testing
by klqwr on Monday November 21, 2022 @06:50PM
(#33699877)
I find it quite brave to trust the OpenBSD guys by default. Historically, they have way too many forked huge projects (Apache, gcc, patched clang, ...) to understand them in depth.
OpenSMPTD had its fair share of exploits. sudo had its fair share of exploits.
All this bickering over language misses the real problem.
The actual solution is that open source, widely used code is a target for hackers.
By using one library used everywhere for everything, you’re painting a target on your own back.
The real solution is we need the software ecosystem to have more competition and decentralization.
Use alternative crypto libraries.
If you want a drop in replacement, use LibreSSL which was forked and cleaned up by the OpenBSD guys due to HeartBleed.
But the long term solution, is more competition by using smaller, more specialized libraries, or even writing your own.