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