Date: Thu, 20 Apr 2000 10:14:46 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.ORG> To: Marc Heuse <marc@suse.de> Cc: suse-security@suse.com, FBob@wt.net, security@FreeBSD.ORG, michael@dynamine.net Subject: Re: [suse-security] imapd4r1 v12.264 and Security Implications Message-ID: <Pine.NEB.3.96L.1000420100429.32667B-100000@fledge.watson.org> In-Reply-To: <20000419202028.603DB67A5@Galois.suse.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 19 Apr 2000, Marc Heuse wrote: > > The following was posted on FreeBSD-Security today. I was interested > > in the official SuSE position since I run both OS's. > > here it is: > > >> I consider the post by the vendor in the bugtraq forum to be some sort of > >> poor joke. At this point, it would appear that anyone who takes security > >> seriously should use some other mail package, or risk their systems' > >> integrity. In particular, the thing about chroot'ing to /tmp is fairly > >> laughable. While partitioning can be a useful scheme for reducing risk, > >> "/tmp" is not the place to chroot to, and chroot'ing is not a replacement > >> for careful code auditing. The suggestion that stackguard should be > >> required to make their software secure has wandered far beyond > >> ``questionable,'' and well into the ``don't touch anything related to my > >> system ever again.'' > > although the language is a bit rude, he is absolutely correct. I would tend to agree with both assessments. Then, being the author I would have a natural tendency to support the latter, although perhaps less so the former. That said, it was a response of frustration, so we'll leave it at that. > well ... it's not the first vulnerability in wu-imap. and the response > of the wu-imap programmer really shows that he does not know about > secure coding. a security audit of the code would really be needed, > however, after half a year new vulnerabilities would be there and the > thing would start over. And also not the second vulnerability. I agree with the assessment that uw-imapd will be a continued source of vulnerabilities unless it is substantially audited and possibly rewritten. My recollection is that the c-client is a complex piece of code, largely in response to the complex format of the IMAP protocol, which requires a fair amount of string parsing and pushing. I.e., IMAP doesn't encourage secure coding styles in a language such as C. :-) > >> Given that attitude of the developer, I would strongly recommend we mark > >> the port as FORBIDDEN, and would also seriously consider an suggestion to > >> simply drop it from the ports and packages collections. > > this is unrealistic. people want and some even depend on imapd. and if we > would do that to imapd, we would have to do the same for pop3, ftp etc. > so the solution is to switch to a imapd with more knowlegable programmers. > not a very easy task ... I depend on IMAP also, although I use the Cyrus server which has proven far more satisfying in a number of ways. However, as with the qmail IMAP server, it relies on a mailbox format that is not standard with most UNIX systems, and as such neither is a serious alternative as part of the base system. I would really like to have an IMAP daemon that I can promote as an easy way to provide remote mail access out of the box, but have a lot of trouble seeing that--given the long delay since the last vulnerability, and the claim of a complete code audit, I had mistakenly assumed that it was safe to do so. It is true that the current vulnerability is not a serious problem in a number of environments (primarily open shell boxes where IMAP is a convenience, not a necessity, and the vulnerability doesn't open up new weaknesses), but the response to the vulnerability is what is particularly worrying. I am willing to accept that programs can and will have vulnerabilities, even after serious code audits (in fact, a code audit is only part of the process of securing a code base), but having the code provider indicate that security either is not a serious issue, or be unable or unwilling to proactively address such a problem is a serious issue. This bodes ill for the remainder of the source base, and the environment in which it was developed. My immediate suggestion of marking IMAPd and/or c-client as "FORBIDDEN" seems realistic--in FreeBSD, the FORBIDDEN or BROKEN tags indicate that it should not be built as a binary package for the base system, and must be intentionally enabled and built by the user. The patches are still provided and it's still part of the build infrastructure. Out-right removing it from the ports collection is probably unwise until a decent alternative is located or developed, but should one exist, I would continue to support a move to simply remove the distribution as provided by UW. > we will provide an update for wu-imapd. but we propose the use another > imapd. as far as I remember, there is another imapd server on the SuSE CDs > (there are far too much packages to remember them all ;-))). Let's hope that > the code of that one is better ... well, time to do a sourcecode audit :( > *sigh* This is great news--at this point I can't volunteer to assist in such an audit due to time constraints from other projects, but eagerly anticipate the release of an alternative/audited uw-imap, or the inclusion of the results of such an audit in the base UW distribution. Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services 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.NEB.3.96L.1000420100429.32667B-100000>