Hacker News Reader

Comment by xtrapolate | Hacker News Reader

Getting an exorbitant bill from DigitalOcean after someone has abused your "containers" would not concern you then?

I'm just not sure what you are alleging? Just because you have full "shell" access to the container doesn't necessarily imply any thing needs to be mitigated.

What specifically are your concerns? What about what you've learned will create an exorbitant bill?

> "What specifically are your concerns? What about what you've learned will create an exorbitant bill?"

Abusing the containers to send large amounts of outgoing traffic would do just that. Downloading files would do that too. How about sending a "while(true) { }" to hog some CPU? It doesn't take much to cause significant monetary damage.

Depending on their set-up, those containers could contain credentials or some other means to compromise the rest of the website. Perhaps it is possible to re-use the containers across different "sessions", serving multiple clients with malicious traffic. Those are plausible scenarios.

I'm not carrying out a full PT right now. Demonstrating the platform has been compromised is more than enough. Any other questions?

> How about sending a "while(true) { }"

Running ps shows the timeout command as PID 1, and evidently an infinite loop gets killed after some point. In fact, there aren't any other processes besides sh, node, and the Python interpreter, and I'm not familiar with containers to know how this is possibly implemented (because obviously, timeout cannot be PID 1, so ps is wrong here).

But you don't know that they aren't using cgroups or a proxy to throttle traffic or cpu access, right? To me, it seemed that your message was overly dramatic when you didn't really prove anything. Depending on their set-up indeed. I just don't see the compromise in your analysis.

You're right but the fact that he was able to curl a file from the outside does seem pretty bad. It means that you can effectively proxy traffic through the website and use it to target 3rd parties.

Just because you have full "shell" access to the container doesn't necessarily imply any thing needs to be mitigated.

What do you mean? It's an arbitrary RCE - a scenario that's generally treated as game over. What specifically are the concerns you don't have if that happens to a system of yours?

In a very carefully configured container regime, you might not be getting anything other than the access the API already had to run code submitted by users. You'd have RCE, but your code can only do the limited set of things permitted by the container; it might not have access to any meaningful filesystem, or to the network, or to the container engine.

It's very tricky to create and maintain those kinds of container systems, but there are services (for instance, the cloud CI providers) that do it.

On applications like these, where the premise is that you give them some kind of code and they evaluate it for you, escaping the "user interface" sandbox isn't game over; you'd have to finish the exercise of escalating to the container host or getting access to an internal network with internal APIs on it.

It's a little like getting SQL injection, but confined to some kind of SQL view. Chances are the application is doomed, but you still have to prove it.

Right, I understand that but you'd not pick a container as your primary line of isolation for running arbitrary Go code. The GP is saying - it's cool, because containers. Yes, perhaps in exceptionally skilled hands, maybe this is sane but generally it's not. The official go playground's first sandbox is Native Client.

Can we not stipulate the existence of a container breakout of the week?

Can you link to a container breakout exploit from the past 6 months?

remote code execution doesn't really mean much in an un-privileged container. They could be using cgroup limits, capability drops, MAC, seccomp, etc etc

Now, I'm not saying that containers are super tight by default. It is entirely possible this particular container env is wide open, but I didn't really see anything too concerning from the parents analysis.

remote code execution doesn't really mean much in an un-privileged container.

It means pretty much everything. Have you ever heard of someone reporting an RCE in a major service and it being treated as no big deal? They're invariably treated as catastrophic compromise because it is. The jump from RCE to privilege escalation, escape, etc is nothing compared to the actual RCE-ing.

when the platform is itself about RCE... I think you have to evaluate what specific dangerous code can be executed before you start lighting the torches.

For one you can now use this page to spam other services.

Reply on news.ycombinator.com