karl@naitc.naitc.com (Karl Denninger) (12/01/90)
We're looking for an OS/2 TCP/IP implementation and NFS client with authentication. Please don't mention the IBM version 1.1 TCP services; these allow people to EASILY spoof any UID on the network! That is, you set your UID and GID through environment variables rather than provide any authentication! When I saw this I nearly freaked out..... Needless to say, this is rather insane! So much for the security we have managed to build over the past several months. Does anyone have a TCP/IP suite for OS/2? If so, please forward the info. Ads and pay-ware are just fine.... Email or post please! -- 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.
backman@FTP.COM (Larry Backman) (12/04/90)
In article <1990Nov30.211623.16555@naitc.naitc.com> karl@naitc.naitc.com (Karl Denninger) writes:
We're looking for an OS/2 TCP/IP implementation and NFS client with
authentication.
Does anyone have a TCP/IP suite for OS/2? If so, please forward the info.
Ads and pay-ware are just fine....
Karl;
You might want to check out our PCTCP for OS/2. It does not
currently support NFS clients but our next release will offer
an NFS Installable File System among other things.
Larry Backman
backman@ftp.comyozzo@ibm.com (12/05/90)
> > We're looking for an OS/2 TCP/IP implementation and NFS client with > authentication. > > Please don't mention the IBM version 1.1 TCP services; these allow people to > EASILY spoof any UID on the network! That is, you set your UID and GID > through environment variables rather than provide any authentication! When > I saw this I nearly freaked out..... > > Needless to say, this is rather insane! So much for the security we have > managed to build over the past several months. > > Does anyone have a TCP/IP suite for OS/2? If so, please forward the info. > Ads and pay-ware are just fine.... > > Email or post please! > > -- > 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. 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. ------------------------------------------------------------------------------ | Ralph E. Yozzo | DISCLAIMER: The opinions expressed | | IBM Thomas J. Watson Research Ctr. | herein are the Authors. | | Arpanet: yozzo@ibm.com | And are not necessarily those of his | | | employer or this station. | | Bitnet: yozzo@yktvmx.bitnet \---------------------------------------| | Home: ..!uunet!bywater!acheron!larouch!yozzo | Phone: (914) 945-3634 work | | | Phone: (914) 564-4731 home | ------------------------------------------------------------------------------
karl@naitc.naitc.com (Karl Denninger) (12/12/90)
In article <1990Dec5.153030.28086@arnor.uucp> yozzo@ibm.com writes: >> >> We're looking for an OS/2 TCP/IP implementation and NFS client with >> authentication. >> >> Please don't mention the IBM version 1.1 TCP services; these allow people to >> EASILY spoof any UID on the network! That is, you set your UID and GID >> through environment variables rather than provide any authentication! When >> I saw this I nearly freaked out..... >> >> Needless to say, this is rather insane! So much for the security we have >> managed to build over the past several months. >> >> Does anyone have a TCP/IP suite for OS/2? If so, please forward the info. >> Ads and pay-ware are just fine.... > >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. >------------------------------------------------------------------------------ >| Ralph E. Yozzo | DISCLAIMER: The opinions expressed | >| IBM Thomas J. Watson Research Ctr. | herein are the Authors. | 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. -- 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/13/90)
> > In article <1990Dec5.153030.28086@arnor.uucp> yozzo@ibm.com writes: > >> > >> We're looking for an OS/2 TCP/IP implementation and NFS client with > >> authentication. > >> > >> Please don't mention the IBM version 1.1 TCP services; these allow people to > >> EASILY spoof any UID on the network! That is, you set your UID and GID > >> through environment variables rather than provide any authentication! When > >> I saw this I nearly freaked out..... > >> > >> Needless to say, this is rather insane! So much for the security we have > >> managed to build over the past several months. > >> > >> Does anyone have a TCP/IP suite for OS/2? If so, please forward the info. > >> Ads and pay-ware are just fine.... > > > >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. > > >------------------------------------------------------------------------------ > >| Ralph E. Yozzo | DISCLAIMER: The opinions expressed | > >| IBM Thomas J. Watson Research Ctr. | herein are the Authors. | > > > 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. > > -- > 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. 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. I agree that OS/2 NFS shows the weakness in AUTH_UNIX, but anyone one using AUTH_UNIX should be aware of this problem. A unix user can write a program and say that they are any user they wish (except root). Does this mean that you are going to remove all the AUTH_UNIX NFS servers are from your network? 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
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
jim@ferkel.ucsb.edu (Jim Lick) (01/01/91)
In article <4984@idunno.Princeton.EDU> marty@pulsar.princeton.edu writes: >In article <1990Dec31.144240.13689@arnor.uucp>, yozzo@ibm.com writes: >|> 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. > Yozzo didn't make it completely clear what he meant. What he meant is that persons with root access can access files owned by anyone except root on the NFS mounted partition. In example: Suppose I give mount access to my /home partion on ferkel to someone with root access on alpo. All he has to do to access my 'jim' files is to create an account on alpo with my UID and GID, and then su to that user. True, unless you have a root= option in the exports file, the user on alpo has only limited access to all root owned files, but all others are wide open. I consider this to be a significant security risk, as many people will set up whole partitions as world or site accessible. It's important to export only to machines you are personally responsible for, or trust, if you have files you need to protect. Jim Lick Work: University of California | Home: 6657 El Colegio #24 Santa Barbara | Isla Vista, CA 93117-4280 Dept. of Mechanical Engr. | (805) 968-0189 voice/msg 2311 Engr II Building | (805) 968-1239 data (805) 893-4113 | (805) 968-2734 fax jim@ferkel.ucsb.edu | Soon: jim@cave.sba.ca.us
karl@naitc.naitc.com (Karl Denninger) (01/03/91)
In article <4984@idunno.Princeton.EDU> marty@pulsar.princeton.edu writes: >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. However, you can do this: $ su Password: xxxxxxx # su karl cd /users/karl (where /users/karl is a NFS filesystem) ls -al ..... Since you can change your UID to anything you want if you're root, you can get to any file which a user (not root) can get to should you desire. If you can't get root, however, this problem does not occur.... -- 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.
thurlow@convex.com (Robert Thurlow) (01/03/91)
In <4984@idunno.Princeton.EDU> marty@puppsr.Princeton.EDU (Marty Ryba) writes: >In article <1990Dec31.144240.13689@arnor.uucp>, yozzo@ibm.com writes: >|> Given [the root password], 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. (So I'll be the fifth person to respond. Big deal :-) Yes, but they can try anything they want as any non-root uid, like bin or daemon or whatever works. Check the man page for su :-) Heck, they can probably try all UIDs in a loop without the server even logging a complaint about an apparent spoof attempt. I agree with yozzo; AUTH_UNIX is full of holes and inflexible. The only pluses are that it is cheap to use, easy to implement and does not introduce vexing system administration issues, which I can't say about AUTH_DES. Maybe if we can smooth out the rough spots of AUTH_DES, we can get something we can trust out there. Rob T -- Rob Thurlow, thurlow@convex.com or thurlow%convex.com@uxc.cso.uiuc.edu ---------------------------------------------------------------------- "This opinion was the only one available; I got here kind of late."
brent@terra.Eng.Sun.COM (Brent Callaghan) (01/03/91)
In article <4984@idunno.Princeton.EDU>, marty@puppsr.Princeton.EDU (Marty Ryba) writes: > 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. That's true, but you've misunderstood the original statement. As root on your own workstation there's nothing to stop you su'ing to someone else. In the su shell you'll have a new set of credentials and these will be conveyed faithfully across the wire by NFS. In this case there's no root credentials going across the wire. As Ralph points out, AUTH_UNIX is very easy to spoof. If you want the convenience of AUTH_UNIX and are concerned about security then you should restrict the export access to trusted hosts. Then you just have to worry about IP address spoofing.... -- Made in New Zealand --> Brent Callaghan @ Sun Microsystems Email: brent@Eng.Sun.COM phone: (415) 336 1051
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