Summary of NFS Quest Responses

[ole!rwing!pat () nwnexus wa com (Pat Myrto)]

Bugtraq-ers:

I was asked by several to summarize to the list the answers I got
when I posted the following question.  The names have been removed
from the respones, because several asked me to not include their names.
So, I felt the safest was to not include ANY names, since direct
e-mail and posting responses to the list were saved in the same mail file.

My original question was:

> I suspect this is old stuff to many folks out there, but it is new stuff
> to me (as a result of being a victim of security through obscurity).
> A site I am associated with had its filesystems mounted by some site
> back East (we are on the West Coast) a few days ago.  One reason for
> this is because all the subdirs are exported with the line of the form
> (note the lack of 'access' options):  The operating system is SunOS
> 4.1.3, running on both Sun4 and Sun 4c platforms.  There is a firewall
> router, but it apparantly did not block this breakin.  Apparantly they
> could not write to much anything, but they apparantly tried to copy the
> data, because the system became so loaded on could not even see typed
> characters echo, for about 20 minutes.
>
> /pathname  -root=host1:host2:host3
>
> When I suggested changing it to the form of
>
> /pathname -root=host1:host2:host3,access=host1:host2,host3
>
> for better access control,  I was told this cannot be done because it
> messes up access permissions for various users.

The responses follow (many were similar, so are combined/paraphrased).
- -------------------------------------------------------------------
Response one:

We use the above permissions on Sun OS (4.1.x) and our Auspex (Sun   
file system) without problems. As I understand it, the 'access' is   
supposed to precede the 'root' entry. We use this on a lot of file   
systems to permit general access to many hosts, and root access to a   
few. We haven't run into any access bugs that we know of. The   
alternative is a world writable file system, which to me is a much   
more serious 'bug'!
- --------------------------------------------------------------------
Response Two:

Blocking port 2049 would be a good idea, as long as there's nobody at   
your site mounting one of the public NFS sites like wuarchive or   
gatekeeper. We are planning to do this eventually, although it may   
cause some wimpers from a few people. NFS is just too attackable. It   
is possible to access an NFS filesystem without going through   
rpc.mountd. This is why blocking 2049 is also a good idea, and why   
you should randomise your inodes. (If the inodes are not randomised,   
there are some well-known inode numbers that make it easy to 'walk'   
the filesystem without the help of 'mount'.)
- --------------------------------------------------------------------  
Response Three:

You could block all packets to port 2049 on your router (or even
to port 111 if you want to stop all RPC traffic)
- --------------------------------------------------------------------
Response Four:

Yeah we've been bitten by that before too, though fortunately not by
someone outside the company.  However, I don't consider this a case of
"security through obscurity", but rather just plain poor sysadmin
documentation on the part of Sun.  The way the man page reads, it's
easy to intuit that -root implies -access.  They should explicitly
tell you that it does not.

> One point I didn't ask - but was true for the affected site:

Also, our exports are mount points, not subdirs.  Perhaps that has
something to do with it.  As far as I can tell it shouldn't.  Btw, the
above also works on SGI's running 4.0.5.
- --------------------------------------------------------------------
Response Five:

It is necessary to set NFS up with a complete access list.  This should not
cause any problems for legitimate users.  The only known problem is the denial
of root access on an NFS mounted file system.  ie: when installing a package
as root and the NFS mounted file system has no root access.   

P.S.: If you obtain information on the use of X-windowing port for NFS
please pass it on.  I am sure what they are refering to is someone has
written rpc commands to run on port 6000.  NFS uses unsecured rpc to
access the data.  It is not a very  difdicult a program to write.
- ---------------------------------------------------------------------
Response Six:

What we do is disable NFS mounts across our firewall router.  In particular, we
do not allow inbound connections to port 2049 or 4045, which are the ports that
NFSD and LOCKD listen on.  This works quite well, and it sounds like your
firewall router does not cut these ports.

In case this helps, these are the ports we cut for security, on inbound
connections only:

TCP:
23 telnet
69 tftp
79 finger
111 sun rpc
144 NeWS
512 rexec
513 rlogin
514 rcmd
515 lpd
517 talk

UDP:
23 telnet
69 tftp
79 finger
111 sun rpc
144 NeWS
2049 NFSD
4045 LOCKD

When NFS v.3 becomes more common, we will have to block ports 2049 and 4045 on
TCP as well, I guess, since NFS v3 supports TCP as well as UDP.

Hope this helps.  Please generate a summary - I'd love to see what other people
do.
- ---------------------------------------------------------------------------
Response Seven:

  How we do the above is very similar to the above, the only thing we
  change is the order. ie.

/pathname -access=host1.domain:host2.domain,root=host1.domain:host2.domain

  We currently use FQDN on all hosts due to the fact that Solaris 2.x
  sorta forces this.
- ---------------------------------------------------------------------------
Response Eight:

What you can do to make life a little easier on yourself is get
Wietse's portmapper which features better access control and
better logging.  This will solve some problems of people going
through the portmapper as well as help you track down other problems.
This is not a total fix however as any attacker can simply hunt
for the port that mountd and nfsd are on without ever talking
to the portmapper.
- -------------------------------------------------------------------------
Response Nine:

     NIS and NFS are extremely insecure and probably buggy as well.
The first thing to do is check for patches from the vendor.  If it's
a Sun, you can get the securelib package, which contains replacements
for three routines in the shared library that do permission checking.
If it's not a Sun (or even if it is) you can get a replacement
portmapper that does permission checking.  Check out
ftp.win.tue.nl:/pub/security.  A couple of other good places to
check out are black.ox.ac.uk, ftp.tamu.edu, and
research.att.com:/dist/internet_security, archive.ohio-state.edu,
and of course ftp.cert.org (be warned, these guys have old versions
of security related software, so you're better off getting programs
from the other sites).
- ------------------------------------------------------------------------
Response Ten:

     I suggest you check out the Personal NetBlazer.  Try sending
mail to info () telebit com.  If that doesn't work then send mail to
postmaster () telebit com and ask where to send your mail.  I believe
the Personal NetBlazer can be had for under $2000US.  It is fully
capable of packet filtering.  It can also act as a terminal server.

=======================================================================
> I had also asked:
>
> I was also told that people could write a program to access NFS
> filesystems using the Xwindows port (whatever porT THAT is), and
> defeat all the export limitiations.  The person telling me this
> knows no details himself, "someone told him" apparantly, so that
> tidbit is next to useless to me.

And the responses generally were along the lines of:
- ------------------------------------------------------------------------
Response One:

I'd like to hear more about this too.  I'm sort of skeptical.  There
may be a way (hell, probably is given the lack of X security) to snarf
all sorts of data through the X server (usually port 6000, btw), but I
doubt it's anything NFS specific.
- ------------------------------------------------------------------------
Response Two:

Don't think that is possible (Xwindows is port 7000 I think).
- ------------------------------------------------------------------------
Response Three:

I have no knowledge of this.  Sorry.  Sounds kind of bogus to me,
though.  If this were true, then _all_ protocols, of any kind, would
seem to be vulnerabilities, and I just don't buy that.   There _is_ a
potential security bug in using xterm, if the xterm program is suid root,
AND the xterm program has the session logging feature enabled.  I've not
been able to get it to work myself, but others do claim this is a problem.
(You can cure this my removing the suid bit from xterm, but then xterm
doesn't record sessions in utmp, so the users become "invisible".  This may
or may not be a "useful feature". :-) )
- ------------------------------------------------------------------------
Response Four:

This sounds blatently wrong.  There is a loophole that lets one bypass
export limitations *in special circumstances* by going through the
portmapper (portmapper will happily forward your request,  replacing
the vital source address information and replacing it with a local
address...  how to exploit is left as an exercise).

sounds like they didn't do their firewalling right.  A proper firewall
shouldn't have passed any of the client NFS traffic [if that's what they
wanted].
====================== End Summary of all responses =======================

Thanks for all the responses and info (especially regarding ports to
disable to the outside world).  It pretty much underscored what I felt,
that access to rpc ports should be blocked in the router or firewall
system, but also its a good idea to set thing up right so it isn't TOO
easy to subvert in case somehow the router/firewall gets misconfigured
(which is what I think caused the original problem of the remote
mount from outside).

There was no consensus as to why users could not access files they had
rights to if the /etc/exports file was set up properly, with both the
- -access= and root= options properly specified.  I was simply TOLD this
was what occurred by the owner.  I never saw this happen MYSELF, so I
cannot speculate more on it.  I have concluded the problem was due to
something else and mis-diagnosed, but its the owners site, and I won't
beat the issue to death - if he wishes to believe that, more power to
him!!

One person did mention that it MIGHT be that the permissions at the
export point and the mount point differed, but that shouldn't be a
problem, I wouldn't think, anyway:  I commonly make mountpoints mode 0,
or 700 owner root to prevent any access when the filesystem isn't mounted,
since the perms that will be in effect will be whatever those are at
the root of the mounted filesystem are, once mounted.  That wasn't the case
on this site, though, the mount points were either mode 555, 755 or 777
(they varied).

Well, I tried to do what I can - that is all anybody can do!!  And learned
some good info in the process...

Hope this summary is sufficient for those who wanted some kind of summary
of the responses...

Thanks again!!  I will now resume lurking ...  :-)

- --  
pat@rwing  [If all fails, try:  rwing!pat () ole cdac com]  Pat Myrto - Seattle WA
"No one has the right to destroy another person's belief by demanding
empirical evidence."  --   Ann Landers, nationally syndicated advice columnist
and Director at Handgun Control Inc.