Re: impossible vs. impractical

[jon () netsys com (jon)]

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