Slashdot Mirror
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."
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."
WTF is a docker?
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.
We discussed that here: https://yro.slashdot.org/story...
"Go to CNN [for a] spell-checked, fact-checked summary" -- CmdrTaco
Libraries are such a problem that you need virtual filesystems from the developer to actually run their program?
Only the State obtains its revenue by coercion. - Murray Rothbard
never let them escape the container, not even with a hacksaw.
Wait, what?! People actually want to run OS containers... in a browser? Isn't this taking "clientless" a bit far? Play-With indeed.
Play with your own Docker, people, and you won't get infected.
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". ;)
IBM has been doing it properly since the 1980s.
Only the State obtains its revenue by coercion. - Murray Rothbard
I've encountered docker with OpenFoam. For the user, it's a mess. In the setup I experimented with, it used virtualization, so right out of the gate, 10% the performance is gone, in electricity and wasted heat. Docker is an ugly, ugly attempt at cross-platform.
https://www.youtube.com/c/BrendaEM
As a 25 year veteran of DB programming on Oracle, SQL Server, Cassandra, Mongo, I would like to state that you are wrong about that. Sure, some people just don't know how to use a relational database properly, so they go schemaless, but what I like to call an "HR problem, not a technology problem." A lot, if not most, problem domains don't fit the relational model very well. A lot of systems store complex, dynamic hierarchical customer data. My daily job is storing unpredictable user-entered data (dynamic tree structures). My last job was storing healthcare data. For both, document-based databases are a much better fit.
How many transactions have you written that weren't proper transactions, but you simply saving chunks of an object across multiple queries?
How many systems have you written that broke an object across many tables only to reassemble them back in the exact same format, never querying the individual child tables?
If either those are true, it's time to start questioning how much value you're getting from your relational database
Document-based databases are inherently more secure. A relational database returns everything unless you write code to limit it. One mistake or SQL injection and you're leaking data across customers. It leaks data by default and you have to write a WHERE clause to stop that. For a document database, it returns it's single user's document by default. You have to write special code to get data across customers.
For those reasons, despite building a long and very profitable career off Oracle, I recommend it less and less each day, going more for Cassandra and Mongo for a lot of corporate systems. Some portions of an application are clear fits for Oracle, simple systems with very predictable data structures. But I have taken data processing jobs down from minutes to milliseconds by replacing Oracle for dynamic and complex applications for Mongo because their underlying use case was a poor fit for a relational model and an excellent fit for a document model.
Sorry to tell you, but it's far from being just some hipster platform. That technology is in production in some rather security critical environments.
No, I'm not any more happy about it than you are.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
It can be done, but it's far from easy. Docker has SO many attack surfaces that securing them is probably expensive enough that any money you save by lowering your hardware cost is nullified by the amount of money you need to secure it.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
What is the problem? A configuration error? Then it's a non-story, badly configured docker environments are a dime a dozen. A docker bug? Then say so, so we can patch our docker environments. A fundamental flaw in the docker environment that breaks the whole docker-concept for good? NOW you'd have a story!
WTF is it?
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
I've worked with some z/OS boxes before and experienced their virtualization. I agree and haven't seen the same sprawl or crazy growth->neglect->stagnation->waste cycle that I've seen with VMware shops. However, the reasons aren't obvious. I'd say that the licensing costs are too high and the skillset too narrow so it simply doesn't get used to the same degree as more common VM solutions. Also, the "practices" are different for z/OS to some degree. However, it does have some things in common with VIOS on POWER. That's definitely a VM technology I've seen get overstuffed and under-engineered and that goes double when they eschew NPIV or dedicated HBAs and instead use vSCSI containers and FCoE/DCB for both networking and storage. In fact, some of the worst VM environs I've seen have been VIOS ones. It's not that they can't be done right, it's that most people aren't smart enough to say no to the "converged" (read: inferior shared bandwidth) cheap-out route, nor can they resist hiring no-nothing H1B sysadmins to ignore their problems for cheap. The latter tending to exacerbate over-subscription situations because they just don't give a damn as long as they keep their visa.