imapd4r1 v12.264 and Security Implications
The following was posted on FreeBSD-Security today. I was interested in the official SuSE position since I run both OS's. Re: Fw: Re: imapd4r1 v12.264 (fwd) From: Robert Watson <rwatson@FreeBSD.ORG> To: Kris Kennaway <kris@FreeBSD.ORG>, "Michael S. Fischer" <michael@dynamine.net> Cc: security@FreeBSD.ORG On Mon, 17 Apr 2000, Kris Kennaway wrote:
According to the message I just read on bugtraq by the vendor, it doesn't seem to be as bad as I described it above: imapd has dropped privileges by the time it hits the vulnerability, so exploiting it will only give access to the shell account of the user who has logged in to imap. This may still be a problem in some installations, i.e. if they don't provide shell access to their mail users on the imap server.
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.'' The University of Washington IMAP programmers have proven time and again that they are quite capable of releasing code that puts people's system's at risk. They also are reluctant to admit or fix the bugs, and have demonstrated poor understanding of systems security issues. In other words, they make the poorest of choices when it comes to selecting developers for security-sensitive software (i.e., remote mail access servers). Perhaps we should fedex the uw-imapd people to the OpenBSD camp for correctional treatment. Given that attitude of the developer, I would strongly recommend we mark the port as FORBIDDEN, and would also seriously consider any suggestion to simply drop it from the ports and packages collections. 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 -- Bob F EMail FBob@wt.net A Truly Wise Man Never Plays Leapfrog With A Unicorn...
participants (1)
-
BobF