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

11–20 of 132 posts

Re: #include </etc/shadow>

#11

Post by jessaustin »

Someone1234 wrote: post #4

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…

They're talking about reading compiler errors, so there won't be a binary to ship. If we could arrange for the code to compile correctly and then be executed, we wouldn't need the binary because the program itself could just upload all the password hashes.

Re: #include </etc/shadow>

#13

Post by mehrdadn »

nneonneo wrote: post #8

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…

> 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.

Re: #include </etc/shadow>

#14

Post by yori »

> 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.

Why is this surprising? Do programmers not read books anymore? Almost, any decent C programming book explains that #include reads the specified file and substitutes itself with the content of that file. Any Unix/Linux book explains that /dev/stdin is a special device file that represents the standard input.

Re: #include </etc/shadow>

#15

Post by jcrawfordor »

judge2020 wrote: post #2

Maybe these services run the compilation in a docker container? shadow and lsb-release exist in many images.

Untrusted code execution in a Docker container is not exactly safe. Even if the runtime and container are optimally configured for security purposes (uncommon), container runtimes are not designed or particularly thoroughly evaluated for use as a security solution.

Re: #include </etc/shadow>

#16

Post by dharmab »

mehrdadn wrote: post #13
nneonneo wrote: post #8

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…

> 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.

You're being downvoted but you're right- Docker really isn't a good choice for running untrusted and potentially hostile code, since a container breakout zero-day pretty much immediately compromises the host OS. (Even with user namespace remapping a breakout still gives enough access to get up to shenanigans.)

At the minimum a disposable VM using something like KVM/QEMU/Firecracker would be a start. That way you have kernel isolation down to the hardware which is much less likely to be exploitable.

Re: #include </etc/shadow>

#17

Post by adwn »

yori wrote: post #14

> 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. Why is this surprising? Do programmers not read books anymore? Almost, any decent C programming book explains that #include reads the specified file and substitutes itself with the content of that file. Any Unix/Linux book explains that /dev/stdin is a special devic…

> Why is this surprising? Do programmers not read books anymore? [...]

No need to be condescending. Three reasons:

1) A sophisticated compiler might read the length of a file before loading it, so that it can allocate a buffer of the right size. Doesn't work with /dev/stdin.

2) Alternatively, it might read the file via mmap(). Doesn't work with /dev/stdin.

3) Furthermore, it might check whether the file is a regular file. If not, it is almost certainly not what the programmer had in mind.

Re: #include </etc/shadow>

#18

Post by puzzledobserver »

yori wrote: post #14

> 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. Why is this surprising? Do programmers not read books anymore? Almost, any decent C programming book explains that #include reads the specified file and substitutes itself with the content of that file. Any Unix/Linux book explains that /dev/stdin is a special devic…

Neither of the individual facts is surprising. It is the juxtaposition that is. In 20 years of writing C/C++ code, I had never thought of #including files such as /dev/stdin.

Of course, I know how the #include mechanism works, and what the special device files do, so I can anticipate the results of #include , but it is unusual enough that I had to write a small test program to see for myself.

Re: #include </etc/shadow>

#19

Post by asveikau »

jakeogh wrote: post #12

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.

Re: #include </etc/shadow>

#20

Post by jdsully »

Someone1234 wrote: post #4

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…

People compile unread code all the time. Having them send the binary back is a little unusual though. But nothing says the resulting binary can’t open its own socket when its first run. There are lots of exfiltration options.

Getting them to run make as root would be pretty easy. People are already conditioned to run “sudo make install”.

A good mitigation is to install software by user so root privileges aren’t needed at any step of the process.

Post reply on HN