Date: Thu, 2 Jan 2003 19:30:59 -0800 From: Claus Assmann <freebsd+current@esmtp.org> To: freebsd-current@FreeBSD.ORG Subject: Re: 5.0-RC2 informal PR: 90 sec sendmail delay Message-ID: <20030102193059.A30727@zardoc.esmtp.org> In-Reply-To: <3E14ACAC.2014C867@mindspring.com>; from tlambert2@mindspring.com on Thu, Jan 02, 2003 at 01:18:36PM -0800 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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. 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. > 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. > 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. > In other words, in this particular case, you have added security > through obscurity... which is generally acknowledged as not really > increasing security at all. This is not "security through obscurity". > 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. > 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. 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?20030102193059.A30727>