Hi, I have verified that this problem exists on version 9.20 UC2 on Solaris 2.6. In my testing I have tested various situations and have a few things to add... > >There is a vulneribility in informix-SQL application which allows local > >users to create any file with root privilege: [...] > >$ cd ~informix/bin (Informix HOME Directory) > >$ ./onshowaudit > >INFORMIX-SQL Version 7.31.UC5 > > onshowaudit must be run by the AAO user unless you've misconfigured > INFORMIX. Since you've already ignored the group restrictions, no doubt > that's the case. On the system I tested on, it had a vanilla 9.20 UC2 install, and many of the programs in $INFORMIXDIR/bin were owned by root and setuid root, including the ones mentioned in the exploit. > Tried the rest. Can't get it to set rwxrwxrwx on any /tmp file, even with > setting umask to 0000, althought that does allow files to be created > rw-rw-rw which isn't good (and why you shouldn't SET umask to 0000. In my testing I set the umask to 077 and still got the same behavior - new files are written with mode 666. It appears that the setuid programs in /opt/informix/bin don't honor the env umask. And it isn't limited to /tmp. I was able to create /.rhosts as well as any other file that didn't exist in any directory (filesystems such as NFS configured to not allow root write access of course wouldn't work). The machine I tested on doesn't have rsh enabled in inetd, so after creating a /.rhosts file, getting rsh working would be difficult because one would have to edit /etc/inet/inetd.conf, then HUP the inetd daemon, and so on, all as user root. Whats more disturbing to me, though, is that I was able to *overwrite* existing files. For instance, doing this: > ln -s /etc/shadow /tmp/onsnmp.foobar.log > ./onsrvapd would *overwrite* /etc/shadow with whatever was written to /tmp/onsnmp.foobar.log. However, the file modes and owner/group of /etc/shadow doesn't change, ie it remained owned by root, group sys, and mode 400 (which is what it was prior to running the onsrvapd command), so I couldn't edit it afterwards, but I could nonetheless overwrite it. I could have just as easily done /etc/passwd, /kernel/<whatever>, etc. So a DBA with access to the user informix's account (but no root access) can overwrite any file they want to. The bottom line with my testing: * The env umask doesn't appear to matter. Even if it did, a malicious person who gained access to the informix user's account could set appropiatly to produce the exploit. * You can overwrite (but not change mode and owner) of existing files. You don't have much control over what is written to the files, but you can overwrite them to corrupt them. Overwriting certain files (like /usr/lib/libc.so) could even crash the system and make it non-bootable. * Version 9.20 UC2 is vulnerable -- --------------------------------------------- Craig Ruefenacht ruefenac@cs.utah.edu ---------------------------------------------
