Conversation

This Tweet was deleted by the Tweet author. Learn more

Replying to

No, that's not what he means. He's saying that an external file system should have a sandboxed filesystem driver, so that exploiting a bug inside it doesn't immediately grant complete control over the entire system and at least requires privesc to escape (likely via the kernel).

1

4

Replying to

Try reading the overview in events.linuxfoundation.org/wp-content/upl. Finding a Linux kernel vulnerability is not hard. Literally hundreds of bugs are found by syszkiller every month and many are not fixed. Most are memory corruption. There are simply too many to even fix all discovered bugs.

2

5

Replying to

yes, we don't need to debate the question "can people write memory safe code in C" the answer is overwhelmingly obvious to almost all of us

3

1

18

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.

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

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

Replying to

If someone applies this to another project like GNU grep, they'll find bugs, and unlike GNU grep upstream (and nearly every other open source project) they may decide to regularly get CVE assignments for the memory corruption bugs exposed to attackers.