Re: Security issues for nfs mount
:-) In this case you may as well post your root passwd in Yahoo. On Fri, Sep 12, 1997 at 09:02:59PM +0100, G. Kapetanios wrote: > > 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 -- Ioannis Tambouras [EMAIL PROTECTED], West Palm Beach, Florida Signed pgp-key on key server. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
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 [EMAIL PROTECTED] 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 > [EMAIL PROTECTED], West Palm Beach, Florida > Signed pgp-key on key server. > > > -- > TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to > [EMAIL PROTECTED] . > Trouble? e-mail to [EMAIL PROTECTED] . > > --- George Kapetanios Churchill College Cambridge, CB3 0DSE-Mail: [EMAIL PROTECTED] 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 [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Security issues for nfs mount
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 [EMAIL PROTECTED], West Palm Beach, Florida Signed pgp-key on key server. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Security issues for nfs mount
Ioannis Tambouras wrote: > 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? Cheers, - Jim pgpYNozTVDntA.pgp Description: PGP signature
Re: Security issues for nfs mount
The traditional unix nfs filesystem is _insecure_ : the i-node generation number, which is part of the file handles, is easy to guess. -- Ioannis Tambouras [EMAIL PROTECTED], West Palm Beach, Florida Signed pgp-key on key server. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Security issues for nfs mount
> Hi, > > I was wondering whether there is anything to worry about if I let > another machine nfs mount, read only, root-squash, one directory on my > machine. Any help will be greatly appreciated. > > Thanks > George I don't think there should be problem with that. (unless, of course, you don't restrict who can connect, and you leave important information like credit card numbers or passwords in that directory) Cheers, - Jim pgpqfwHZ40Dx7.pgp Description: PGP signature
Re: Security issues for nfs mount
> > Hi, > > I was wondering whether there is anything to worry about if I let > another machine nfs mount, read only, root-squash, one directory on my > machine. Any help will be greatly appreciated. The only problem I can think of is that root-squash may not be enough (an attacker may still read files owned by "shadow", etc). So /tmphostname(ro,squash_uids=0-100,squash_gids=0-80) may be slightly more safe. But after that, I don't anticipate any problems. If anyone still knows problems with that, I'd be interested to hear! -- joost witteveen, [EMAIL PROTECTED] #!/usr/bin/perl -sp0777ihttp://www.dcs.ex.ac.uk/~aba/rsa/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Security issues for nfs mount
Hi, I was wondering whether there is anything to worry about if I let another machine nfs mount, read only, root-squash, one directory on my machine. Any help will be greatly appreciated. Thanks George --- George Kapetanios Churchill College Cambridge, CB3 0DSE-Mail: [EMAIL PROTECTED] 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 [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
