You can't contain me: elevation-of-privilege vulnerability in Docker for Windows | Hacker News Reader

You can't contain me: elevation-of-privilege vulnerability in Docker for Windows

srcincite.io

144 pointsingve46 comments

On Linux, at least, being able to access the docker daemon (i.e. being in the docket group) is essentially equivalent to being root, in that there are trivial ways to become root if you can start an arbitrary container (e.g. bind-mounting / into a container).

So, it’s perhaps unclear how this exploit is significantly worse. Yes, you get access to SYSTEM, but Docker’s permission model appears to be predominantly “if you can control Docker then you own the machine”. Is this not the case on Windows?

The difference as I understand it is documentation. For Linux, the Docker docs make it abundantly clear what the security model is - don’t give access to the daemon socket to anyone you don’t trust to be root.

For Windows on the other hand there seems to be no official documentation on the topic. Instead some “unofficial” documentation has popped up to fill the void, making insecure recommendations in the process. This then becomes Docker’s problem.

I think it’s a good general lesson for documenting a platform: in the end you are responsible not only for what you explain to your users, but also for what they explain to each other. This can be frustrating because it makes you responsible for something you cannot control, like Docker couldn’t control the recommendations on that github thread. But you are still on the hook for addressing it - in this case probably by filling the gap in official documentation.

> This can be frustrating because it makes you responsible for something you cannot control

If bad recommendations are a product of bad/non-existent documentation then that very much is something you can control and a direct consequence of that neglect.

If docker couldn't be bothered the blame should not be with the bad recommendations.

If you can control Docker, you can do what Docker does. But Docker doesn’t need to be able to do everything (as long as you’re sure that you’ll never need to run a container that needs to do those things.) Specifically, you can run the Docker daemon itself under any combination of cgroup+namespace restrictions (i.e. “in a container”, though not usually in the sense of running Docker in Docker.)

Sadly, many docker images you might want to try fail when run under Docker running in a unprivileged container.

> you can run the Docker daemon itself under any combination of cgroup+namespace restrictions

Not really though. The docker daemon needs access to the mount call, so it either must be root or root within its namespace.

It's incredibly difficult to remove any meaningful permissions from the docker daemon.

This is true to run any container, not just one that has bindmounts.

The docker daemon was not built to be anything but root, and running it as "docker in docker" only works with "--privileged", which is to say, with no security restrictions.

> Docker at first denied a vulnerability existed at all, but later patched it on July 19th. After further discussions, they assigned CVE-2018-15514 on the 18th August.

It’s frustrating that this is the default reaction. I know why it occurs, at least from a human psychological standpoint, but it’s still frustrating. I’ve reported vulnerabilities without response, only to find them thanklessly fixed later. Without reply. But most of the time, my notifications are ignored. It becomes depressing very quickly.

Are there possible legal consequences to acknowledging such a report, though? Maybe it's not just psychological, but a CYA move.

It's unlikely. Many companies handle this sort of thing every day and don't deny the issue, just delay confirmation. It's more likely that someone within Docker decided that they didn't believe the report, but didn't bother to investigate properly before responding.

Generally no, there is minimal liability attached to acknowledging a report. There may be internal political issues and definitely external media ones, though.

Nobody wants to be the person who says "We're vulnerable, but I don't care enough to fix it". That's how you get internal political battles. Denial solves that problem.

When dealing with external reports, it means ammunition for dealing with third parties. "We are not aware of any such vulnerabilities" becomes a defensible position, as does telling reporters that you dispute the claims of vulnerability. Those buy time to maybe fix something.

And, well, there's the CYA psychology too. Nobody wants to confront the idea that they, or their smart and hard-working coworkers, screwed up to the point of creating a significant vulnerability.

Something similar happened to me with Amazon a while back. Found some vulns, and they fixed them but never publicly acknowledged them - because they said "the cloud is always patched", so no need to tell anyone- which I thought was an odd response.

Same for the RocketChat developers: https://github.com/RocketChat/Rocket.Chat/pull/10793

"We do not disclose security fixes as soon we have them fixed to prevent bad guys to exploit them."

"as soon we have" means never.

They believe bad guys would not monitor the commits of target products.

Not disclosing in release change logs potentially increase the chance of people being affected.

If I see a changelog with XSS fixed I will update a product straight away, if I don't - I might leave it a week or two until I have time.

I had a similar experience a few years back with Google (specifically the Android security team). Eager to get the issue fixed, but not in public disclosure or acknowledgement.

Personally I've been turned off by Docker the company on numerous occasions. (Still love docker the project)

Are there any inroads to a truly open source implementation of Docker for Mac and Windows? (Though I assume running a Linux VM would suffice?) It seems unfortunate that the default is running a non-open binary.

What is that about?

    - 2018-04-03 - Verified existing and sent to iDefense’s VCP
    - 2018-04-04 - Validated and acquired by iDefense

Is there a company that buys information about bugs ahead of time so they can protect their clients?

(a cursory Internet search didn't answer my question)

Is there a company that buys information about bugs ahead of time so they can protect their clients?

Companies like Zerodium act as brokers for 0-day exploits, but they tend to sell only to government agencies and the like.

https://zerodium.com/about.html

And iDefense is doing something similar?

They are more "security alerts as a service":

https://searchsecurity.techtarget.com/feature/VeriSign-iDefe...

Gee. Is that really ethical?

Presumably their customers don't intend to patch the bugs without help from the vendor. They likely intend to exploit the bugs (in the name of state surveillance). Many/most global governments (all?) aren't trustworthy in this regard. If you disclose a bug to Zerodium, can you trust them not to have "bad" governments as customers? Also, consider a Sybil attack: Zerodium is an untrustworthy government front.

> ZERODIUM customers are mainly government organizations in need of specific and tailored cybersecurity capabilities, as well as major corporations from defense, technology, and financial sectors, in need of protective solutions to defend against zero-day attacks.

shrug, okay, I hope that's the case.

Reply on news.ycombinator.com