From owner-freebsd-security Fri Sep 29 20:27:37 2000 Delivered-To: freebsd-security@freebsd.org Received: from silby.com (cb34181-c.mdsn1.wi.home.com [24.183.3.139]) by hub.freebsd.org (Postfix) with ESMTP id 3DDB837B66C for ; Fri, 29 Sep 2000 20:27:35 -0700 (PDT) Received: (qmail 17706 invoked by uid 1000); 30 Sep 2000 03:28:41 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 30 Sep 2000 03:28:41 -0000 Date: Fri, 29 Sep 2000 22:28:41 -0500 (CDT) From: Mike Silbersack To: James Wyatt Cc: Roman Shterenzon , Kris Kennaway , security@freebsd.org Subject: Re: cvs commit: ports/mail/pine4 Makefile (fwd) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 29 Sep 2000, James Wyatt wrote: > Lies, Damn Lies, and Statistics... > > I haven't looked, but I'll bet that most of the 4299 hits you got for pine > were in code that concerns fairly useless-to-attack areas of code like the > CUI (screens, menus, text areas, etc), config file IO, etc... Since the > program isn't suid or guid, a stack overflow in the menu code might let > you become *gasp!* yourself - whee! > > I have to admit that with *that* many incidences of a cancer like that, > some of it is likely to be attached to a vital organ or two like mailspool > header parsing or such. Aftre all user input isn't the problem, external > input is, isn't it? - Jy@ Don't trivialize Kris's statement. In the last few weeks, bugtraq has seen two pine-related postings. The first, a DoS any three year old could perform. The second, a buffer overflow which would be relatively simple to exploit. UW has done absolutely nothing about these yet. If you take a look through the code, you'll quickly become disgusted; the strange style makes detecting coding errors extremely difficult, and buffer overruns look to be everywhere. I found out by trying to chase a few that sanity checks were actually done elsewhere, but I have little confidence that every case was handled with such luck. That being said, I'm still finding it very difficult to rip myself away from pine. I had considered suggesting a fork of 4.21 which would be audited and snprintfified, but the license seems to suggest that such an effort could only exist in the form of patches, which would be annoying. In theory, such patches would be absorbed into the main product. But, given the UW coders' use of odd string functions they came up with and total lack of responsiveness, I doubt they'd ever get around to incorporating the patches. Anyone have ideas (or good communication with the UW guys?) Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message