19 SCO 5.0.5+Skunware98 buffer overflows

[btellier () WEBLEY COM (Brock Tellier)]

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