Date: Wed, 19 Apr 2000 22:20:28 +0200 (MEST) From: marc@suse.de (Marc Heuse) To: suse-security@suse.com Cc: FBob@wt.net, rwatson@FreeBSD.ORG, security@FreeBSD.ORG, michael@dynamine.net Subject: Re: [suse-security] imapd4r1 v12.264 and Security Implications Message-ID: <20000419202028.603DB67A5@Galois.suse.de>
next in thread | raw e-mail | index | archive | help
Hi > 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. >> 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. 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. >> 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 ... 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* Greets, Marc -- Marc Heuse, SuSE GmbH, Schanzaeckerstr. 10, 90443 Nuernberg E@mail: marc@suse.de Function: Security Support & Auditing "lynx -source http://www.suse.de/~marc/marc.pgp | pgp -fka" Key fingerprint = B5 07 B6 4E 9C EF 27 EE 16 D9 70 D4 87 B5 63 6C 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?20000419202028.603DB67A5>