From owner-freebsd-security  Fri Oct 25 12:32:17 1996
Return-Path: owner-security
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id MAA10297
          for security-outgoing; Fri, 25 Oct 1996 12:32:17 -0700 (PDT)
Received: from skynet.ctr.columbia.edu (skynet.ctr.columbia.edu [128.59.64.70])
          by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id MAA10291
          for <freebsd-security@freebsd.org>; Fri, 25 Oct 1996 12:32:13 -0700 (PDT)
Received: (from wpaul@localhost) by skynet.ctr.columbia.edu (8.6.12/8.6.9) id PAA26175; Fri, 25 Oct 1996 15:31:53 -0400
From: Bill Paul <wpaul@skynet.ctr.columbia.edu>
Message-Id: <199610251931.PAA26175@skynet.ctr.columbia.edu>
Subject: Re: Vadim Kolontsov: BoS: Linux & BSD's lpr exploit
To: imp@village.org (Warner Losh)
Date: Fri, 25 Oct 1996 15:31:51 -0400 (EDT)
Cc: freebsd-security@freebsd.org
In-Reply-To: <E0vGqzJ-00027v-00@rover.village.org> from "Warner Losh" at Oct 25, 96 12:28:09 pm
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Sender: owner-security@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

Of all the gin joints in all the towns in all the world, Warner Losh had 
to walk into mine and say:

> In message <199610251820.OAA26055@skynet.ctr.columbia.edu> Bill Paul writes:
> : ! 	while (p1 < (char *)&buf + BUFSIZ && (c = *p2++) != '\0') {
> ...
> : Yes this will silently truncate the string, but if the printer subsystem 
> : isn't smart enough to deal with this gracefully then it's no damn good 
> : anyway. :)
> 
> :-).  I just installed a variation of this from OpenBSD.  I think that
> the above patch has a fencepost error in it.  What happens when you
> get more than BUFSIZ bytes?  The first test will fail when buf is
> exactly full.  However, one more byte is written after the loop ends,
> which will overflow onto the stack.  Maybe it is harmless, but you
> never can tell.  See my last mail in security for other reasons why my
> patch is completely bogus and for the patch I applied.  lpd may not be
> able to handle the long lines due to its use of fixed buffers
> everywhere.  Also, my patch dumps core the first time through the loop
> (that will teach me to post w/o testing :-).
> 
> Warner

Whups. Yeah, you're right. The assignment of the newline at the end
didn't catch my eye for some reason. I suppose it should be:

	while (p1 < ((char *)&buf + BUFSIZ - 1) && (c = *p2++) != '\0') {

In any event, overrunning the buffer by one byte and possibly dumping
core is a little better than giving away a free root shell. :)

FYI: this same bug is likely to be present in lpr on SunOS (well, duh), 
though obviously you'd need a different chunk of machine instructions to 
exploit it.

-Bill

-- 
=============================================================================
-Bill Paul            (212) 854-6020 | System Manager, Master of Unix-Fu
Work:         wpaul@ctr.columbia.edu | Center for Telecommunications Research
Home:  wpaul@skynet.ctr.columbia.edu | Columbia University, New York City
=============================================================================
 "If you're ever in trouble, go to the CTR. Ask for Bill. He will help you."
=============================================================================