Hacker News Reader

Hacker News

Comment by meepmorp | Hacker News Reader

Parent Full thread

meepmorp

> Here is the first thing i typed in the terminal

root@lisa:~# ./CrackTheDoor

Um. I see at least one security issue already.

View on HN

Not sure why you're getting downvoted, but debugging a "crack me" app while running as root is probably a bad idea.

Even if this is inside a VM, it might give the wrong message to someone wanting to try this for themselves.

I've played in many CTFs and written challenges for a few. Unpleasant surprises in the binaries, especially when run as root aren't uncommon.

You could also attack the VM:

http://www.cvedetails.com/vulnerability-list/vendor_id-93/pr...

Given this, what is the best first step? Best we can tell, he was running root in a VM that was running as an ordinary user. What more can be done, aside from running it on a throwaway machine? Running on a cloud instance, perhaps?

Perhaps a LiveCD/LiveUSB, with a VM inside of it?

Then a compromise would need to be:

Local VM user -> root VM user -> local LiveCD user -> root liveCD user -> hardware exploits

Christ I had no idea Virtualbox was that riddled with holes. I wonder how many of those have been fixed.

Give it costs pennies to boot up new Linux instances, I wouldn't assume this was OP's own machine.

Given that he later shows screenshots of "eren@lisa:~$ gdb ./CrackTheDoor" that assumption is pretty shaky.

Could have been a VM! I'd assume it was.

I did assume that, but it still seems like bad practice.

Or even a livecd with no other storage attached.

Except it may flash your bios or reflash any of your PCI cards and persist there.

kali default user?

Could be inside docker. In which case it's all reasonable.

Afraid you're woefully incorrect. The root user is no more contained inside a default docker image than they are inside a chroot, which is, not really at all. It isn't difficult to break out of a container if you have uid 0 aka root. This will change when the userns stuff lands, but it hasn't yet, so that doesn't count yet.

https://opensource.com/business/14/9/security-for-docker

Or as solomon hykes, the docker creator himself said recently:

https://news.ycombinator.com/item?id=7910117

"""When we feel comfortable saying that Docker out-of-the-box can safely contain untrusted uid0 programs, we will say so clearly."""

Well, so far I have only heard a lot of FUD and nothing concrete.

http://opensource.com/business/14/7/docker-security-selinux seems to have some information. But to refuse the points there, on my system: a) docker containers do not have a /dev/mem b) /sys/fs is mounted read-only c) /dev/sd* is not visible

And so on. What's the thing with cgroups? Can a container delete the host's cgroups? Can it overwrite it's own cgroup constraints?

Can you or someone tell me if there is something I can try out on my own to understand actual issues? I run my containers unprivileged (which is the default) if it matters.

Again, all I am asking is for some material to educate myself on what actually the flaws are. All I have seen are vague articles claiming it's insecure.

http://blog.docker.com/2014/06/docker-container-breakout-pro...

But nothing is stopping you from creating a binary and running it as root that perhaps mounts those filesystems, or sends ioctls / badness to the kernel.

I'm just shooting from the hip here and might be wrong, but I'm almost certain devices aren't namespaced. If you were to mknod a block device with the right major / minor numbers as the host's sda/sdb/etc, what would stop you from mounting the host's root filesystem and making changes?

Granted the "work around" is to drop the privileges of the containers as much as possible, use sVirt (via SELinux), drop as many capabilities as possible, don't run untrusted containers, etc. But this isn't a theoretical security problem, it is a real big attack surface.

Edit:

http://www.projectatomic.io/blog/2014/09/yet-another-reason-...

afaik, devices are namespaced already.

http://lwn.net/Articles/564854/

No, I dont think thats upstream.

For a moment I thought John Cormack replied :)

Thanks for the info.

When the creators themselves are saying they don't consider it secure, I don't think it's "FUD".

Sorry, I didn't imply what Shykes said is FUD. I meant most of the articles out there about docker security have little to no information other than "breakout is possible".

That quote from Shykes could be paraphrased "it's safest to assume breakout by uid0 is possible." I understand the academic/hacker interest in identifying the exact avenues for breakout, and why vague articles are disappointing. My point is, it's important everyone understand it's not to be considered secure, even if we can't/don't name the vulnerabilities off the top of our heads.

Fair enough. I agree with you.

You should be assuming Docker is insecure until proven otherwise. Fully isolating a root user with a shared kernel is very difficult.

OpenVZ is very widely deployed and manages to do this safely.

Reality disagrees with you good sir:

https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=openvz

The first is not even an OpenVZ bug, and which of the others shows an exploit that breaks out of the VM?

How do you prove something is secure?

Reply on news.ycombinator.com