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

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". ;)