From owner-freebsd-security Mon Jul 12 12:36:14 1999 Delivered-To: freebsd-security@freebsd.org Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (Postfix) with ESMTP id 715A31514D; Mon, 12 Jul 1999 12:35:45 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from salmon.nlsystems.com (salmon.nlsystems.com [10.0.0.3]) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id UAA01594; Mon, 12 Jul 1999 20:33:43 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Mon, 12 Jul 1999 20:33:43 +0100 (BST) From: Doug Rabson To: Robert Watson Cc: Mark Newton , Mike Tancsa , security@freebsd.org, stable@freebsd.org Subject: Re: 3.x backdoor rootshell security hole In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 12 Jul 1999, Robert Watson wrote: > On Mon, 12 Jul 1999, Mark Newton wrote: > > > Mike Tancsa wrote: > > > > > Has anyone looked at the articled below ? Here is a quote, > > > "The following module was a nice idea I had when playing around with the > > > proc structure. Load this module, and you can 'SU' without a password. > > > > If you have enough privileges to load a module, you have enough > > privileges to su without a password already (by creating an suid > > shell, for example) > > In fact, if you have permission to modify the running kernel, you may have > more privilege than that of a root process, with securelevels.. :-) What > the THC posting is really about it hiding compromises on a machine that > has been compromised, and leaving backdoors. The title, "Attacking > FreeBSD..." is a little misleading, it's more about "Trojaning FreeBSD > Once You Already Have Absolute Control of a Machine". And these aren't > even very persistent: they have to be reloaded after each boot, meaning > changes to configuration files, etc, etc. Also if a site is running using securelevel, even root can't load files into the running kernel. The attacker would have to arrange to load the code during startup and reboot the box (a noticable event surely). Hmm. Shouldn't we protect the contents of /boot with the schg flag? -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message