Conversation

This Tweet was deleted by the Tweet author. Learn more

Replying to

If you look through grep's commits, you can see fixes like git.savannah.gnu.org/cgit/grep.git/ and git.savannah.gnu.org/cgit/grep.git/ which did not get a CVE assigned, because it's rare to seek out CVE assignments for each security relevant bug fix. Most projects don't do much of that, or don't at all.

1

1

Replying to

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.

1

1

1

Replying to

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

debdrup@bsd.network

Replying to

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

Replying to

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

Replying to

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

Replying to

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

debdrup@bsd.network

Replying to

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

Replying to

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

Replying to

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.

6:26 PM · Apr 18, 2019Twitter Web Client

Replying to

Computing time is a big deal for fuzzing. There's a drastic difference between a security researcher doing it on their workstation vs. having a massive dedicated server farm running assorted fuzzers against a program. Actually need resources to triage / fix all the bugs too.

1

debdrup@bsd.network

Replying to

The reason why fuzzing makes sense is that compute is so cheap compared to people-power, yes.

debdrup@bsd.network

Replying to

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

Replying to

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.

1

Show replies