Date: Thu, 02 Jan 2003 20:03:43 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Claus Assmann <freebsd+current@esmtp.org> Cc: freebsd-current@FreeBSD.ORG Subject: Re: 5.0-RC2 informal PR: 90 sec sendmail delay Message-ID: <3E150B9F.3F29FB8E@mindspring.com> References: <rgptrg1uzx.trg@localhost.localdomain> <3E1352BC.4043921B@mindspring.com> <20030101145232.A391@zardoc.esmtp.org> <3E13D095.FC52B758@mindspring.com> <20030102104810.A27967@zardoc.esmtp.org> <3E14ACAC.2014C867@mindspring.com> <20030102193059.A30727@zardoc.esmtp.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Claus Assmann wrote: > On Thu, Jan 02, 2003, Terry Lambert wrote: > > Claus Assmann wrote: > > > What can you do with smmsp group access? > > > Send tons of SPAM. Execute code as mailuser to raise my priviledge > > to root, and then execute code as root. > > > 8-). > > Show me a way to do the latter. If you can do that, then it's > a bug that needs to be fixed. If it's a bug that needs to be fixed, it's a bug in the host OS, and not something that sendmail can address. Priviledge escalation for normal users to root on UNIX machines is an ongoing problem, which has not yet been solved. The easiest way to do it is a "trojan horse" program that you leave around, e.g. named "ls", that you hope someone running at an escalated priviledge runs. Basically, sendmail can't dictate that no one put "." as the first element of their root shell path, no matter what else happens on the system. > There have been too many problems in sendmail that caused security > holes, even remote root access. The redesign of sendmail will get > rid of that, and this includes that there is not set-user-ID root > binary and as little code as possible will run as root. It will get rid of immediate root access. It will not address OS problems that permit escalation. The problem before and after the change is identical, if sendmail permits conversion from a client of sendmail to a client of arbitrary code that is running as the user that sendmail runs as. The gatekeeper *must* be enforcement against exploits that permit an attacker to run arbitrary code at *any* priviledge level. As I said before, I understand the PR problem of having a remote exploit be a remote root exploit vs. a remote $MAILUSER exploit: the marketing value of being able to claim a guarantee of "no potential remote root exploits", when you are being disingenous and are really guaranteeing only that there are no *first order* remote root exploits enabled by the software can't be underestimated, I think. But in terms of real security, it's always going to reduce to "at most, as secure as the host OS", anyway (e.g. the Linux setgid() shared library priviledge drop prevention exploit, to use your own example). > > If the environment is not secure, then the system is not secure, > > by definition. For this particular case, the Linux system is going > > to be insecure, unless you remove all setuid() programs that attempt > > to drop root priviledges from the system. If it's still possible to > > See how easy it was to avoid that problem? > No set-user-ID root -> no root exploit. You didn't avoid it. You merely made it into a two step process, instead of a one-step process. > > get in to execute code as the UID of the mail user, then it's possible > > that the code you execute would be another setuid() program that is > > succeptible to the problem, and therefore you've only added an extra > > step to the exploit, rather than eliminated the possiblity. > > Please show me how. If sendmail could be exploited by replacing the shared library implementation of setuid()-as-used-to-drop-priviledges, then using a buffer overflow attack to get a shell as the user $MAILUSER permits me to use precidsely the same exploit to obtain root on the box: sendmail opens the door to the escalation, even if it is not itself the proximal means of the esclation to root. If, on the other hand, you could not run arbitrary code from a client in the context of $MAILUSER, then it would not matter if $MAILUSER was "bob", or if $MAILUSER was "root". My problem with this is that it changes the focus from preventing the running of arbitrary code by a network client, which is where I personally think the focus should be, to one of damage control, which only prevents certain kinds of damage, to the extent that the host OS was vulnerable, regardless of whether it was running sendmail or some other program. > > The general security threat out there is knowledgable attackers > > who write tools that get into the hands of "script kiddies", who > > are not themselves capable of writing the attacks, but are able > > to run them just fine, once they are written. Such a change does > > nothing in defense against the knowledgable attacker. > > Wrong. Which statement is wrong, in your opinion: the first, or the second? > > It's really a matter of where you put your walls. > > If I put one stone in wall that needs to removed such that the whole > wall collapses then the design of the wall is broken. I agree. Hense my statement that this is really a propaganda issue for achieving parity with postfix, qmail, and other programs which incorrectly claim to "make you safe", when they fail to address the escalation from network client to $MAILUSER running arbitrary code. You could have addressed the problem equally well, merely by running in a chroot environment, with the process still running as root. It's the name "root" that holds all the mojo, in this case, with the promise that because the compromises which occur from unknown future bugs will require additional effort for priviledge escalation from $MAILUSER to root, that the software is somehow safe, because it's OK to let an attacker run as $MAILUSER, or because you implicitly guarantee that there are no methods on the host system for exclation of priviledge from $MAILUSER to root, once you have a shell running as $MAILUSER. It's a false sense of security. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E150B9F.3F29FB8E>