Re: Port 135 Probes Continue

From: Nico Kadel-Garcia (nkadel_at_comcast.net)
Date: 01/25/04

  • Next message: Bill Marcum: "Re: vpn tunnel and nat" 
    Date: Sun, 25 Jan 2004 00:18:51 -0500

    "Casper H.S. ***" <Casper.***@Sun.COM> wrote in message
    news:400aaede$0$329$e4fe514c@news.xs4all.nl...
    > "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.

    That... sounds right. This was a while ago, but when I chatted with a
    competent engineer about it last year he claimed the bug still existed.

    > >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.

    Unfortunately, every implementation of IPsec I've seen stores all the keys
    in plaintext. This is pretty unacceptable in any sane environment. Also,
    IPsec has gotten some poor reviews due to its overwhelming complexity and
    code drift: the Microsoft VPN tools (as implemented in the various Linux
    PPTP tools available) seems simpler to work with and use.

    > 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.

    Umm. There's access, and then there's obvious. Storing passwords on your
    filesystem only in encrypted format would be a good start.

    > >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.

    Hmm. You sure you can't scribble on the NFS exported filesystem with the
    various additional security features turned on?

    > >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.

    *GOOD*. That would be nice. How painful will it be to set up? Will it
    continue to hang both the server and the client and require both of them to
    reboot if you accidentally break the connection between them for several
    hours while the client tries to write to the server?

    > >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

    I meant "no one sets it up that way", for whatever reasons.

  • Next message: Bill Marcum: "Re: vpn tunnel and nat"
    • Quantcast