Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 29 Jul 1997 08:32:21 -0400 (EDT)
From:      Robert Watson <robert@cyrus.watson.org>
To:        Vincent Poy <vince@mail.MCESTATE.COM>
Cc:        Brian Buchanan <brian@thought.res.cmu.edu>, freebsd-security@FreeBSD.ORG, JbHunt <johnnyu@accessus.net>, "[Mario1-]" <mario1@primenet.com>
Subject:   Re: securelevel (was: Re: security hole in FreeBSD)
Message-ID:  <Pine.BSF.3.95q.970729082232.5972D-100000@cyrus.watson.org>
In-Reply-To: <Pine.BSF.3.95.970728173307.3844R-100000@mail.MCESTATE.COM>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 28 Jul 1997, Vincent Poy wrote:

> On Mon, 28 Jul 1997, Brian Buchanan wrote:
> 
> =)Uh, that would defeat the purpose of securelevel.  It's not supposed to be
> =)possible to ever lower it, except when dropping into single-user mode, and
> =)even allowing init to do so in that instance is risky IMHO - a few months
> =)ago I reported a hole, which I believe was fixed, that made it possible to
> =)lower the securelevel by attaching a debugger to init.  Even though that's
> =)plugged now, it's still possible that there's another way to fool the
> =)kernel into thinking that process 1 is requesting that securelevel be
> =)lowered.
> 
> 	Anything is possible since nothing is unhackable.  Would running
> init at securelevel 2 and then have it reboot multi-user at a lower level
> be possible?

I disagree with the assertation that nothing is unhackable.  My toaster is
unhackable. :)  Depending on how you define hack, of course.  But in a
similar vein: you say you have been carefully following the latest version
releases, and patching all known bugs.  That is not sufficient.  A site
needs a good security policy as well as patching known bugs.  For example,
you should have been using ssh the entire time, and have copied the public
keys for the hosts to your client machine using sneaker-net.  Sending any
unencrypted data to/from a host, especially sensitive information like the
root password, is an extremely bad idea.

Similarly, careful analysis of the trust relationships between the
machines and accounts on the machines is important -- constructing a bad
DNS structure can invalidate your whole security design, as if DNS is
corrupted, all the .rhosts stuff is vulnerable.  Ideally, you would only
use .rhosts in combination with SSH, and then make sure that the
appropriate keys are in /etc/ssh_whatever, and deny connections that did
not match the predefined keys of all hosts.  Key distribution is one of
the big downsides to SSH, but floppy disks can help here.

Applications like web servers may themselves represent no immediate or
known security problems, but often-times web servers use third party CGI
programs, available publicly in source, or written by a third party for
the web server.  Many web programs are notoriously sloppy (or ignorant),
and this has not been helped by the release of a number of CGI programming
books that haven't even touched on the issue of security.  It has been
shown time and time again that greater access for an attacker increases
risk, and most CGI bugs allow shell access to the host, albeit as www or
nobody.  Even those are problematic.  And once someone is in to the
system, they can get around simple solutions like disabling inetd.  In 15
seconds, I can compile and run a daemon that lets me back into an account
on a higher port number, and unless you know your tools are good, and how
to use them, you won't be able to tell.  I certainly won't appear in the
logs. :)

In the case of someone else's machine, you probably can't do anything to
get rid of the CGI problems, so that really leaves you with just
minimizing the risks in the OS.  You've already touched on SUID programs
-- as many as possible should be disabled.  If you have console access,
just disable root also, as you can login as root directly.  Most programs
do not require suid, if you don't mind administrating as root.  Su'ing to
root is clearly a risky activity, especially if you're logged in
unencrypted.  Setting a high secure-level, as well as mounting all file
systems w/o setuid support, can make a big difference.  Mount all file
systems but root as nodev, and things should move along some also.



  Robert N Watson 

Junior, Logic+Computation, Carnegie Mellon University  http://www.cmu.edu/
Network Security Research, Trusted Information Systems http://www.tis.com/
Network Administrator, SafePort Network Services  http://www.safeport.com/
robert@fledge.watson.org   rwatson@tis.com  http://www.watson.org/~robert/




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95q.970729082232.5972D-100000>