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?
https://theintercept.com/2019/01/10/amazon-ring-security-camera/
At least that big Taliban beard will keep those thick black glasses on your head.
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.
Container sandboxes like Katakoda have been ripe for exploits like this for years. They don't have anything really stopping you from launching a bunch of cryptocurrency miners on them other than a 30 minute time limit, and I'd imagine that would be pretty easy to get around.
Yeah... the crypto kitties are the primary reasons we can't have nice things in the cloud, like free trial accounts with access to GPU hardware.
Whatever kernel/software-level bullshit you try to use will no insulate you from the bugs in those systems.
Hell, even proper VM's (KVM, et al) don't protect you from spectre/meltdown. Give up now!
So now we add idiot "security researchers" shouting "hacks! hackers! hacking!" in the mix, and look, BeauHD has another content-free post to share!
Apparently the thing of the times is to do things without knowing how to do these things.
Ya, if you're going to do any scaling you need good audits and lifecycle management. Chargeback or showback models help keep attention on resource usage and do a lot to prevent "orohans" since someone has to justify their existence to the beancounters.
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". ;)
VMs make a limited amount of sense, but only if you are REALLY SURE that the VM/sandbox is provably secure. No VM environment yet has been, and thanks to hardware problems unless you are running the combination of an In-Order processor with Registered memory and non-vulnerable virtual machine extensions (which as far as I know, no such combination of features exist!) then you have to assume your vms can be compromised by a sufficiently dedicated attacker, and your containers will fare even less well, since all you need is a single kernel/escalation vulnerability and your containers are likely broken and leaking root namespace kernel information into your nice little sandbox opening the door to complete system control.
Personally, I question how much we have really improved over the unix rwx or DEC/M$ NT permissions, and how much of this is just obfuscation of the problem to somewhere else in the code/permission chain. Punting it down the road under a pile of complications rather than solving the root issues of each.
IBM has been doing it properly since the 1980s.
Only the State obtains its revenue by coercion. - Murray Rothbard
FreeBSD box out there running on FreeBSD 11 that has a FreeBSD 10 compatibility layer running a FreeBSD 9 layer, running an 8 layer running a 7 layer ..... running a FreeBSD 4.x layer, that has original FreeBSD 4 executables running to which no one has the original source. It just works.
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.
The disconnect from the physical resources can happen without VMs. 2Ghz bajillion core processors in a box that needed ten fast ones. Literally more ram than you can use, integrated NICs that go into some kind of high latency polling mode at high pps. All the failed disk lights and powered off decommed servers ready to power on and eat their former IP address like zombies.
Intel servers are so cheap they are (mis)treated just like VMs basically.
Play with Docker is a playground app. Who cares. It's not like you can escape real Docker containers.
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
I'm just saying they are often a roach motel and often very poorly understood and administered.
So much this. Clueless uninformed people making decisions about stuff that they shouldn't, as always. And, the end result is a huge mess and likely breach
Yet, no one is held responsible, so no one cares and it never changes.
P.S. you failed to mention the ever popular, run all the containers as root fiasco. FML
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.
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.