Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

#include

blog.hboeck.de

Post reply on HN
Print view View original

71–80 of 132 posts

Re: #include </etc/shadow>

#71

Post by shawabawa3 »

fwsgonzo wrote: post #61

You can compile and execute C/C++ code in my little hobby project: https://droplet.fwsnet.net/ It's something I use to measure certain things, like how many instructions does a C++ exception add etc. It's run in a docker container, and I think I strip out any slashes from includes. I'm pretty sure the container is not executing stuff as root as well. Still, probably not bulletproof.

You aren't stripping slashes.

I tried `#include ` and it eventually crashes the container failing to allocate memory (looks like they have a 4GB limit?)

Re: #include </etc/shadow>

#72

Post by arpa »

rbanffy wrote: post #68
londons_explore wrote: post #65

Earlier quoted context omitted.

Running as actual root in a VM would be my preferred design. There are lots of times a user might need to apt-get some dependencies for their compile job. Let an attacker do whatever they like in the VM. Then delete the VM between users. Docker containers aren't really a good security barrier, and a VM is much better (although VM escape vulnerabilities aren't unheard of).

There are many ways a hostile program inside a VM can escape it and run code on the host or, at least, negatively affect it.

Please do share how can one escape qemu.

Re: #include </etc/shadow>

#73

Post by pdpi »

eeZah7Ux wrote: post #58
pdpi wrote: post #46

Earlier quoted context omitted.

Funny you say the docker is not for security (it’s there in the manual) but then suggest chroot of all things — that is just as well documented as not being meant for security!

On the contrary, docker increases the attack surface.

The point is that neither tool has a security focus, any security characteristics they might have are incidental and not at all guaranteed, and so neither should be used for that purpose.

Re: #include </etc/shadow>

#74

Post by vsareto »

thenewnewguy wrote: post #28
mehrdadn wrote: post #13

Earlier quoted context omitted.

> I find it more likely that the "root" user mentioned in this post is the root user of some disposable Docker container, which would be the right way to run a compiler-as-a-service. My understanding is that Docker isn't something you use if you really want security.

This is true, but containers are so much better than nothing and relatively simple to use, so if someone isn't going to put in the effort for a more secure solution I'd rather they use Docker than nothing.

We haven't lost the effort in securing bare metal systems. Those still work.

Re: #include </etc/shadow>

#75

Post by jacquesm »

arpa wrote: post #72
rbanffy wrote: post #68

Earlier quoted context omitted.

There are many ways a hostile program inside a VM can escape it and run code on the host or, at least, negatively affect it.

Please do share how can one escape qemu.

At your service:

https://www.techrepublic.com/article/vm-escape-flaw-in-qemu-...

Re: #include </etc/shadow>

#76

Post by mnw21cam »

fwsgonzo wrote: post #61

You can compile and execute C/C++ code in my little hobby project: https://droplet.fwsnet.net/ It's something I use to measure certain things, like how many instructions does a C++ exception add etc. It's run in a docker container, and I think I strip out any slashes from includes. I'm pretty sure the container is not executing stuff as root as well. Still, probably not bulletproof.

Yeah, that's definitely a big "Here, hack me" post you just put up there.

Re: #include </etc/shadow>

#79

Post by softwarelimits »

You wrote something interesting, unfortunately you accidentally hit the "reply" button before you could insert some URLs that would add some substance to your words.

I am sure you know that words without evidence are of no value on the internet and it will kill your reputation, so I am waiting until you get online again and send some examples.

Please post some currently working code for escaping XEN, KVM, also VMWare and Virtualbox may be of interest, thanks!

I could not find any relevant content on the website you publish in your profile - btw it seems to be a bit broken, maybe go into webdev a little bit after you finished the code for the VM exploits?

Post reply on HN