[15469] in bugtraq
Re: [Stan Bubrouski : Re: rh 6.2 -
daemon@ATHENA.MIT.EDU (Frank da Cruz)
Sat Jun 24 16:01:28 2000
Message-ID: <CMM.0.90.4.961875665.fdc@watsun.cc.columbia.edu>
Date: Sat, 24 Jun 2000 15:41:05 EDT
Reply-To: Frank da Cruz <fdc@COLUMBIA.EDU>
From: Frank da Cruz <fdc@COLUMBIA.EDU>
X-To: Mitchell Blank Jr <mitch@sfgoth.com>
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: Your message of Sat, 24 Jun 2000 03:59:49 -0700
> > 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.
>
Fair enough. Although this begs the question of why dialout programs have
to be privileged in the first place, which has been my pet Unix peeve for,
well, forever. Other operating systems manage perfectly well without all
the lockfile silliness, and even manage to share serial ports between dialin
and dialout service -- it's all done with modem signals and kernel code. A
Unix-like example is QNX. A non-Unix-like example is VMS. A Unix version
that's moving in this direction is FreeBSD. For a longer rant on this topic,
see Section 10 of:
ftp://kermit.columbia.edu/kermit/f/ckuins.txt
In any case, even with a successful buffer exploit that executes its own
set[ug]id() call, the most to be gained is access to the dialout device
and lockfile directory, which is not exactly a Chernobyl-class catastrophe.
Anyway, special thanks to those who told me about plp_[v]snprintf(); I
didn't know about it before and it looks very promising.
Finally, I'd like to get the idea across to everybody that C-Kermit is
vigorously and aggressively supported. Anybody who has a problem with it
is welcome, and in fact requested, to contact kermit-support@columbia.edu
about it. We'll probably be issuing a 7.1 version fairly soon.
- Frank
