Date: Fri, 29 Sep 2000 22:28:41 -0500 (CDT) From: Mike Silbersack <silby@silby.com> To: James Wyatt <jwyatt@rwsystems.net> Cc: Roman Shterenzon <roman@xpert.com>, Kris Kennaway <kris@FreeBSD.org>, security@freebsd.org Subject: Re: cvs commit: ports/mail/pine4 Makefile (fwd) Message-ID: <Pine.BSF.4.21.0009292216140.17675-100000@achilles.silby.com> In-Reply-To: <Pine.BSF.4.10.10009292106510.43354-100000@bsdie.rwsystems.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0009292216140.17675-100000>