[1812] in bugtraq
Re: impossible vs. impractical
daemon@ATHENA.MIT.EDU (Tom Ptacek)
Sun May 14 06:30:22 1995
From: Tom Ptacek <lblack@onshore.com>
To: jon@netsys.com (jon)
Date: Sun, 14 May 1995 04:23:32 -0500 (CDT)
Cc: bugtraq@fc.net
In-Reply-To: <199505132028.NAA21364@netsys.com> from "jon" at May 13, 95 01:28:29 pm
> 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?!
First of all, let's get something straightened out here. A strict source
route is one wherein the packet follows EXACTLY the route specified in
the options field of the packet, or gets tossed. A loose source route is
one that allows the packet to use any number of intermediate routers and
gateways, as long as the packet goes sequentially through each hop
specified in the loose source route.
"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.
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.
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.
> 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.
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.
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.
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...
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 *"?
> For a mount client to implement source routed mount requests you'd
> probably have to rewrite all the RPC libs and replace clnt_create() &
> clnttcp_create().
Bah. Been there, done that. Make a dummy interface, assign it the IP of
the address you want to spoof. Rewrite clnttcp_create() to make source
routed connections (actually not all that necessary, since source routed
clnttcp_create functions have been written and are floating around
already), source route a connection through an intermediate hop host on
your LAN to your target host.
Have a static route set to your dummy interface on that hop host, and
your target will (if it's source routing works) think it's talking to
whoever you want it to think it's talking to.
Source routing is A Big Deal.
---------------------------------------------------------------------------
asriel@wookie.net
