Bugtraq mailing list archives
Re: impossible vs. impractical
From: jon () netsys com (jon)
Date: Sun, 14 May 1995 12:35:17 -0700 (PDT)
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 willMIGHT 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
Current thread:
- Re: impossible vs. impractical, (continued)
- Re: impossible vs. impractical Aleph One (May 08)
- R. Thomas's NFS question PETER.T.WHITING () sprint sprint com (May 09)
- Re: R. Thomas's NFS question Marek Michalkiewicz (May 10)
- RE: Anon site needed for FIP[S] PUB 190 Lawrence E. Bassham (May 09)
- unsubscribe bugtraq parkerm@cs49.holloman ParkerM,TSgt,49CS/SCSC (May 09)
- Please, please, _please_ (was Re: impossible vs. impractical) G.J.W. Hagenaars (May 08)
- Re: Please, please, _please_ (was Re: impossible vs. impractical) ATM_Feel_the_Power (May 09)
- Re: impossible vs. impractical John F. Haugh II (May 10)
- Re: impossible vs. impractical jon (May 13)
- Re: impossible vs. impractical Tom Ptacek (May 14)
- Re: impossible vs. impractical jon (May 14)
- Re: impossible vs. impractical Tom Ptacek (May 14)