31–40 of 102 posts
There are nearly 4,000 exposed Docker daemons: https://www.shodan.io/report/ol761bRb
I wonder how many of those 4,000 docker daemons are running/managing containers of dubious origin.
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.
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.
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.
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.
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.
Source, Google talk at Linux Kernel Summit 2018.
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.
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.
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.
Here's link to our security posting with more information and upgrade procedures: https://cloud.google.com/kubernetes-engine/docs/security-bul...
Hey all - Seth from Google here. Please let us know if you have any questions regarding GKE or questions about the upgrade process. I'm also happy to escalate any feedback to our internal product and engineering teams. Here's link to our security posting with more information and upgrade procedures: https://cloud.google.com/kubernetes-engine/docs/security-bul...
Earlier quoted context omitted.
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.
In 2018, 68% of Linux CVEs were caused by C's memory corruption features. Source, Google talk at Linux Kernel Summit 2018.
Earlier quoted context omitted.
Jails are virtually identical technology to Linux containers from a security point of view. They've had holes before and they likely will again, and a breakout like this (seems like the root cause here is a writable file descriptor to the host binary) can absolutely compromise the host system. The upthread recommendation was using hardware VM technology, which is a fundamentally different isolation model from what so…
Sure, but there were 19 years of time proofing them. Each product has vulnerabilities which get weeded out when time passes. And for kata and docker, in context of what they are used for, they are bleeding edge. (from a technical perspective, you would be running jails for years too - so much about platform loyality)
Jails haven't been used to protect as many high-value targets as Linux containers have. This is not a comment on the technical quality of jails. It may well be a comment on the world's anti-FreeBSD prejudice. But either way it's still true, and that means the 19 years of existence didn't magically harden the product.
Earlier quoted context omitted.
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.
Probably only off by an order of magnitude. Check out Dmitry’s szykaller slides. https://events.linuxfoundation.org/wp-content/uploads/2017/1... Edit: I missed the “RCE” context. Most of these are just privescs or memory disclosures.
Earlier quoted context omitted.
Alternative idea: throw away docker and katacontainers and move to freebsd, where jails were introduced on 14 Mar 2000 (no, seriously, superior technology exists for 19 years - stable, time proven, working). Some more info: https://www.freebsd.org/doc/handbook/jails.html And for quick start: https://github.com/iocage/iocage
The major use case for Docker is really as a massively simplified package manager and an entrypoint for distributed applictions. Other features, like quicker runtime than VMs and system isolation, are just icing on the cake. It took a massive marketing campaign to get people to use Docker and realize it made their life easier, so something like iocage would need the same push. (Also, nobody wants to start adopting ad…
Any kind of isolation is just icing on the cake.