Re: Port 135 Probes Continue

From: Casper H.S. Dik (Casper.Dik_at_Sun.COM)
Date: 01/18/04 

Date: 18 Jan 2004 16:05:50 GMT

"Nico Kadel-Garcia" <nkadel@comcast.net> writes:

>No, there's a set of old issues involving guessing filehandles *without* the
>need to fake IP addresses. Last I looked, Sun had never fixed this problem.
>NFS filesystem security is a form of security through obscurity: while you
>can't easily guess the file associated with a filesystem in a thoroughly
>secured NFS system, you can guess at available filehandles and write to disk
>in a random fashion, corrupting the server quite quickly. This has been
>demonstrated to Sun by MIT hackers repeatedly, and at last look (admittedly
>2 years ago) they had never found a solution for the fundamental problem.

You need to fake the IP addresses; I assumed you were talking about
faked IP addresses because you were talking about writing but not
reading.

The reason that you need to fake IP addresses is because the Solaris
NFS server checks the NFS client IP address *on each RPC call*.

It keeps a cache of clients and calls mountd using a loopback transport
if it doesn't know the current caller.

So if you get a filehandle from mountd from a good client and give
it to a non-client, you cannot do anything unless you also fake
the IP address.

>And very, very few sites properly secure their NFS servers: simply running
>"showmount -e servername" usually gives you more than enough information to
>start an attack on vulnerable services, in particular for those sites that
>do not put the extra effort into authenticating client users. And frankly,
>very, very few sites do this.

It's unfortunate that little security "AUTH"_SYS is so much easier to
rdeploy than Kerberized NFS; of course, even with just AUTH_SYS you could
authenticate the clients using IPsec which would go some way to
protecting AUTH_SYS traffic.

But stronger authentication in the protocol is much preferred
(though it should be said that all the supposed "user" authentication
protocols assume secure or single user clients as the superuser
on the client has access to all credentials in use on the system.

>See above. There's a real problem, as I understand it, with guessing and
>scribbling on accessible filehandles.

Not with proper security mechanisms in place; guessing filehandles
only works as a mechanism to bypass mountd. But since Solaris 2.6
the Sun NFS server doesn't allow you to bypass mountd in such a
fashion. But if you fake the IP address and you know you have a
valid filehandle you can still do bad things but *only* as long
as you do not employ other security mechanisms such as:

        - IPsec
        - Secure auth flavours:
            - DH security for NFS
            - GSS-API security for NFS.

>Do you know *anyone* who operates NFSv4 in a home or small workplace
>environment?

I don't know anyone employing it at all except here internally at
Sun while testing Solaris.next.

But NFSv4 will not magically fix things, as you can still run it
in the "unsecure" mode. But it looks like NFSv4 will bring
the Linux community its first secure implementation of NFS.

>That... is a good point. But it means that, in practice, it's not there. For
>a system that's going to be directly exposed to the Internet, it's
>especially a problem.

If you mean "In practice, that means it is not availble for Linux;
and even for those OSes where it is available, it is often not
deployed", then I agree.

Casper 

-- 
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
Quantcast