6 ms·

> Here is the first thing i typed in the terminal root@lisa:~# ./CrackTheDoor Um. I see at least one security issue already.

odonnellryan 12y ago
Could have been a VM! I'd assume it was.
- meepmorp 12y ago
  I did assume that, but it still seems like bad practice.
- icebraining 12y ago
  Or even a livecd with no other storage attached.
  - antocv 12y ago
    Except it may flash your bios or reflash any of your PCI cards and persist there.
scott_karana 12y ago
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.
- ryan-c 12y ago
  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.
- eyeareque 12y ago
  You could also attack the VM: http://www.cvedetails.com/vulnerability-list/vendor_id-93/product_id-20406/Oracle-Vm-Virtualbox.html http://www.cvedetails.com/vulnerability-list/vendor_id-93/pr...
  - doreo 12y ago
    Christ I had no idea Virtualbox was that riddled with holes. I wonder how many of those have been fixed.
  - jfoster 12y ago
    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?
    - scott_karana 12y ago
      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
general_failure 12y ago
Could be inside docker. In which case it's all reasonable.
- SEJeff 12y ago
  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 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 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."""
  - general_failure 12y ago
    Well, so far I have only heard a lot of FUD and nothing concrete. http://opensource.com/business/14/7/docker-security-selinux 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.
    - ryan-c 12y ago
      You should be assuming Docker is insecure until proven otherwise. Fully isolating a root user with a shared kernel is very difficult.
      - 12y ago
parktheredcar 12y ago
kali default user?
zaidf 12y ago
Give it costs pennies to boot up new Linux instances, I wouldn't assume this was OP's own machine.
- mverwijs 12y ago
  Given that he later shows screenshots of "eren@lisa:~$ gdb ./CrackTheDoor" that assumption is pretty shaky.

odonnellryan 12y ago

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

meepmorp 12y ago
I did assume that, but it still seems like bad practice.
icebraining 12y ago
Or even a livecd with no other storage attached.
- antocv 12y ago
  Except it may flash your bios or reflash any of your PCI cards and persist there.

scott_karana 12y ago

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.

ryan-c 12y ago
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.
eyeareque 12y ago
You could also attack the VM: http://www.cvedetails.com/vulnerability-list/vendor_id-93/product_id-20406/Oracle-Vm-Virtualbox.html http://www.cvedetails.com/vulnerability-list/vendor_id-93/pr...
- doreo 12y ago
  Christ I had no idea Virtualbox was that riddled with holes. I wonder how many of those have been fixed.
- jfoster 12y ago
  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?
  - scott_karana 12y ago
    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

general_failure 12y ago

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

SEJeff 12y ago
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 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 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."""
- general_failure 12y ago
  Well, so far I have only heard a lot of FUD and nothing concrete. http://opensource.com/business/14/7/docker-security-selinux 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.
  - ryan-c 12y ago
    You should be assuming Docker is insecure until proven otherwise. Fully isolating a root user with a shared kernel is very difficult.
    - 12y ago

parktheredcar 12y ago

kali default user?

zaidf 12y ago

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

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