5 ms·

Yikes that's a big patch! Just on a meta-level, security vulnerabilities fixed with big patches are usually the least fun. Also, I would bet that freshly writ

Yikes that's a big patch! Just on a meta-level, security vulnerabilities fixed with big patches are usually the least fun. Also, I would bet that freshly written C code has about 1 RCE bug every 100 LoC. This patch has 236 LoCs so probably about 2.36 RCE's.

loeg 8y ago
1 RCE bug per 100 LoC feels like a very high bet. How did you arrive at that number? I've heard 1 bug per 100 LoC before, but RCEs are a very specific subset of bugs.
- pizlonator 8y ago
  Yeah, I was joking. But not completely. Even if you leave a codebase alone in the sense that you only fix security bugs, you’ll end up with a slow trickle that never quite ends. There are the RCEs that get reported plus a bunch that don’t. So, if you: - project into the future, assuming that if there still has been a trickle of bugs being found then more bugs will also still be found in the future. - take into account that there are some number of unreported bugs. Maybe for every reported one there is one that isn’t. Dunno the ratio there. Put all that together and it’s not hard to imagine a 1RCE/100LoC rate. But still I’m kinda joking. But only slightly. Maybe if I had a way to bet money on this and it was a testable bet (it’s not because of the unreported RCEs) then I’d throw some cash down.
megous 8y ago
By your guess each new Linux release would have about 5000 new RCEs. So that's 25000-30000 new RCEs over the last year alone.
- ebeip90 8y ago
  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.
- pizlonator 8y ago
  I wasn’t being completely serious. But taking the joke further, are you counting each release’s lines of code towards the RCEs or only new/modified code? If you’re counting all vise then you’re double counting RCEs. I wouldn’t double count.
  - megous 8y ago
    New lines only. It's approx half a mil. new lines of code in each recent release.
- pjmlp 8y ago
  In 2018, 68% of Linux CVEs were caused by C's memory corruption features. Source, Google talk at Linux Kernel Summit 2018.
  - wahern 8y ago
    And how many of those were related to the difficulty of managing IPC across user/kernel boundaries, DMA, mbuf-based networking code, eBPF JIT'ing, etc? So-called memory safe languages don't help with any of that. I'll take your memory safe languages and up the ante with microkernels, which actually help immensely in all those cases. But Linux isn't going to go that route, either.
    - pjmlp 8y ago
      Plenty of them related to lack of bounds checking handling strings and arrays. Google has been pushing for the Kernel Self Preservation project for quite a while now, which Android and ChromeOS make best use of, also a reason why the NDK is so constrained on Android. Security in the kernel also had quite a few talks at Linux Conf 2019, just recently in New Zealand.
  - loeg 8y ago
    68% of N, where N « 30,000.
  - geofft 8y ago
    See also Fish in a Barrel's Twitter account: https://twitter.com/LazyFishBarrel https://twitter.com/LazyFishBarrel The vast majority of security updates these days are memory unsafety. (Fish in a Barrel, LLC is a nonexistent security research "company" consisting of people setting up fuzzers on the weekend and then proceeding to shoot fish in a barrel.)
cyphar 8y ago
The version of the patch pushed to master is significantly simpler[1], and the context in which the code runs is so trivial that standard C vulnerabilities are unlikely to happen (meaning that we are doing IO to a memfd and if any errors happen we abort the process -- and immediately after the C code is set up we either execve or we boot the Go runtime which scrubs over all memory anyway). My first attempts at this patch used Go code but it wasn't possible to protect against all cases. Doing it in C was the only way to do it. [1]: https://github.com/opencontainers/runc/commit/0a8e4117e7f715d5fbeef398405813ce8e88558b https://github.com/opencontainers/runc/commit/0a8e4117e7f715...

loeg 8y ago

1 RCE bug per 100 LoC feels like a very high bet. How did you arrive at that number? I've heard 1 bug per 100 LoC before, but RCEs are a very specific subset of bugs.

pizlonator 8y ago
Yeah, I was joking. But not completely. Even if you leave a codebase alone in the sense that you only fix security bugs, you’ll end up with a slow trickle that never quite ends. There are the RCEs that get reported plus a bunch that don’t. So, if you: - project into the future, assuming that if there still has been a trickle of bugs being found then more bugs will also still be found in the future. - take into account that there are some number of unreported bugs. Maybe for every reported one there is one that isn’t. Dunno the ratio there. Put all that together and it’s not hard to imagine a 1RCE/100LoC rate. But still I’m kinda joking. But only slightly. Maybe if I had a way to bet money on this and it was a testable bet (it’s not because of the unreported RCEs) then I’d throw some cash down.

megous 8y ago

By your guess each new Linux release would have about 5000 new RCEs. So that's 25000-30000 new RCEs over the last year alone.

ebeip90 8y ago
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.
pizlonator 8y ago
I wasn’t being completely serious. But taking the joke further, are you counting each release’s lines of code towards the RCEs or only new/modified code? If you’re counting all vise then you’re double counting RCEs. I wouldn’t double count.
- megous 8y ago
  New lines only. It's approx half a mil. new lines of code in each recent release.
pjmlp 8y ago
In 2018, 68% of Linux CVEs were caused by C's memory corruption features. Source, Google talk at Linux Kernel Summit 2018.
- wahern 8y ago
  And how many of those were related to the difficulty of managing IPC across user/kernel boundaries, DMA, mbuf-based networking code, eBPF JIT'ing, etc? So-called memory safe languages don't help with any of that. I'll take your memory safe languages and up the ante with microkernels, which actually help immensely in all those cases. But Linux isn't going to go that route, either.
  - pjmlp 8y ago
    Plenty of them related to lack of bounds checking handling strings and arrays. Google has been pushing for the Kernel Self Preservation project for quite a while now, which Android and ChromeOS make best use of, also a reason why the NDK is so constrained on Android. Security in the kernel also had quite a few talks at Linux Conf 2019, just recently in New Zealand.
- loeg 8y ago
  68% of N, where N « 30,000.
- geofft 8y ago
  See also Fish in a Barrel's Twitter account: https://twitter.com/LazyFishBarrel https://twitter.com/LazyFishBarrel The vast majority of security updates these days are memory unsafety. (Fish in a Barrel, LLC is a nonexistent security research "company" consisting of people setting up fuzzers on the weekend and then proceeding to shoot fish in a barrel.)

cyphar 8y ago

The version of the patch pushed to master is significantly simpler[1], and the context in which the code runs is so trivial that standard C vulnerabilities are unlikely to happen (meaning that we are doing IO to a memfd and if any errors happen we abort the process -- and immediately after the C code is set up we either execve or we boot the Go runtime which scrubs over all memory anyway). My first attempts at this patch used Go code but it wasn't possible to protect against all cases. Doing it in C was the only way to do it. [1]: https://github.com/opencontainers/runc/commit/0a8e4117e7f715d5fbeef398405813ce8e88558b https://github.com/opencontainers/runc/commit/0a8e4117e7f715...