unixware.chown.txt

1999-12-04T00:00:00
ID PACKETSTORM:11278
Type packetstorm
Reporter Brock Tellier
Modified 1999-12-04T00:00:00

Description

                                        
                                            `Greetings,  
  
  
OVERVIEW  
Any user can change the owner of any file he or she owns.  
  
BACKGROUND  
All my testing was done on UnixWare 7.1, however chances are excellent that  
this problem exists for all versions of UnixWare.  
  
DETAILS  
This hole is, erm, different. Apparently any user can change the ownership of  
any file he or she owns to any other user. But there is no exploit code  
attached below since all this requires is the use of chown(1).   
  
  
uw71:/usr/home/btellier$ ls -la owned  
-rw-rw-r-- 1 btellier web 0 Dec 3 15:29 owned  
uw71:/usr/home/btellier$ chown root owned  
uw71:/usr/home/btellier$ ls -la owned  
-rw-rw-r-- 1 root web 0 Dec 3 15:29 owned  
uw71:/usr/home/btellier$  
  
Interesting, eh? Note that we can NOT change the owner of a suid file without  
losing the suid bits. Also note that we cannot change the group. Maybe  
someone else wants to play with this one, but I cannot see any way to make  
this into instant root. There are, however, a few things that we could do  
with this privilege:  
  
1. UnixWare's r-services deal doesn't allow an .rhosts file unless the mode is  
0xx0, where x can be anything. In addition to this, the user in questionmust  
also own this file as a security precaution. Various exploits do things like  
creating any file chmoding it to the user running the exploit. Under  
UnixWare, this exploit would fail if, for instance, we created . Used in  
conjuction with this exploit, it would succeed.  
  
2. Any user is able to mask his attempts with various exploits. The best  
example of this would be my uidadmin exploit which left a shell in /tmp and  
waited until the next reboot to make it a rootshell. A suspicious sysadmin  
could easily notice this in /tmp and be tipped off as to who has been rooting  
his UnixWare box. With this exploit, we could chown it to root or some other  
user, thereby disassociating ourselves from it.  
  
I would welcome any suggestions from any Un*x admin as to what they might use  
this exploit for, since, whatever it is, it probably affects UnixWare.  
  
Brock Tellier  
UNIX Systems Administrator  
Chicago, IL, USA  
btellier@usa.net  
  
`