6 ms·

Dirty COW Docker Container Escape

24 points by josephscott 10y ago

pmontra 10y ago
It can't be exploited from remote, unless combined with a remote code execution vulnerability. An attack vector could be a "run as docker" application downloaded and run with the idea of sandboxing it. Any other attack scenarioes?
- TheDong 10y ago
  There are also many services like heroku that offer customers a container that's multi-tenent with many other containers. You could break out of yours and examine the filesystem of other's and steal whatever valuables you wish to.
  - pmontra 10y ago
    You are right, I didn't think about that.
  - majewsky 10y ago
    That's why it is considered a best practice to implement multitenancy via VMs: Every customer gets their own set of VMs where their containers are scheduled. If an application breaks out of the container isolation, at least it can only see other stuff from the same customer because the VM offers an additional isolation layer that's more battle-tested.
hinkley 10y ago
There's something that has been bugging me for a long time now. I understand and appreciate the concept of DRY. I use it quite extensively when untangling ratty, convoluted code. But when I see reports like this, and they seem to be coming more regularly these days, maybe there's something slightly wrong with collapsing all of the most critical code in our systems to a single point of failure a couple of bytes wide. If it's not an attacker, it's shitty SSDs, bad PSUs, brownouts, vacuum cleaners or cosmic rays. I don't know what the solution is. Maybe copy all of the important bits early on. Maybe redundant execution with voting. Related but an aside, it's almost perverse that the most important code in my day job is often the code we interact with the least. We spend all of our time and energy touching the inconsequential bits and almost none on the parts that matter the most. I had a situation a couple years ago where one of the bits of code I was most proud of writing, I couldn't recreate it by hand. It had been so long since I touched it that I was forgetting how it worked. All around a troubling realization.
- majewsky 10y ago
  I can see the same problem that you describe in the last paragraph. My team is really "full-stack", dealing with bare-metal compute/network/storage equipment at the bottom end and going up to fancy Rails web apps on the top. The infrastructure parts are relatively understaffed while everyone is working on the applications on top of it, because this is where customer value is perceived. We manage to get by because developers feel the impact of problems in the lower parts of the stack, and start to take greater care of these lower parts, but it's a hard journey.

24 points by josephscott 10y ago

It can't be exploited from remote, unless combined with a remote code execution vulnerability. An attack vector could be a "run as docker" application downloaded and run with the idea of sandboxing it. Any other attack scenarioes?

TheDong 10y ago
There are also many services like heroku that offer customers a container that's multi-tenent with many other containers. You could break out of yours and examine the filesystem of other's and steal whatever valuables you wish to.
- pmontra 10y ago
  You are right, I didn't think about that.
- majewsky 10y ago
  That's why it is considered a best practice to implement multitenancy via VMs: Every customer gets their own set of VMs where their containers are scheduled. If an application breaks out of the container isolation, at least it can only see other stuff from the same customer because the VM offers an additional isolation layer that's more battle-tested.

hinkley 10y ago

There's something that has been bugging me for a long time now. I understand and appreciate the concept of DRY. I use it quite extensively when untangling ratty, convoluted code. But when I see reports like this, and they seem to be coming more regularly these days, maybe there's something slightly wrong with collapsing all of the most critical code in our systems to a single point of failure a couple of bytes wide. If it's not an attacker, it's shitty SSDs, bad PSUs, brownouts, vacuum cleaners or cosmic rays. I don't know what the solution is. Maybe copy all of the important bits early on. Maybe redundant execution with voting. Related but an aside, it's almost perverse that the most important code in my day job is often the code we interact with the least. We spend all of our time and energy touching the inconsequential bits and almost none on the parts that matter the most. I had a situation a couple years ago where one of the bits of code I was most proud of writing, I couldn't recreate it by hand. It had been so long since I touched it that I was forgetting how it worked. All around a troubling realization.

majewsky 10y ago
I can see the same problem that you describe in the last paragraph. My team is really "full-stack", dealing with bare-metal compute/network/storage equipment at the bottom end and going up to fancy Rails web apps on the top. The infrastructure parts are relatively understaffed while everyone is working on the applications on top of it, because this is where customer value is perceived. We manage to get by because developers feel the impact of problems in the lower parts of the stack, and start to take greater care of these lower parts, but it's a hard journey.