61–70 of 132 posts
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 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.
> Recently I saw a tweet where someone mentioned that you can include /dev/stdin in C code compiled with gcc. This is, to say the very least, surprising. You can also call something to read from stdin in your Makefile, or read from stdin in your executable. > But is it equally obvious that the compiler also needs to be sandboxed? Yes. Why wouldn't it be sandboxed?! > I even found one service that ... showed me the ha…
This seems contrived. So you need to send someone "evil" code that they won't read, have them compile it as root, and then ship you the resulting binary. I wouldn't read too much into it "working" with some kind of compile/show service, as they could have been using non-persistent containers. Ultimately this seems like social engineering i.e. "Tricking privileged users into doing as root." Might have well ask them to…
> Recently I saw a tweet where someone mentioned that you can include /dev/stdin in C code compiled with gcc. This is, to say the very least, surprising. You can also call something to read from stdin in your Makefile, or read from stdin in your executable. > But is it equally obvious that the compiler also needs to be sandboxed? Yes. Why wouldn't it be sandboxed?! > I even found one service that ... showed me the ha…
> That's quite a leap from 'I can read /etc/shadow' to 'I am root'. Of all the leaps in that post, that's the least leapy thing. `shadow` exists precisely so that only `root` can read its content, whereas before said content resided in `passwd` which _needs_ to be readable by all. I see only two possibilities here. Either the people who set up that compile service are complete morons and run said compile as actual ro…
Docker containers aren't really a good security barrier, and a VM is much better (although VM escape vulnerabilities aren't unheard of).
Compiling untrusted code is already a dangerous affair. Compilers are not audited for security vulnerabilities, and many versions of popular compilers have contained memory corruption bugs or similar issues that could be leveraged to gain code execution. Many services that compile untrusted code will run the resulting binaries too, which definitely requires a sandbox or disposable VM - at which point you may as well…
In a container or not, running a compiler-as-a-service as root is never the right way to run a compiler-as-a-service.
Running as root I think is the exact thing to run as. Then throw the whole VM or container away when handling a request for another user.
> Recently I saw a tweet where someone mentioned that you can include /dev/stdin in C code compiled with gcc. This is, to say the very least, surprising. You can also call something to read from stdin in your Makefile, or read from stdin in your executable. > But is it equally obvious that the compiler also needs to be sandboxed? Yes. Why wouldn't it be sandboxed?! > I even found one service that ... showed me the ha…
The reason is that the content is generated by a callback that the kernel calls, and the kernel does not want the content to be generated just in order to stat(2) the file, so it shows a zero length, and assumes that things like /bin/cat will just read(2) until EOF is returned, without trying to be too smart.
Earlier quoted context omitted.
> That's quite a leap from 'I can read /etc/shadow' to 'I am root'. Of all the leaps in that post, that's the least leapy thing. `shadow` exists precisely so that only `root` can read its content, whereas before said content resided in `passwd` which _needs_ to be readable by all. I see only two possibilities here. Either the people who set up that compile service are complete morons and run said compile as actual ro…
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 plenty of webpages that offer online services where you can type in C code and run it. It is obvious that such systems are insecure if the code running is not sandboxed in some way. But is it equally obvious that the compiler also needs to be sandboxed?
Yes it's equally and painfully obvious.
Gentoo's build system is sandboxed by default: https://wiki.gentoo.org/wiki/Project:Sandbox
This reminds me that in say, a *BSD ports tree, you end up pulling tarballs from the internet, extracting them and running make. (Granted there can be a hash on them so that's some verification) But an exploit using that would likely sooner just write something malicious in the Makefile if it wants to compromise the build machine. Targeting the compiler for such a goal seems like it would be harder.