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

1–10 of 132 posts

Re: #include </etc/shadow>

#4

Post by Someone1234 »

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 cat /etc/shadow and email you the "nonsense" it prints.

https://devblogs.microsoft.com/oldnewthing/20180227-00/?p=98...

Re: #include </etc/shadow>

#5

Post by slimsag »

> is it equally obvious that the compiler also needs to be sandboxed?

I would NEVER expect that one can run a C or C++ compiler on arbitrary input safely. There are so many potential attack vectors and, unless the authors have gone out of their way extensively to prevent them, it seems very likely they would suffer from buffer overflows, leaking memory to callers, and in the worst case arbitrary code execution.

I doubt any one of these websites is safe unless using very strict validation or disposable VMs/hardware in some way.

Re: #include </etc/shadow>

#6

Post by dvt »

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…

Not only is it contrived, it's also compiler dependent[1]. I'd wager most compilers will simply copy the contents of the included file like gcc does, but all kinds of other stuff can happen.

[1] https://gcc.gnu.org/onlinedocs/cpp/Include-Syntax.html

Re: #include </etc/shadow>

#8

Post by nneonneo »

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 throw your whole compiler in the sandbox/VM too.

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.

Re: #include </etc/shadow>

#9

Post by unilynx »

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…

Well, if he saw an actual hash... there’s generally no reason a docker container should have any password hashes in /etc/shadow.

Of course how a specific container is built is anyone’s guess

Re: #include </etc/shadow>

#10

Post by stevekemp »

judge2020 wrote: post #2

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

I found a lot of online services which would do LaTeX to PDF conversion, which were running in docker containers.

They would almost universally allow you to include files, and run commands on the host.

Post reply on HN