
Dirty COW Docker Container Escape - josephscott
https://blog.paranoidsoftware.com/dirty-cow-cve-2016-5195-docker-container-escape/
======
hinkley
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
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.

------
pmontra
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
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.

~~~
majewsky
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.

