Re: [Stan Bubrouski <satan () FASTDIAL NET>: Re: rh 6.2 - gidcompromises, etc [+ MORE!!!]]

[mitch () SFGOTH COM (Mitchell Blank Jr)]

> It should be noted the program does not run suid or sgid except the following
> places:
>
>  1. When opening the SET LINE device.
>  2. When creating the UUCP lockfile.
>  3. When reading a UUCP lockfile.
>  4. When deleting the UUCP lockfile.

This is probably old hat to many in the bugtraq crowd, but it bears
repeating.  Temporarily dropping your raised permissions does not offer
ANY real protection against buffer overruns.  The malicious shell code
can do that set[ug]id() syscall just as well as you can.  Many exploits
have been written to do this.

That isn't to say that [ug]id switching is a bad technique - it prevents
some sorts of security holes (like tricking kermit into opening a session
log somewhere the user shouldn't be allowed to)  It just doesn't help
you here.  The only defense is proper bounds checking throughout the app,
and for a program the size of kermit that's a tall order.  When you
consider that parts of C-Kermit predate the Morris worm, it's really not
surprising if there are problems.

A full audit of C-Kermit would be a good project for any aspiring security
geeks out there.  A far better idea would be to write a sgid-uucp app that
can handle opening devices (with the proper uucp locking) and then pass
back an fd over a unix-domain socket.  Then train {kermit,minicom,cu,etc} to
use this new tool.  That would fix these problems in a whole class of apps
and allow a LOT of code to run completely unprivledged.

-Mitch