[1813] in bugtraq
Re: impossible vs. impractical
daemon@ATHENA.MIT.EDU (jon)
Sun May 14 16:46:37 1995
From: jon <jon@netsys.com>
To: lblack@onshore.com (Tom Ptacek)
Date: Sun, 14 May 1995 12:35:17 -0700 (PDT)
Cc: jon@netsys.com, bugtraq@fc.net
In-Reply-To: <199505140923.EAA07859@onshore.com> from "Tom Ptacek" at May 14, 95 04:23:32 am
>
>
> > the kernel level. Still, for mountd the use is limited, you can, of course
> > implement a source routed mount request to mountd, using strict routing,
> > and it might be relatively easy to obtain a filehandle, however this will
>
> MIGHT be?!
?
>
> "Using strict routing" doesn't make much of a difference in this
> scenario, except that it limits what hosts you can hit (if it'll work at
> all with strict routing... I've never tried it) because of the limited
> space in the options field of the IP header. A loose source route will
> serve a hacker's purposes just fine, Thank You Very Much.
I have failed to do it with loose routing, however it's quite possible
that one of intermidiate routers blocked it.
However it worked with strict routing.
>
> And as long as the system in question will accept a source routed packet
> and respond (as Net/2 based code should, and the RFC states) with the
> inverse of the route, you WILL get a file handle. The whole process of
> getting a file handle in NFS relies on address-based authentication. Once
> you put yourself in a position where you determine the route that your
> target's packets take, addresses cease to be trustworthy.
>
You repeated my words here.
> As for the real-world feasibility of the attack, the tools to do this
> exist and are floating around. It isn't particularly hard to do,
> either... as long as you know the concept behind it, it's all pretty much
> common sense.
>
So has I said.
> > not always give you file access, at times, it gives you read access,
>
> I suggest you go take a look at the RFC for NFS.
Thank you for your suggestion.
>
> The entire system is BASED on the file handle. The nfs daemon
> SPECIFICALLY does not do authentication... I believe (I don't have the
> RFC sitting in front of me at this moment) that the system is arranged so
> that authentication is seperated from the gritty file i/o stuff, so that
> different authentication systems can be arranged.
RFC will not give you all information. All I meant was:
if more filtering rules on the router are used AND ip source routing is NOT
blocked you may find no use out of the filehandle you obtained from
your source-routed mount request.
There is no doubt that the authentication is based on the filehandle. I didn't claim otherwise.
>
> If you have the file handle of the exported filesystem you want to
> attack, you have every bit of access that the legitimate NFS clients
> have. If the legit NFS clients have read only access, yeah, there's no
> way I know of to get around that... but otherwise, you're good to go.
>
> > at times no access at all. If 2049/udp is filtered in the router,
> > you can still send an "unlink" requests, and cause damage, however
> > you can't retrive data because no reply is sent to you.
>
> Huh?
>
> If the port the nfs daemon is talking on is filtered at the router,
> unless the attacker can find a way to get around that filter (which
> depends on how the router is configured), said hacker is shit out of
> luck. Without any way of communicating with the nfsd, "unlink requests"
> aren't going to get through.
>
You're wrong.
On configuration when: 2049 udp, which is commonly being used for nfs
is blocked, and ip source routing is not, "unlink requests" are GOING to
get through -- in fact, any request will go through that doesn't require
any reply. Think of the logics
> Of course, the nfs daemon communicates through UDP... and UDP is Real
> Real Easy to spoof. If your router will allow certain packets (ANY
> packets, in fact) through whatever filtering mechanism you have set up,
> you've got a potential vulnerability...
You may apply filtering mechanisms that would reject packets that pretend tobe
coming from your internal network through the network interface that handles all
"external" traffic.
>
> BUT...
>
> An "unlink request" (as you put it) still requires a valid file handle
> (what inode are we addressing here?). If you have an EXTREMELY determined
> assailant on your hands, you have a potential problem in that there's a
> limited number of possible file handles for a filesystem to have, and if
> someone tried hard enough, they'll EVENTUALLY come across the right one.
>
> I've never done it. It can definitely be done, but I don't even KNOW of
> anyone who will actually sit and try to guess file handles. It'd be
> pretty trivial to write up a program that would continually send unlink
> RPC's with guessed handles, though... nohup it, stick it in the
> background on a secured system, and let it run for a few months, and see
> how much trouble it causes.
>
> Of course, if the mountd isn't appropriately secured, guessing file
> handles ceases to be a problem. Of course, if the mountd isn't
> appropriately secured, why waste time with unlink requests when you can
> just bust out with "rm *"?
Wrong approach
