This is a multi-part message in MIME format.
------=_NextPart_000_03FD_01BEFAA9.02E79120
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
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..=20
=20
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
------=_NextPart_000_03FD_01BEFAA9.02E79120
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Greetings,</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2> After some light =
security=20
auditing ;) I've found approximately nineteen buffer overflows in =
various=20
SCO 5.0.5+Skunkware98 programs. This was, by no means, a =
comprehensive=20
audit of SCO's su/gids so I'm sure there are dozens of holes I've =
missed. =20
Keep in mind also that this was ONLY command line buffer overflow =
testing and=20
did not include environment, file i/o, or any other sort of =
overflow. And=20
I didn't touch /tmp races. That said.. </FONT></DIV>
<DIV><FONT face=3DArial size=3D2> </FONT></DIV>
<DIV><FONT face=3DArial size=3D2> Some of these holes =
are old to=20
the world of security, but apparently SCO hasn't caught up yet. =
For=20
instance, anyone remember the old Xt library holes in xterm and =
such? =20
Well, apparently SCO doesn't. Not to mention the fact that in June =
someone=20
posted an xterm exploit (though the author didn't make clear that all =
programs=20
using the Xt library were probably vulnerable) and SCO never came out =
with a=20
fix. Thus this program as well as all others in the class are =
still=20
vulnerable. Following is a list of vulnerable programs and their =
su/gid=20
status:</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>Potential root:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>SUID root</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>---</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>1. xload -bg $1492bytes</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>2. xterm -bg $1492bytes</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>3. xmcd -bg $1492bytes</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>SUID auth (Auth has rw access to=20
/etc/shadow)</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>---</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>4. xlock -bg $1492bytes</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>5. xscreensaver -bg =
$1492bytes</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>6. scolock -bg $1492bytes</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>SUID mem (strings =
/dev/kmem)</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>--</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>7. sar -o $2105bytes or sar -f =
$1077bytes=20
x</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>Potential lp:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>SUID lp</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>--</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>8. cancel $998bytes (isn't this one old =
too?)</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>9. lp $10000bytes (didn't get the exact =
number)</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>10. reject $10000bytes (as =
above)</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>Potential bin:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>SUID bin</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>---</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>11. sd $1017bytes (SIGSEGV @1017 =
SIGTERM 1 to=20
1017bytes)</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>Potential annoyance:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>SUID dos</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>---</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>12. doscat $19031bytes</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>13. doscp "" x</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>14. dosdir ""</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>15. dosls ""</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>16. dosmkdir ""</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>17. dosrm ""</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>18. dosrmdir ""</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>SUID uucp</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>---</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>19. ati $40bytes</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>FIX:</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2> For most of these =
programs,=20
you're going to have to suffer with some broken functionality when you =
remove=20
the s-bits. The various suid root and auth won't be able to =
function=20
without their su/gid status. However you could make a new =
group such=20
as xusers and have these programs only executable by its members. =
In fact=20
adding trusted users to the lp group is probably the best way to =
overcome these=20
lp vulnerabilities as well.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2> Hopefully this =
advisory will=20
scare SCO into doing some security auditing on their own before their =
buggy=20
product hits the market. In any case, be wary.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>Brock Tellier</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>UNIX Systems Administrator</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Webley Systems</FONT></DIV>
<DIV><FONT face=3DArial size=3D2><A=20
href=3D"http://www.webley.com">www.webley.com</A></FONT></DIV></BODY></HT=
ML>
------=_NextPart_000_03FD_01BEFAA9.02E79120--
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:02:51 PDT