Re: Security issues for nfs mount

[ioannis@flinet.com]

 I could resist to your request, Jim, and appear before you with further 
 clarifications, for you are an active contributor in the Debian project
 and we are quite fortunate to have you here among us; moreover, there in 
 an ancient saying, that "hard is the knowledge of the good."  And the
 knowledge of nfs is a great part of knowledge. If I had not been busy, I
 might have reviewed all the relevant rcf's, which is a complete education 
 in nfs mechanics and then I should have been at once able to answer your
 question about the IO mechanics. But, indeed, I have only a limited time,
 and therefore, I do not know the truth about such matters; I will, however, 
 gladly assist you in the investigation of them. We say that an nfs server
 running nfs-ver_1, or nfs-ver_2, can be tricked to perform unauthorized IO.
 But, there is a good deal of difficulty in describing this sort of knowledge
 in a public list, therefore we better investigate the description of it,
 instead on the specific steps that we are now supposing.

 Lets reflect on the nature of the io request.

 The file handle is a simple structure of 32 bytes for version 2 (although
 this was increased with version 3 to 64 bytes) and is created by the
 server, who passes it back to the client, and then the client uses the 
 file handle to access the file. All the server does does is validate the
 file handle (the ticket) when the io request is made. Supply the right 
 handle and you are in. 

 Guessing the fields of the structure is not extremely difficult. Most
 of the information is already known: major and minor device numbers,
 i-node number, etc. Everything is known except the i-node
 generation number whose purpose is to provide security and is chosen 
 when the open request is made. The generation number is implementation
 dependent; it may, even, be a sequential(!) number, but allow, for the 
 sake of this discussion, this to be a truly random number. My distinct 
 recollection from the relevant rfc [1] is that the width of this number
 is small, either 16 or 32 bits, we could, of course, if we must, go back
 to the specification and verify the truth of this, yet this weakness of
 (traditional) nfs is so well known and is as old as I dare remember. It will
 not take a giant to place many requests until one succeeds, and it does 
 not prevent an 12-year old to run an exploit that was written very many
 years ago. 



[1] The "opaque" structure, the file handle definition, is a simple
    typedef in rfc1094 . The actual details should then be in the XDR
    rfc1014 , I must assume, for I do not have it here locally to examine.


> >   The traditional unix nfs filesystem is _insecure_ : the
> >  i-node generation number, which is part of the file handles, is easy
> >  to guess. 
> 
> I'm curious.  How would an attack on nfs using this method proceed?


-- 
Ioannis Tambouras 
ioannis@flinet.com, West Palm Beach, Florida
Signed pgp-key on key server. 


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-user-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .