Hack Allows Escape of Play-With-Docker Containers (threatpost.com)

secwatcher quotes a report from Threatpost: Researchers hacked the Docker test platform called Play-with-Docker, allowing them to access data and manipulate any test Docker containers running on the host system. The proof-of-concept hack does not impact production Docker instances, according to CyberArk researchers that developed the proof-of-concept attack. "The team was able to escape the container and run code remotely right on the host, which has obvious security implications," wrote researchers in a technical write-up posted Monday.

Play-with-Docker is an open source free in-browser online playground designed to help developers learn how to use containers. While Play-with-Docker has the support of Docker, it was not created by nor is it maintained by the firm. The environment approximates having the Alpine Linux Virtual Machine in browser, allowing users to build and run Docker containers in various configurations. The vulnerability was reported to the developers of the platform on November 6. On January 7, the bug was patched. As for how many instances of Play-with-Docker may have been affected, "CyberArk estimated there were as many as 200 instances of containers running on the platform it analyzed," reports Threatpost. "It also estimates the domain receives 100,000 monthly site visitors."

Comments

Used to think containers & virtualization grea

[Seven Spirals]

Show me a company that's been running VMs or containers for years and I'll likely show you a mess of orphaned guests or containers, oversubscribed hosts, and a management and IT group that's disconnected from their actual resources because they feel they can stretch them forever due to memory balloons, thin disks, HyperThreading||SMT, and other consolidation features that often have a very sharp double edge to them. I'm not saying VMs and containers have no place, I'm just saying they are often a roach motel and often very poorly understood and administered.

Re:Okay, but...

[phantomfive]

OK, imagine you are a dev team, and you don't know how to write an install script for your software. No problem, just load it into docker once, and you don't have to worry about cleaning up your install scripts.

There are some valid use cases, but what I just described is the main one people use in the modern world. There are people who think things like, "Makefiles (or Maven or whatever) are too complicated because they don't allow you to have loops and functions." Nah, these are signs you are making things too complicated and they should be simplified.

Oh, and while I'm criticizing things like an old man, I'll just add that the primary use for mongodb is people who don't know SQL or how to write a schema. That isn't everyone, and there are some valid reasons to use NoSQL, but a primary use case is people who don't know databases.

Re:Okay, but...

[Richard_at_work]

I describe Docker as "an environment in a tin". You don't need to care about setting up full VMs for two bits of software that normally conflict, just run them on the same host under Docker with less overhead than full VMs. Upgrades are trivial as well.

Being able to set up complete development environments (cache, database, reverse proxies, app servers etc) on each developers box with a single command - brilliant. Each developer can develop in an environment which mimics the production environment much more closely these days, because the two environments might indeed be created using the same Docker Compose file.

Docker is brilliant.

But what it isnt, and what pretty much every experienced Docker user will tell you it isnt, is a security system.

Depends.

[Anonymous Coward]

I've worked 3 places since virtualization became mainstream in the early 2000s. In 2003, we mandated that all new systems go onto VMs and mandated that our vendors support it. We were the 25,000 gorilla, so this worked.
A few specialized systems got dedicated hardware because the system was tied to the hardware, but that was the exception, by far.

None of the projects I know about ever oversubscribed VMs, RAM, Storage or networking. Our CPU target was 80%. Before we started virtualizing, the average system utilization was 13%. We had over 60K servers. 5-8% of that utilization was monitoring software. We weren't buying $3K servers either. Most were $25K and up. On my projects we were buying $200K - $5M servers almost always.

Whenever resources are shared, there can be complexities. In general, we treated every VM just like a physical machine and had a chargeback solution so each department paid their share of the costs for power, redundancy, space, storage, CPU, backups, DR, and OS support. Application and DB support was a bill they got directly.

No free rides, usually. Unless some VP signed a contract with penalty clauses for delays in providing infrastructure. That happened a few times and totally screwed every other project being worked. I hope that VP didn't get any bonus for 5 yrs as a lesson on working together, but I fear they got higher bonuses for not spending their own money and for getting their projects in on time - about 300% faster than the people playing by the rules.

For us, the hardest problem was handling SAN storage firmware upgrades. There might be 60 physical systems connected to an EMC which needed new firmware. Those computers might have 200 separate projects, so all of them would need to be moved off to other SAN storage before the original hw could be upgraded. In general, no projects would return to their old computers, so new projects would get placed onto it. Sometimes we'd run out of storage and didn't have physical room inside the data center, so we built another across the street. Just try to explain to a business guy spending $5M on computer hardware that the storage isn't in the same building as their computers, but accessing it was "just as fast". ;)