Re: Securing a Linux Firewall

["Stephen P. Berry" <spb () meshuggeneh net>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Carson Gaspar writes:

> No. Doing an basic application security analysis does not require doing the 
> full filesystem dependency analysis.

Well, it's worth pointing out that a significant portion of this `full
filesystem dependency analysis' of some widget foo consists of:

        # ldd /usr/local/bin/foo
        # truss -r all -w all -f /usr/local/bin/foo \
                | grep -E -e 'open|read|write|exec' 
                (or the equivalent with ktrace/strace/whatever)

...and then run your regression/acceptance test(s) against foo.

I'm not saying that's -all- you'll need to do---just that you're making
it sound a lot more scary than it is.  I say again:  it ain't -easy-,
but it ain't hard, either.


> And in reality, doing so is not 
> possible, as you cannot know all the dependencies in a closed-source 
> product unless you can fully excercise all functions.

Once again, this sounds like an argument for miminal builds.  You know
what you -want- it to do, and you presumably have some way of exercising
that functionality.  Hopefully you have more than that---if you're
interested in hardening the box at all, you presumably have some sort
of functional spec with a regression or acceptance test for it.  At
any rate, you can certainly verify that your widget does what you want
it to do.  If the widget tries to do something else, then the proper
failure mode is for it to try and fail (which it will do if your minimal
install doesn't include something it wants) rather than to try and
succeed (which it will if you've installed everything).

At least, that -should- be the correct failure mode for a box you're
trying to harden.  This gets us back to the fundamental philisophical
bone of contention:  a box you've taken the trouble to harden shouldn't
do anything you don't want it to do;  if it does do something unexpected,
it should be a failure mode;  and if it is a failure mode, you should be the
one controling it (rather than the application designer or the luser).
Controlling failure modes is one of the most important aspects of
a security architecture.  Things like bare bones OS installs help you
to control failure modes;  default, include-everything OS installs do
not.


> What would convince me? Show me a vulnerability that is exploitable on my 
> system that isn't on yours.

Posit:

You're running some service foo which has a remotely exploitable
vulnerability.  The cookbook exploit gives the evildoer a shell prompt
with the UID of the process, which is nobody or some other unprivileged
luser.

Take a look at what evildoers are actually doing once they get that
prompt.

        -Connect to an outside host to download a rootkit
                Default install:  attacker uses ftp client
                Minimal install:  ftp: Command not found.
        -Untar/uncompress the a rootkit (presumably they rewrote the
         exploit to cat the rootkit to a file rather than fork /bin/sh)
                Default install:  attacker untars rootkit
                Minimal install:  tar: Command not found.
        -Run some widget bar from the rootkit (they rewrote the expoit
         again to write each of the components to an seperate file)
                Default install:  attacker runs widget
                Minimal install:  ./bar:  error while loading shared libraries:
                        libfoozle.so.0: cannot open shared object file: No
                        such file or directory

...and so on.

Even assuming no escalation of privileges (because you chmod'd all the
setuid/setgid stuff), there are things that a normal login environment
will give even an unprivileged luser:

        -Reconnaissance.  The bad guy can collect information about
         versions and revs, local network topology, local luser names,
         installed software....
        -Data.  If you're running a web server as httpd and a bad guy can
         get a prompt as httpd, you should expect that he'll be able to
         get to anything that httpd can get to.  That means that if your
         customers are entering information into web forms, the evildoer
         can get that information.  Depending on your setup, he may also
         be able to snag credential information that the service uses (i.e.,
         a cert for SSL) which he might use elsewhere (i.e., in setting
         up a clone site to get a customer talking to him instead of you)
        -Easier avenues of attack.  Even if you do defence in depth, chances
         are there are some assets that are easier to reach from a compromised
         box than from the outside.  I.e., if your web server talks to a
         backend database, it's probably easier to attack the database from
         the web server than the outside world.
         An unprivileged luser on the local system is also probably going to be
         able to launch a DOSes more easily than an outsider---both against
         the compromised box (i.e., file descripter snarfing and that kind
         of thing), as well as nearby boxen (i.e., bandwidth attacks against
         machines on the same segment)
        -Sockets.  A local luser will probably have an easier time
         getting your box to participate in a ddos, become a warez
         distribution site, whatever---being unprivileged just means they
         can't use the low-numbered ports.  And most sites are less likely
         to block/audit outbound traffic from one of their boxen than
         inbound traffic to it

This is just a quick overview.  Of course the more you have installed,
the more the badguy can do.  


> Any attacker with half a brain can install any tool he wants on the box, 
> once he's on the box. Yes, having a compiler installed makes his life 
> easier. But not having one doesn't stop him. It may indeed slow him down. 
> So would running VMS.

I'm not sure exactly what the requisite brain fraction is, but I think
you're underestimating the difficulty of turning a buffer overflow into
an actual compromise if the environment the exploited process is running
in is really spartan.  I.e., if the evildoer pops off the stack into
an environment without a /usr/bin .

Could he conceivably get the tools he wants onto the box (and working)?
Possibly, if he's motivated enough.  But the length of time it'll take
him to get settled will almost certainly be longer than my response time.
Particularly if I'm getting paged if someone tries to use ps(1) on
the box.

Now, I'm not saying that doing a rm -rf on /usr/bin is always possible,
nor am I saying that alarming on use of ps is always worthwhile.  But that's
within the scope of what I'm talking about, and it sure as heck isn't
something a partially decerebrated evildoer will shrug off.









- -spb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (OpenBSD)

iD8DBQE9T0CdG3kIaxeRZl8RAiCpAKDLZyqXVlORii0RXdhdU6TSoUvGSQCgkoJD
aUF7oQ/D44x4oidx2Vcl5EU=
=nBNw
-----END PGP SIGNATURE-----
_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards