CVE databases just aren't usable for determining most of the vulnerability fixes going into a project. Linux distributions like Debian relying on CVEs to determine which fixes need to be backported have serious security issues. Greg KH spells this out again and again for Linux.
Conversation
Also, the Linux kernel having far more CVE assignments than say the FreeBSD kernel doesn't mean it's less secure or had more vulnerabilities. In fact, the lack of security research / fuzzing / dynamic analysis being done to find these bugs in other kernels is a very bad thing.
1
1
Minor nit: Nowadays FreeBSD is being both fuzzed by syzkaller and has clang and other analyzers run against it with the analysis target of bmake, as well as coverty doing static analysis.
Still wouldn't be a bad thing to have more security research being done on FreeBSD, though.
1
My point is that there's a whole lot less of it being done, which means fewer bugs are being discovered like this, but it doesn't mean that the bugs aren't there.
Cannot directly compare different projects by CVE assignments especially when most projects rarely seek them out.
1
Memory corruption bugs with security implications are fixed all the time in open source projects and the vast majority of the fixes do not receive CVE assignments. The number of these bugs that are found and fixed also heavily depends on the amount of time being put into that.
1
The Linux kernel has a massive amount of computing resources being thrown at fuzzing with syzkaller with the kernel using KASan and UBSan, along with lots of other fuzzing and security research. The mix of fuzzing with those dynamic analysis features churns out lots of bug finds.
2
Like I said before, syzkaller has also been applied to FreeBSD, and clang implements KA-san and UB-san which is used quite extensively.
1
That's not news to me and I haven't been saying that zero comparable work is being done for FreeBSD... as I said above, my point is that a whole lot less of it is being done. Are you saying that comparable computing hours have been put into fuzzing, with as many fuzzers?
2
Chromium vs. Firefox is another example. Chromium has far more resources put into fuzzing, and finds more bugs. That doesn't mean Chromium has lower code quality or more of these bugs than Firefox. The number of bugs being found has a lot to do with time and effort put into it.
2
There is one big exception, in that by far the most consumers of Chromium are using Chrome on Android or their desktop or laptop, which contains a lot of code not found in Chromium
1
It doesn't contain a lot of code not found in Chromium. Can you list some things that aren't open sourced as part of Chromium for Android or *nix operating systems? It's nearly just a branding swap. It doesn't have an impact on fuzzing the web sandbox, and they do that anyway.
Of course I can't list things which aren't public, but there's at the very least three sources of additional code that I know about: The flash player, Widevine CDM, and NaCL. Additionally, there's also big differnces in multimedia codec support, as well as sandboxing differences.
2
That's not true. NaCL is open source and included in Chromium. The flash player and Widevine are separate plugins and work in Chromium. There are not sandboxing differences. What differences in codec support are you actually talking about? Chromium certainly supports H.264, etc.
2
Show replies