From owner-freebsd-stable Tue Jul 13 5: 1:20 1999 Delivered-To: freebsd-stable@freebsd.org Received: from aurora.sol.net (aurora.sol.net [206.55.65.76]) by hub.freebsd.org (Postfix) with ESMTP id 4CEBF14CA8 for ; Tue, 13 Jul 1999 05:01:17 -0700 (PDT) (envelope-from jgreco@aurora.sol.net) Received: (from jgreco@localhost) by aurora.sol.net (8.9.2/8.9.2/SNNS-1.02) id GAA65497; Tue, 13 Jul 1999 06:58:01 -0500 (CDT) From: Joe Greco Message-Id: <199907131158.GAA65497@aurora.sol.net> Subject: Re: 3.x backdoor rootshell security hole In-Reply-To: from Robert Watson at "Jul 13, 1999 8: 9:30 am" To: robert@cyrus.watson.org (Robert Watson) Date: Tue, 13 Jul 1999 06:58:01 -0500 (CDT) Cc: stable@freebsd.org X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Mon, 12 Jul 1999, Doug Rabson wrote: > > > On Mon, 12 Jul 1999, Robert Watson wrote: > > ... > > > 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? > > Ideally some of the directories themselves, as well as /boot, parts of > /etc large parts of /sbin and /bin (including sh, as that gets run in > single-user mode)... My feeling is we should maintain a list, but not > ship that way as it would be irritating for most of the world. At one > point I had a script that did some of the work, but currently due to file > layout and the way we do config files, you end up with a fairly hobbled > machine. Which is, of course, the idea. :-) I think security(8) (?) > discusses a fair amount of this stuff. All of /sbin and /bin. These should never change. I did post a sample file protection script to -security a few months back. It also removed suid/sgid privilege on things that are not likely to be used (modifiable, of course, it basically just lists all suid/sgid progs). I believe that it will harden base filesystems on a FreeBSD box to the point of almost being annoying. Requires securelevel of course. ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message