Date: Sat, 23 Nov 1996 23:09:25 -0700 From: Warner Losh <imp@village.org> To: newton@communica.com.au (Mark Newton) Cc: marcs@znep.com (Marc Slemko), freebsd-hackers@freebsd.org Subject: Re: non-root users binding to ports < 1024 (was: Re: BoS: Exploit for sendmail smtpd bug (ver. 8.7-8.8.2).) Message-ID: <E0vRXkr-0004O4-00@rover.village.org> In-Reply-To: Your message of "Sun, 24 Nov 1996 13:44:51 %2B1030." <9611240314.AA03473@communica.com.au> References: <9611240314.AA03473@communica.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <9611240314.AA03473@communica.com.au> Mark Newton writes: : We already have one, it's called mail.local. mail.local doesn't execute shell scripts. In fact, mail.local makes it trivially easy to forge mail from any address that you desire the mail to come from. : As I tried to say to Warner, the whole idea of shoving shell execution into : the MTA is bogus. Not only does it blow the model of having seperate : delivery agents out of the water, it also leads to arguments like Warner's, : where continuing to run a demonstrably unsecure program with special : privilages is mandated to continue simply because the alternative would : break someone's pet feature. And as I tried to say that we're stuck with it. Sendmail provides the functionality of executing a program when mail is delivered. That functionality is politically impossible to remove. You have stated that it is a bad idea, but you have not offered an alternative. Nor have you really said why it is a good idea, beyond removing some bloat from sendmail. : Which is precisely why sendmail shouldn't be doing shell execution: History : has shown (and will, in all likelihood, continue to show) that sendmail is : woefully inadequate at checking data passed to it by users. I am not : aware of any sendmail security bugs which have been caused by major : architectural flaws, but in every case security bugs have been solved by : fixing up sendmail's sloppy implementation. Given that sendmail has shown : such a history of sloppiness, I'm simply amazed that we continue to : trust it with the front door keys to our systems. Just because there is a history of sloppiness does not mean we should throw the baby out with the bathwater. Sendmail has vastly improved in the last 20 or so releases. However, if you look at the rest of the system, you'll find that it is no worse than others. There are a boatload of programs that are setuid that have the much talked about buffer overflow problem. : Sendmail does not need root. Sendmail should not have root. Thus far, : the only argument I've seen to suggest that sendmail should have root is, : "We've always done it that way." There is currently no standard facility : to make it do it any other way, either. Permitting a selected subset : of non-root processes to bind to ports < 1024 is, IMHO, the first step : to such a stadnard. No. You weren't listening. I said that in order to retain useful and desired functionality, you must have sendmail run as root. Or you must have a setuid program that sendmail (and only sendmail) can run so that this functionality can be preserved. : > > While I think it is maybe useful to allow binding to port 1024 to : > > non-root programs, it is also potentially dangerous and should only be : > > entered into if you are sure that there are *NO* holes possible. : : This makes me laugh. I have no control over what you find funny, but it irrelevant to the discussion at hand. : Warner apparently favours the alternative, which : is that we're essentially certain that sendmail is full of holes, and we'll : knowingly continue to give it root to satisfiy the needs of a misfeature : (to whit: shell escapes). Please explain to me why shell escapes are a bad idea. Please explain to me why sendmail + smrsh is insecure. smrsh was designed to specifically increase the security of the shell escapes, and does a good job at that. I'm sorry that I'm not convinced by bald assertions. Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E0vRXkr-0004O4-00>