Hackers can take full control of online compilers through a RCE exploit (2018) | Hacker News Reader

Hackers can take full control of online compilers through a RCE exploit (2018)

serhack.me

20 pointscrecker15 comments

Online environment that allows arbitrary code execution allows arbitrary code execution.

I can't be the only person that's accidentally crashed gcc. This isn't a surprising idea.

EDIT: Oh nevermind, it sounds like they're pointing out that you can just upload malware.

Yeah that's what I thought this was about too - submit code that crashes the compiler and gives RCE.

But he actually is talking about online compilers that execute the code - he just runs `system("ls")`. What a waste of everyone's time.

Hi! I'm the author. Sorry for wasting your time, thanks for the feedback.

Wait till you see that you just need to log output in CI like

    ##teamcity[setParameter name='foo' value='bar']]

    ##vso[task.setvariable variable=foo]bar

From any package in your deps, a simple console output can set any pipeline variable. CI pipelines are a security nightmare with modern dependency chains.

Related, Ken Thompson's 1984 Turing Award speech, Reflections on Trusting Trust, https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_Ref...

is there a reason to believe this isn’t already sandboxed / run in a VM?

Hi, author here!

I wrote that post two years ago and at least in 2 environment, there was no sandbox or under Docker. I remember that I found an interesting environment that an interesting script.

The script parsed the input file and then chose if it could be compiled or not. Well, it's really easy to circumvent that.

In 2020, I would be impressed to see someone shipping such application without sandbox/VM.

I don't think docker would be an appropriate security measure here.

To be fair, docker is great, but I remember a few warnings about how users could get root access to the "host" machine. It's containers, not VMs.

Right, docker is great for configuration and deployment, but it's not a strong sandbox for untrusted code.

AWS doesn't offer to run your docker container on a Linux instance shared with other customers' containers. VMs are the correct abstraction for secure isolation, not docker.

How did you verify that it was not in a VM? Did you achieve persistence?

I think the article should have focused more on this as it's the most interesting and important part. execle and system are not really interesting, to paraphrase verroq: that just goes from arbitrary code execution to arbitrary code execution.

And disabling execle by recompiling library wont work, since you could still do a syscall "manually" with inline assembly.

Once I got into two compilers and achieved persistence (with a reverse shell), I stopped my investigation. I did not want to have any legal issues since I found some tokens that were used in production environment.

I reported that to developers and they found that I could have access to sensible data.

Thanks for the tips on the article!

If you get the compiler errors, you can get an idea of the host system. For example, by testing these includes:

    #include </etc/hostname>
    #include </etc/hosts>
    #include </etc/passwd>

If you get some info about the system/user the process is running as, you can even try something like

    #include </root/.ssh/id_rsa>
    #include </root/.bashrc>
    #include </root/.gitcredentials>

etc

Amazing! I never thought about this.

this is bullshit.

Reply on news.ycombinator.com