karl@naitc.naitc.com (Karl Denninger) (12/26/90)
In article <1990Dec13.000905.24664@arnor.uucp> yozzo@ibm.com writes: >> >> In article <1990Dec5.153030.28086@arnor.uucp> yozzo@ibm.com writes: >> >> >> >The real trouble lies in the AUTH_UNIX authenication scheme. >> >For better security, use the AUTH_DES authenication scheme. >> > >> >Currently, IBM OS/2 TCP/IP does not support the AUTH_DES security >> >scheme. (Read: You set your UID and GID by environment variables!) I wrote: >> IE: IBM's OS/2 TCP/IP implementation doesn't support any security, and >> if you have NFS-exported filesystems on your network, you're hosed >> should anyone decide to take advantage of the "hole". If you're >> foolish enough to have "root" mapped to uid 0, then you can be >> REALLY hosed. Take note, diskless-workstation boot nodes! >> >> I >know< that AUTH_UNIX isn't perfect. However, many vendors (B&W, Sun, >> etc) have managed to make a reasonable pass at doing authentication by using >> a daemon for this. It's not perfect, but it's much better than nothing at >> all! (Environment variables?!) >> >> You won't stop a dedicated hacker, no. We don't have to. This is a >> corporate environment; I can safely operate on the assumption that the >> people who work here are working here, not hacking into our network for fun >> and profit. However, this "hole" just makes it too easy and tempting. I >> certainly can't sanction this product's use at Nielsen in it's present form. >> >> How and why did IBM release something which they >knew<, in advance, was >> this dangerous to network security? >> >> I did note that they DID do something about MVS NFS servers; there's a login >> program for them. But only if your server is a MVS machine.... which most >> aren't. >> >> I have no intention of letting that package anywhere near our network, >> unless I emasculate it first and remove things like NFS from the stack. >> >>If IBM decides to fix it, it has the appearance of a real nice package. Right >> now it's a time bomb waiting to go off. >> >> Alternatives welcome. Yozzo wrote.... >A future version of OS/2 NFS should have AUTH_DES support. > >We had AUTH_UNIX authentication using the PCNFSD daemon but it was >removed becausing the testing group did not feel that they could >test it in time. So instead IBM released it with no authorization at all. That is, you allow anyone to set any UID and GID they want, and just go to it. I (and I bet a bunch of other network managers) would have rather you not release the product than do this. Or take the time to at least support something like the PCNFSD authentication daemon.... >I agree that OS/2 NFS shows the weakness in AUTH_UNIX, but anyone >one using AUTH_UNIX should be aware of this problem. No, OS/2 NFS doesn't show the weakness, it exploits it. There is a fundamental difference. Note well: Unsafe operating systems (such as OS/2 and MSDOS) don't permit "good" security in a file-sharing environment regardless of what one does (remember, if you can peek and poke....) However, one doesn't have to leave the door to the barn wide open with a big sign reading "STEAL ME" visible from the street as has been done here! It would seem as though one could do an AUTH_UNIX implementation with PCNFSD and store the validated UID and GID in system space somewhere (ie: protected memory) where a user application couldn't touch it.... and be somewhat safe. It would certainly be much better than what you have done now! >A unix user can write a program and say that they are >any user they wish (except root). Not unless you can get root privileges on the system you're working with..... if you can do that, just "su" to the user you want to impersonate. (I am assuming that the NFS server host(s) are doing port checking which at least makes an attempt to see if you're coming from a reasonable place with privileges to get to the port......) It certainly is >possible< to do your own client-level NFS stuff. If you're crazy (or motivated) enough to do this then you're definately in the "hacker" catagory - writing filesystem code isn't one of my favorite pasttimes. Again, we're not terribly worried about this -- it's the nature of our environment here that people are assumed to be working for the company :-) MSDOS users can certainly break in, IF they can write a RPC library (yeah, right) or get the calls into another one that is existant (without documentation this is again a heck of a lot of work!) This is a weakness of MSDOS, in that someone could "poke" a UID into a structure, etc.... Someone dedicated enough to do this can just tap the Ethernet wire and pull frames off the LAN, looking for passwords, can't they? Does anyone out there allow TELNET connections..... if so, AUTH_DES doesn't help you at all given a Sniffer or it's equivalent! >Does this mean that you are going to remove all the AUTH_UNIX NFS servers >are from your network? No, but it does mean we'll remove IBM's OS/2 TCP/IP from our building! And it means we won't buy it until and unless it's fixed as long as I have to sign off on the product.... where we otherwise would have. We would love to have all AUTH_DES servers. Unfortunately, this isn't the majority of available NFS servers right now. Furthermore, if we DO implement that your OS/2 NFS is completely useless at present, isn't it? >It does not have to be a hacker. It only takes one program that >accepts parameters as to what uid and gid you would like to be. > >Ralph E. Yozzo And access to a RPC library, and one other condition -- root on the workstation. We don't give that out around here; there is no need for development purposes, and certainly no need for routine user level stuff. We (and others) have lived with those conditions for quite some time. In a "friendly" environment it's reasonable to do so. OS/2 TCP/NFS, on the other hand, allows people to just "walk in" without having so much as a "C" compiler at hand, or any knowledge of what they're doing! While I'm at it, it would be nice if OS/2's TCP supported RARP and BOOTP for IP address assignment.... nearly all MSDOS products of this type do, so why not in OS/2's TCP/IP? I still contend that the security problem is nothing short of incredible, and makes the product a darn good candidate for "most dangerous software release of 1990". -- Karl Denninger AC Nielsen kdenning@ksun.naitc.com (708) 317-3285 Disclaimer: Contents represent opinions of the author; I do not speak for AC Nielsen on Usenet.
yozzo@ibm.com (12/31/90)
This problem exists in any LAN where the users have the root password for there own machine. I do not know about your environment but a lot of environments that I have seen, the users have there own workstation and they have the root password on their workstation. Given this, they can 'su' to any user they wish and therefore can spoof NFS. One way to limit access is to only export to machines that you trust. Regarding the mounting being limited to reserved ports, It is not the case that every NFS server checks that the Mount request is coming from a reserved port. Another problem with AUTH_UNIX is when users have different UID's and GID's on different machines. Again this lead to NFS spoofing. All these cases deal with Unix spoofing. Basically, AUTH_UNIX is not secure. If you want real security, you should not be using AUTH_UNIX NFS. Ralph Yozzo
marty@puppsr.Princeton.EDU (Marty Ryba) (01/01/91)
In article <1990Dec31.144240.13689@arnor.uucp>, yozzo@ibm.com writes: |> I do not know about your environment but a lot of |> environments that I have seen, the users have there own workstation |> and they have the root password on their workstation. |> Given this, they can 'su' to any user they wish and |> therefore can spoof NFS. What!? From what I understand of NFS (at least Sun NFS), UID root will *NOT* be accepted for most activities. On SunOS, root on a client machine can only modify a filesystem if it has been exported -root=<client>. Check the man page for exportfs. Marty Ryba | slave physics grad student Princeton University | They don't care if I exist, Pulsars Unlimited | let alone what my opinions are! marty@pulsar.princeton.edu | Asbestos gloves always on when reading mail
hutton@nic.cerf.net (Tom Hutton) (01/08/91)
One of the ways we stop people with workstations on their desks from impersinating others is that we dont allow them to have root on their workstation. If they *MUST* have root, then we dont let them onto are network cable. Tom Hutton San Diego Supercomputer Center