Re: [ Hackerslab bug_paper ] Informix-SQL application vulnerability

[Craig Ruefenacht <ruefenac () cs utah edu>]

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
---------------------------------------------