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

31–40 of 132 posts

Re: #include </etc/shadow>

#31

Post by commandersaki »

puzzledobserver wrote: post #18
yori wrote: post #14

> 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. Why is this surprising? Do programmers not read books anymore? Almost, any decent C programming book explains that #include reads the specified file and substitutes itself with the content of that file. Any Unix/Linux book explains that /dev/stdin is a special devic…

Neither of the individual facts is surprising. It is the juxtaposition that is. In 20 years of writing C/C++ code, I had never thought of #including files such as /dev/stdin. Of course, I know how the #include mechanism works, and what the special device files do, so I can anticipate the results of #include , but it is unusual enough that I had to write a small test program to see for myself.

I’ve known about it for a very long time after someone pointed it out. I always joke that’s how I write C.

I never thought about it in terms of a security problem.

Re: #include </etc/shadow>

#33

Post by pvtmert »

- most of them (actually) containers

- one can easily do:

``` char buf[8192]; fread(buf, sizeof(buf), 1, fopen("/etc/shadow", "rb")); printf(buf); ```

also reading 'shadow' is not do that much since its salted and hashed. strong password (10 chars) will take many months and years.

you can do more harm with actual 'code' which you may compile on the service

Re: #include </etc/shadow>

#34

Post by zaphirplane »

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…

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

Re: #include </etc/shadow>

#35

Post by chmaynard »

willvarfar wrote: post #30

Its interesting tangent that the "confused deputy" security problem was first identified in a compiler, back in the days when people paid to have their code compiled. This led towards "capabilities" and lots of operating system design that is now in vogue again. https://en.wikipedia.org/wiki/Confused_deputy_problem (this #include problem can be thought of as a confused deputy vulnerability. The compiler shouldn't hav…

Henry Levy's 1984 book "Capability-Based Computer Systems" -- a survey and description of early object-based and capability-based processors and operating systems -- is available here:

https://homes.cs.washington.edu/~levy/capabook/index.html

Re: #include </etc/shadow>

#37

Post by dTal »

jdsully wrote: post #20
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…

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…

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.

Re: #include </etc/shadow>

#38

Post by mkl »

pvtmert wrote: post #33

- most of them (actually) containers - one can easily do: ``` char buf[8192]; fread(buf, sizeof(buf), 1, fopen("/etc/shadow", "rb")); printf(buf); ``` also reading 'shadow' is not do that much since its salted and hashed. strong password (10 chars) will take many months and years. you can do more harm with actual 'code' which you may compile on the service

> one can easily do:

> char buf[8192]; fread(buf, sizeof(buf), 1, fopen("/etc/shadow", "rb")); printf(buf);

The code is compiled on the server, but it doesn't run there.

Re: #include </etc/shadow>

#39

Post by zonidjan »

> 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 hash of the root password.

Wow. That's bad. Of course, that's not a compiler issue, but rather a system administration issue. /etc/shadow should not be world-readable.

> This effectively means this service is running compile tasks as root.

That's quite a leap from 'I can read /etc/shadow' to 'I am root'.

> Interestingly, including pseudo-files from /proc does not work. It seems gcc treats them like empty files.

More accurately, it seems the system treats them like empty files. gcc does a stat on the file, which returns 'regular file' and 'size=0'. gcc therefore calls read() with a length of 0 bytes.

Re: #include </etc/shadow>

#40

Post by zonidjan »

adwn wrote: post #17
yori wrote: post #14

> 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. Why is this surprising? Do programmers not read books anymore? Almost, any decent C programming book explains that #include reads the specified file and substitutes itself with the content of that file. Any Unix/Linux book explains that /dev/stdin is a special devic…

> Why is this surprising? Do programmers not read books anymore? [...] No need to be condescending. Three reasons: 1) A sophisticated compiler might read the length of a file before loading it, so that it can allocate a buffer of the right size. Doesn't work with /dev/stdin. 2) Alternatively, it might read the file via mmap(). Doesn't work with /dev/stdin. 3) Furthermore, it might check whether the file is a regular…

> 1) A sophisticated compiler might read the length of a file before loading it, so that it can allocate a buffer of the right size. Doesn't work with /dev/stdin.

gcc does this. It appears to be why /proc files don't work. gcc sees that stat calls it a 'regular file' and 0 bytes long, and actually performs a read() syscall with a length of 0.

> 3) Furthermore, it might check whether the file is a regular file. If not, it is almost certainly not what the programmer had in mind.

gcc probably does this. (It would explain why /dev/stdin works)

Post reply on HN