From owner-freebsd-current Thu Jan 2 19:30:53 2003 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 95CA837B401 for ; Thu, 2 Jan 2003 19:30:51 -0800 (PST) Received: from zardoc.esmtp.org (adsl-63-195-85-27.dsl.snfc21.pacbell.net [63.195.85.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9276243EC5 for ; Thu, 2 Jan 2003 19:30:50 -0800 (PST) (envelope-from ca@zardoc.esmtp.org) Received: from zardoc.esmtp.org (localhost [127.0.0.1]) by zardoc.esmtp.org (8.12.7/8.12.7.Beta1) with ESMTP id h033UxGL031936 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 2 Jan 2003 19:31:00 -0800 (PST) Received: (from ca@localhost) by zardoc.esmtp.org (8.12.7/8.12.0.Beta12) id h033Ux9S029894 for freebsd-current@FreeBSD.ORG; Thu, 2 Jan 2003 19:30:59 -0800 (PST) Date: Thu, 2 Jan 2003 19:30:59 -0800 From: Claus Assmann To: freebsd-current@FreeBSD.ORG Subject: Re: 5.0-RC2 informal PR: 90 sec sendmail delay Message-ID: <20030102193059.A30727@zardoc.esmtp.org> References: <3E1352BC.4043921B@mindspring.com> <20030101145232.A391@zardoc.esmtp.org> <3E13D095.FC52B758@mindspring.com> <20030102104810.A27967@zardoc.esmtp.org> <3E14ACAC.2014C867@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <3E14ACAC.2014C867@mindspring.com>; from tlambert2@mindspring.com on Thu, Jan 02, 2003 at 01:18:36PM -0800 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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