sco_bof.txt

`Subject: 19 SCO 5.0.5+Skunware98 buffer overflows  
To: [email protected]   
  
  
Greetings,  
  
After some light security auditing ;) I've found approximately nineteen buffer overflows in various SCO 5.0.5+Skunkware98 programs. This was, by no means, a comprehensive audit of SCO's su/gids so I'm sure there are dozens of holes I've missed. Keep in mind also that this was ONLY command line buffer overflow testing and did not include environment, file i/o, or any other sort of overflow. And I didn't touch /tmp races. That said..   
  
Some of these holes are old to the world of security, but apparently SCO hasn't caught up yet. For instance, anyone remember the old Xt library holes in xterm and such? Well, apparently SCO doesn't. Not to mention the fact that in June someone posted an xterm exploit (though the author didn't make clear that all programs using the Xt library were probably vulnerable) and SCO never came out with a fix. Thus this program as well as all others in the class are still vulnerable. Following is a list of vulnerable programs and their su/gid status:  
  
Potential root:  
SUID root  
---  
1. xload -bg $1492bytes  
2. xterm -bg $1492bytes  
3. xmcd -bg $1492bytes  
  
SUID auth (Auth has rw access to /etc/shadow)  
---  
4. xlock -bg $1492bytes  
5. xscreensaver -bg $1492bytes  
6. scolock -bg $1492bytes  
  
SUID mem (strings /dev/kmem)  
--  
7. sar -o $2105bytes or sar -f $1077bytes x  
  
Potential lp:  
SUID lp  
--  
8. cancel $998bytes (isn't this one old too?)  
9. lp $10000bytes (didn't get the exact number)  
10. reject $10000bytes (as above)  
  
Potential bin:  
SUID bin  
---  
11. sd $1017bytes (SIGSEGV @1017 SIGTERM 1 to 1017bytes)  
  
Potential annoyance:  
SUID dos  
---  
12. doscat $19031bytes  
13. doscp "" x  
14. dosdir ""  
15. dosls ""  
16. dosmkdir ""  
17. dosrm ""  
18. dosrmdir ""  
  
SUID uucp  
---  
19. ati $40bytes  
  
FIX:  
  
For most of these programs, you're going to have to suffer with some broken functionality when you remove the s-bits. The various suid root and auth won't be able to function without their su/gid status. However you could make a new group such as xusers and have these programs only executable by its members. In fact adding trusted users to the lp group is probably the best way to overcome these lp vulnerabilities as well.  
  
Hopefully this advisory will scare SCO into doing some security auditing on their own before their buggy product hits the market. In any case, be wary.  
  
Brock Tellier  
UNIX Systems Administrator  
Webley Systems  
www.webley.com  
  
  
`