poj@daimi.dk (Per Olsvig Jensen) (05/25/89)
I'd like to start a discussion on the matter:
PC-NFS and System Security.
As I see it, giving a PC, where the terms user, username, userid
and so forth doesn't exist at all, access to NFS on ie. a SUN with
profound user access security check, is bound to create security
holes. I mean, who can assure you, that on the PC, the person using
PC-NFS is really the one PC-NFS thinks he is. All PC-NFS seems to
check, is that the UserId and GroupId are the right ones. It is
intended that these Ids are set up by User Authentication, but what
in the world prevents a hacker from setting up this information
himself ?
In fact it took me less than half an hour to locate the UserIds
etc. in the memory of PC-NFS an to set them as I liked. Once these
Ids are set, nothing seems to prevent me from mounting an other
users files on the SUN, writing them or deleting them as I would
like to.
The only comment I've found on that in my PC-NFS Users Manual
is in the chapter of "NFS Server Issues" concerning "User Authen-
tication" and "System Security" stating:
" user ids do not enhance the server's security, but ....
Sun is working on secure RPC protocols. When these become
available, they will be incorporated in PC-NFS.
You should also be aware that PC-NFS poses the same security
problems as other network functions that are buildt on RPC.
For password checking, the encryption emplyed by net name is
trivial. " ...
I agree, except I can't see using secure RPC will help as long
the critical information for security check is stored very simply
in the PC memory, and accessible to everyone.
Am I wrong on this, or do you have any comments ?
PS. The version of PC-NSF we're using is Version 2.00, not that
it matters.
Regards
Per Olsvig Jensen
Computer Department
University of Aarhus, Denmark.kjeld@iesd.dk (Kjeld Flarup) (05/25/89)
In article <2373@daimi.dk> poj@daimi.dk (Per Olsvig Jensen) writes: > I'd like to start a discussion on the matter: > PC-NFS and System Security. > In fact it took me less than half an hour to locate the UserIds >etc. in the memory of PC-NFS an to set them as I liked. Once these >Ids are set, nothing seems to prevent me from mounting an other >users files on the SUN, writing them or deleting them as I would >like to. It is correct that you can't sucure any data in memory on a 8088 machine. However possible on 80286 in vitual mode this is never used. Now i would not claim to know anything about the PC-NFS system. But how can the server when communicating with a remote machine know that this remote machine is a machine belonging to the system. This issues an even bigger problem with networking. It is possible to tap the communication between machines. Unless everything is encrypted with the correct password, it is infact public. So you say that you can change your user id and group. Right immediately i see two quite obviously solutions. 1) Do not let the PC know that there are other disk area's than these it is allowed to access. (That sure is the MS-DOS ghost ) 2) Install a translator process on the server, that generates new codes for User and Group id each time a login is performed. Thus it would be impossible to change these to anything else with a meaning. My conclusion is that MS-DOS is and always will be a low security system, and when connecting it to other systems it automaticly becomes the weakest point in the chain. Kjeld Flarup Christensen | "I'am now twentyseven times older than the universe kjeld@iesd.dk | itself." Marvin the depressed Robot.
boomer@athena.mit.edu (Don Alvarez) (05/25/89)
In article <2373@daimi.dk> poj@daimi.dk (Per Olsvig Jensen) writes: > >...it took me less than half an hour to locate the UserIds >etc. in the memory of PC-NFS and set them as I liked. Once these >Ids are set, nothing seems to prevent me from mounting another >user's files on the SUN, writing to them or deleting them. > >...I can't see how using secure RPC will help as long >the critical information for security check is stored very simply >in the PC memory, and accessible to everyone. > >Am I wrong on this, or do you have any comments ? Before you conclude that PC's are the problem, ask yourself "why is it any harder to get a UNIX computer to commit the same security breaches that you just committed with your PC?" Hint: you just have to read a few more manuals and know how to get root privileges on the machine. Welcome to the wonderful world of NFS. -Don Alvarez -- + -------------------------------------------------------------------------- + | Don Alvarez M.I.T. Center For Space Research (617) 253-7457 | | boomer@SPACE.MIT.EDU Moving Soon: Princeton University Gravity Lab 8/89 | + -------------------------------------------------------------------------- +
geoff@hinode.east.sun.com (Geoff Arnold) (05/26/89)
In article <11668@bloom-beacon.MIT.EDU> boomer@space.mit.edu (Don Alvarez) writes: >In article <2373@daimi.dk> poj@daimi.dk (Per Olsvig Jensen) writes: >> >>...it took me less than half an hour to locate the UserIds >>etc. in the memory of PC-NFS and set them as I liked. Once these >>Ids are set, nothing seems to prevent me from mounting another >>user's files on the SUN, writing to them or deleting them. >> >>...I can't see how using secure RPC will help as long >>the critical information for security check is stored very simply >>in the PC memory, and accessible to everyone. >> >>Am I wrong on this, or do you have any comments ? > >Before you conclude that PC's are the problem, ask yourself "why is it >any harder to get a UNIX computer to commit the same security breaches >that you just committed with your PC?" > >Hint: you just have to read a few more manuals and know how to get >root privileges on the machine. > Don is correct. Unless you can physically secure the system and disable "-s" type reboots, any Unix system is potentially as insecure as a PC. In fact, it's more so, since you don't have to grovel around with a disassembler and find the right bits: the documentation tells you how to do it. With current Sun and Sun-derived NFS implementations, you probably want to control which hosts can mount sensitive file systems using the netgroup mechanism. This means that anyone trying to break in has to use or impersonate a trusted host - still not a significant barrier, but better than nothing. However Per is incorrect when he says that secure RPC won't help. This is because with secure RPC you would have to synthesize not just a UID/GID but a public-key-encrypted short-lifed "ticket" (to borrow the Kerberos term). My understanding of the state of this particular art is that the only way to really spoof such schemes is with a combination of host impersonation (probably involving gateway subterfuge) and messing around with the network time source(s). One PC ain't gonna cut it. [After all's said and done, fixing NFS without doing something about the other network services is pretty useless. Anyone with a Sniffer(tm) or similar network monitor can snarf up all the passwords (s)he wants, assuming that telnet or ftp is being used....] Geoff Arnold, Internet: garnold@sun.com Manager, PC-NFS Engineering UUCP: ....!sun!garnold PCDS Group, Sun Microsystems Inc. "A disclaimer? Sure, at that price you can have half a dozen of 'em."
frank@hpwrce.HP.COM (Frank Stutzman) (05/26/89)
> This issues an even bigger problem with networking. It is possible > to tap the communication between machines. Unless everything is encrypted > with the correct password, it is infact public. Phoey. Of course anyone with a good lan analyzer is able to intercept any packets on the network and read them. The question is wether or not its worth the effort. A good analyzer is an expensive piece of equipment that the average joe is not going to have lying around. If you have to worry about this, you shouldn't have a lan at all. I realize this this is a big drift off of pc-nfs, but hey, a statement like that I couldn't let slip by. |==================================================================| |Frank Stutzman | "When your only tool | |Hewlett-Packard Western Response Center | is a hammer, every | |Mtn. View, Ca | problem becomes a | |frank@hpwrc.hp.com | nail" - C.W. Ford | |==================================================================|
davidr@hplsla.HP.COM (David M. Reed) (05/27/89)
Actually, it is not much different than a user logging in on a terminal and walking away without logging out. Now anyone can walk by and have access as someone they are not. We have keyboard locks on our PC's here, and users are to lock there keyboards when they are away from their desks. Otherwise, there really is very limited security. As I view it, there is little difference between a PC and a workstation or terminal, other than it being slightly quicker and slightly easier to do on a PC what can still be done on the other.
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) (05/27/89)
In article <578@eagle_snax.UUCP>, geoff@hinode.east.sun.com (Geoff Arnold) writes: > > ...My understanding of the state of this particular > art is that the only way to really spoof such schemes is with a combination > of host impersonation (probably involving gateway subterfuge) and > messing around with the network time source(s)... Arp packets are a handy tool for impersonation, at least given the passive response of standard 4.xBSD network code to the theft its IP address. If you use the 4.3BSD timed as a network time source, and unless the timed code has had substantial changes to make it picky about who it thinks is a timelord, any machine in the network can change the network time. I spent a lot of time banging on the BSD timed code, with limited success. There are seemingly grievous errors in the TSP protocol, beyond the complete lack of provision for authentication & authorization. One may hope that someone at Sun is smarter than I. > [After all's said and done, fixing NFS without doing something > about the other network services is pretty useless. Anyone with > a Sniffer(tm) or similar network monitor can snarf up all the > passwords (s)he wants, assuming that telnet or ftp is being used....] Agreed. However, there is no need to buy a fancy box if all you want to do is snarf passwords. If I didn't have access to the snazzy network monitoring tools on my IRIS workstation, I would use etherfind on the nearest Sun. (Of course I never have and expect never to abuse the tools that way.) Aren't there snoopy ethernet products for PC's? > Geoff Arnold, Internet: garnold@sun.com > Manager, PC-NFS Engineering UUCP: ....!sun!garnold > PCDS Group, Sun Microsystems Inc. Vernon Schryver Silicon Graphics vjs@sgi.com
jfc@athena.mit.edu (John F Carr) (05/29/89)
In article <578@eagle_snax.UUCP> geoff@hinode.UUCP (Geoff Arnold) writes: >With current Sun and Sun-derived NFS implementations, you probably >want to control which hosts can mount sensitive file systems using >the netgroup mechanism... >However Per is incorrect when he says that secure RPC won't help. This >is because with secure RPC you would have to synthesize not just a >UID/GID but a public-key-encrypted short-lifed "ticket" (to borrow >the Kerberos term). My understanding of the state of this particular >art is that the only way to really spoof such schemes is with a combination >of host impersonation (probably involving gateway subterfuge) and >messing around with the network time source(s). One PC ain't gonna cut it. >[After all's said and done, fixing NFS without doing something >about the other network services is pretty useless. Anyone with >a Sniffer(tm) or similar network monitor can snarf up all the >passwords (s)he wants, assuming that telnet or ftp is being used....] Many of these concerns are addressed by the combination of Kerberos and Kerberos-authenticated NFS. Kerberos is used to set up a mapping from a {client-host,userid} to a {userid,gid...} on the server (most often, this is the same userid, but it need not be as long as the client kernel is smart enough not to get confused). Our NFS servers have an option for each exported partition to export it in "fascist" mode. This means that you can not mount an NFS filesystem if you do not have a uid map set up (the set of users who can map to the server is stored in a file). We use this option to NFS export source code which is not freely distributable (kernel sources, for example). This increases the requirment for breaking security, because it is necessary to impersonate a host that has mappings to the server (as well as the userid with mappings). Until there is an encrypted NFS, this is about as good security as you can get. I claim that in the general case it is much better than host-based export restrictions, since the goal is usually to restrict who can access the filesystem rather than from where they can access it. --
vail@tegra.UUCP (Johnathan Vail) (06/02/89)
In article <2373@daimi.dk> poj@daimi.dk (Per Olsvig Jensen) writes: I'd like to start a discussion on the matter: PC-NFS and System Security. As I see it, giving a PC, where the terms user, username, userid and so forth doesn't exist at all, access to NFS on ie. a SUN with profound user access security check, is bound to create security holes. I mean, who can assure you, that on the PC, the person using PC-NFS is really the one PC-NFS thinks he is. All PC-NFS seems to check, is that the UserId and GroupId are the right ones. It is intended that these Ids are set up by User Authentication, but what in the world prevents a hacker from setting up this information himself ? Your problem is that the access information is stored in your computer. In the implementation I have when you boot and bring up NFS it asks you for username and password to get write access. Read access is allowed anywhere it is usually allowed. As I see it your security issues are: Physical security of the machine and ethernet (which is not considered secure) And access security. People should reboot when they are done if they are worried about security. At any rate, unless there are bugs that I am not aware of the issues are no different than a workstation. Log off when you are done and don't keep passwords on the machine. "A screaming comes across the sky" _____ | | Johnathan Vail | tegra!N1DXG@ulowell.edu |Tegra| (508) 663-7435 | N1DXG@145.110-,145.270-,444.2+,448.625- -----
huitema@mirsa.inria.fr (Christian Huitema) (06/05/89)
From article <11714@bloom-beacon.MIT.EDU>, by jfc@athena.mit.edu (John F Carr): > ................ Until there is an encrypted NFS, this is about as good > security as you can get... Obviously, the current NFS protocol is ``as insecure as possible'', and until the Kerberos fixed are applied, security can only be achieved by physical protection -- in short, use it in a physically controlled small size local net, and trust all the users... However, Kerberos will not solve everything, for much of the weakness derives from two major design choices: a stateless protocol + mount per host. Greater security would be achieved with a connection oriented model + one connection per user. Christian Huitema