From owner-freebsd-security Fri Oct 25 17:10:29 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA08580 for security-outgoing; Fri, 25 Oct 1996 17:10:29 -0700 (PDT) Received: from scanner.worldgate.com (scanner.worldgate.com [198.161.84.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id RAA08573 for ; Fri, 25 Oct 1996 17:10:23 -0700 (PDT) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.7.5/8.7.3) with UUCP id SAA01832; Fri, 25 Oct 1996 18:10:19 -0600 (MDT) Received: from localhost (marcs@localhost) by alive.ampr.ab.ca (8.7.5/8.7.3) with SMTP id SAA28215; Fri, 25 Oct 1996 18:03:20 -0600 (MDT) Date: Fri, 25 Oct 1996 18:03:19 -0600 (MDT) From: Marc Slemko X-Sender: marcs@alive.ampr.ab.ca To: Warner Losh cc: security@FreeBSD.ORG Subject: Re: Vadim Kolontsov: BoS: Linux & BSD's lpr exploit In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, 25 Oct 1996, Warner Losh wrote: > I've commited the OpenBSD fix for this problem, btw, which silently > truncates. Don't see a whole lot of reason for exiting in this case, > but I have trouble articulating why. I can improve upon the OpenBSD > fix, but at least that is one less lpr hole that is in FreeBSD. You can argue both ways, but I really don't think it matters too much. I do, however, really thinks that the idea logging things like this should be pursued; either someone is trying to breakin, which is bad, or someone is really trying to do something odd, in which case it would be nice to know why it wasn't working as it should. I would also suggest that perhaps it is even worth scrapping lpr entirely. There are numerous other security changes in the OpenBSD source tree, and even then I would bet there are still other problems with the code. Has anyone looked at LPRng in depth? (ftp://dickory.sdsu.edu/pub/LPRng/) I have serious doubts that the current BSD print system (ie. lpr & friends) is going to be made secure any time this century. Perhaps a wholescale replacement is in order? There is, of course, the disadvantage of becoming non-standard; LPRng uses different config files and works differently, so it isn't just a drop-in replacement.