[3900] in bugtraq

home help back first fref pref prev next nref lref last post

AUTOSOFT/RTS holes

daemon@ATHENA.MIT.EDU (Brian Mitchell)
Thu Jan 9 12:28:14 1997

Date: 	Thu, 9 Jan 1997 01:31:07 -0600
Reply-To: Brian Mitchell <brian@saturn.net>
From: Brian Mitchell <brian@saturn.net>
To: Multiple recipients of list BUGTRAQ <BUGTRAQ@NETSPACE.ORG>

Hi there,

Recently I have been working on a project involving Auto-Soft's RTS
inventory control system. Well, in a fit of boredom I desided to take
a quick look at some of the privledged programs; alas, I was greatly
disappointed.

The software contains things I thought were long gone: popen()/system()
holes and gets() [!]. Of course, there are also buffer overflows
galore, but that is almost expected these days.

I have not checked all the privledged programs thoroughly, so it is
entirely possible that I have missed many many many holes in their
package. Test platform is a Interactive UNIX box, your milage may
vary. Here are a few interesting (and quite amusing) snipits.

utusr
This is a setuid program that's purpose is to run things as any user
from the command line, somewhat akin to su. There is, however, one
slight catch - it does no checking of either password or users.
Additionally, there is atleast one exploitable buffer overflow.

utrts
This program is essentially the same as utusr, except it runs programs
as the rts user. However, there is a buffer overflow as it copies the
LOGNAME environment variable into a 133 byte local buffer - this all
happens right before it sets the uid to the rts userid, so root is
obtainable.

uttstsoc
This is a test program for the ports rts uses to read/write messages.
It is, of course, setuid root. I'm not sure how many buffer
overflows this program has, I lost count after I found 4 exploitable
ones, the last one being a gets() (what ARE these people thinking?!).

utreadsoc
This is very much like uttstsoc, except there is no gets(). However,
the sprintf()s are there in full force.

utqm
This is the queue manager, first problem I spotted was a number of
extremely exploitable popen() function calls (take your pick). The
popen() calls run grep and ps in many many functions.


Brian Mitchell / brian@saturn.net
http://www.saturn.net/~brian/security/

home help back first fref pref prev next nref lref last post