Re: Security issues for nfs mount
Hi,
Although I am not familiar at all with the inner workings of nfs
the description below indicates a risk that an unauthorised client may
read files on the specific directory which is being exported by nfs read
only. However my worry is not whether somebody else will read the files
which in my cased is only a piece of software. My worry is whether anybody
can write to the directory being exported or any other directory of my
computer , given that the stuff on the exported directory are
mathematical software unrelated with the workings of the operating system
. I would be grateful if someone could clarify this point
Thanks
George
On Fri, 12 Sep 1997 ioannis@flinet.com wrote:
>
>
> 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 .
>
>
-------------------------------------------------------------------------------
George Kapetanios
Churchill College
Cambridge, CB3 0DS E-Mail: GK205@cus.cam.ac.uk
U.K. WWW: http://garfield.chu.cam.ac.uk/~gk205/work_info.html
-------------------------------------------------------------------------------
--
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 .
Reply to: