[15464] in bugtraq
Re: [Stan Bubrouski : Re: rh 6.2 -
daemon@ATHENA.MIT.EDU (Mitchell Blank Jr)
Sat Jun 24 14:58:08 2000
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-ID: <20000624035949.A31466@sfgoth.com>
Date: Sat, 24 Jun 2000 03:59:49 -0700
Reply-To: Mitchell Blank Jr <mitch@SFGOTH.COM>
From: Mitchell Blank Jr <mitch@SFGOTH.COM>
X-To: Frank da Cruz <fdc@COLUMBIA.EDU>
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <CMM.0.90.4.961792555.fdc@watsun.cc.columbia.edu>; from
fdc@COLUMBIA.EDU on Fri, Jun 23, 2000 at 04:35:55PM -0400
> 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
