Bugtraq mailing list archives
Re: response to the bugtraq report of buffer overruns in imapd LIST command
From: MRC () CAC WASHINGTON EDU (Mark Crispin)
Date: Mon, 17 Apr 2000 18:24:59 -0700
Can we please avoid hyperbole (such as "Seattle disease"), and discuss the facts rationally? 1) There is no added vulnerability at all for a UNIX system which permits shell access. I don't have sufficient data to know what percentage of UW imapd sites run IMAP servers on top of shell UNIX systems as opposed to closed systems. 2) The impact of the problem is that an authorized user may obtain unauthorized shell access to a closed system. Unless the system also has other, more severe, security problems, the consequences are modest and it is not difficult to identify the perpetrator. 3) A closed system which uses UW imapd probably is going to modify it in any case. Among other things, access to unmodified UW imapd is essentially equivalent to access to FTP. UW imapd is designed for use in a more or less cooperative environment in which the primary focus is denying access to unauthorized users. We have never claimed that unmodified UW imapd is immune to mischief by authorized users. The final form of the CHROOT_SERVER code, which will be an option in the next distributed version, consists of: if (chroot (home ? home : ANONYMOUSHOME)) return NIL; home = "/"; And, yes, this will do the necessary chdir(). I will also look into what else needs to be done for this particular problem. I would have done so anyway. Nevertheless, the response to a bug needs to be measured compared to the impact. Unlike a root-compromise bug, the sky is not going to fall for the overwhelming majority of UW imapd sites. Just a little bit less hyperbole would go a long way towards creating a useful discussion. Last but not least, I am very interested in Kris Kennaway's claim that "It may also be possible to break out of the chroot jail on some platforms." If true, it represents a huge root-level security hole on those platforms. I simply do not believe the claim. I would like to know if there is some substance to this claim, or if it was mere speculation.
Current thread:
- Reappearance of an old IE security bug, (continued)
- Reappearance of an old IE security bug Ben Mesander (Apr 16)
- Re: Reappearance of an old IE security bug Vladimir Dubrovin (Apr 17)
- Announcing: Solaris Fingerprint Database (sfpDB) on SunSolve Casper Dik (Apr 17)
- Re: XFree86 server overflow Olaf Kirch (Apr 17)
- Re: XFree86 server overflow Valentin Pavlov (Apr 17)
- Microsoft Security Bulletin (MS00-025) Microsoft Product Security (Apr 17)
- Re: XFree86 server overflow Paweł Sakowski (Apr 17)
- RAZOR Analysis of dvwssr.dll Simple Nomad (Apr 17)
- response to the bugtraq report of buffer overruns in imapd LIST command Mark Crispin (Apr 17)
- Re: response to the bugtraq report of buffer overruns in imapd LIST command Theo de Raadt (Apr 17)
- Re: response to the bugtraq report of buffer overruns in imapd LIST command Mark Crispin (Apr 17)
- Re: response to the bugtraq report of buffer overruns in imapd LIST command R. C. Dowdeswell (Apr 17)
- xfs security issues (fwd) Chris Evans (Apr 17)
- Re: response to the bugtraq report of buffer overruns in imapd LIST command Mark Crispin (Apr 17)
- RUS-CERT Advisory 200004-01: GNU Emacs 20 RUS-CERT, University of Stuttgart (Apr 18)
- More vulnerabilities in FP Narrow (Apr 18)
- Re: More vulnerabilities in FP The Cyberiad (Apr 19)
- Re: More vulnerabilities in FP Ron van Daal (Apr 22)
- Re: More vulnerabilities in FP The Cyberiad (Apr 19)
- AVM's Statement eAX [Teelicht] (Apr 19)
- Adtran DoS Mike Ireton (Apr 19)
