33 ms·

Probably only off by an order of magnitude. Check out Dmitry’s szykaller slides. https://events.linuxfoundation.org/wp-content/uploads/2017/11/Syzbot-and-the-

Probably only off by an order of magnitude. Check out Dmitry’s szykaller slides. https://events.linuxfoundation.org/wp-content/uploads/2017/11/Syzbot-and-the-Tale-of-Thousand-Kernel-Bugs-Dmitry-Vyukov-Google.pdf https://events.linuxfoundation.org/wp-content/uploads/2017/1... Edit: I missed the “RCE” context. Most of these are just privescs or memory disclosures.

loeg 8y ago
Yes. For RCEs, it's hard to accurately compute, but probably off by at least two orders of magnitude (charitably).
pizlonator 8y ago
Wasn’t even serious about this, but now that y’all are playing along, I’ll just dig in for fun. It’s interesting that Linux kernel bug stats contradict my bold bet. But I’m imagining rando C code here, not necessarily open source, not necessarily in the kernel, not necessarily tested and reviewed the same way. This code is at least open source but I dunno to what extent this newly added code path in runc gets the kind of shaking out that makes kernel code solid. Runc aside, I expect most C code to have a higher rate of every kind of bug than the kernel.
- TheDong 8y ago
  Large swathes of C code can't have an RCE by definition. Any C code which is not available on the network (e.g. C code running on your refrigerator) by definition cannot have a remote code execution vulnerability. Lots of software, such as the 'top' utility, makes no networking related calls in the codebase, so any instances of bugs would be buffer overflows or crashes, but not remotely exploitable by the usual meaning. I think that you vastly under-estimate how difficult it is to accidentally write a remotely exploitable bug. Sure, buffer overflows and undefined behavior happen all the time in C code. Those bugs might be 1 per 100 lines even in the average C code. of those, hardly any will be network exploitable. Relatively little code will be handling data sourced from the network.
  - pizlonator 8y ago
    That's sort of literally true except that it's hard to predict how code will be used in the future. For example, I bet that some dude writing an image decoder in the 90's was thinking "it's cool, I don't have to worry about security" because he just knew that his code wasn't going to be remotely exploitable. Anyway, my original comment was supposed to be as funny as your handle. I guess the humor ended up being just in how seriously folks took it. The part I'm not joking about is that folks always underestimate the amount of security bugs that will be found in a piece of code in the future, either because the code ends up used in a way that wasn't predicted, or because some really great bug was just waiting for the right kind of genius to uncover it.

loeg 8y ago

Yes. For RCEs, it's hard to accurately compute, but probably off by at least two orders of magnitude (charitably).

pizlonator 8y ago

Wasn’t even serious about this, but now that y’all are playing along, I’ll just dig in for fun. It’s interesting that Linux kernel bug stats contradict my bold bet. But I’m imagining rando C code here, not necessarily open source, not necessarily in the kernel, not necessarily tested and reviewed the same way. This code is at least open source but I dunno to what extent this newly added code path in runc gets the kind of shaking out that makes kernel code solid. Runc aside, I expect most C code to have a higher rate of every kind of bug than the kernel.

TheDong 8y ago
Large swathes of C code can't have an RCE by definition. Any C code which is not available on the network (e.g. C code running on your refrigerator) by definition cannot have a remote code execution vulnerability. Lots of software, such as the 'top' utility, makes no networking related calls in the codebase, so any instances of bugs would be buffer overflows or crashes, but not remotely exploitable by the usual meaning. I think that you vastly under-estimate how difficult it is to accidentally write a remotely exploitable bug. Sure, buffer overflows and undefined behavior happen all the time in C code. Those bugs might be 1 per 100 lines even in the average C code. of those, hardly any will be network exploitable. Relatively little code will be handling data sourced from the network.
- pizlonator 8y ago
  That's sort of literally true except that it's hard to predict how code will be used in the future. For example, I bet that some dude writing an image decoder in the 90's was thinking "it's cool, I don't have to worry about security" because he just knew that his code wasn't going to be remotely exploitable. Anyway, my original comment was supposed to be as funny as your handle. I guess the humor ended up being just in how seriously folks took it. The part I'm not joking about is that folks always underestimate the amount of security bugs that will be found in a piece of code in the future, either because the code ends up used in a way that wasn't predicted, or because some really great bug was just waiting for the right kind of genius to uncover it.