The NFS protocol wasn't just stateless, but also securityless!
Stewart, remember the open secret that almost everybody at Sun knew about, in which you could tftp a host's /etc/exports (because tftp was set up by default in a way that left it wide open to anyone from anywhere reading files in /etc) to learn the name of all the servers a host allowed to mount its file system, and then in a root shell simply go "hostname foo ; mount remote:/dir /mnt ; hostname `hostname`" to temporarily change the CLIENT's hostname to the name of a host that the SERVER allowed to mount the directory, then mount it (claiming to be an allowed client), then switch it back?
That's right, the server didn't bother checking the client's IP address against the host name it claimed to be in the NFS mountd request. That's right: the protocol itself let the client tell the server what its host name was, and the server implementation didn't check that against the client's ip address. Nice professional protocol design and implementation, huh?
Yes, that actually worked, because the NFS protocol laughably trusted the CLIENT to identify its host name for security purposes. That level of "trust" was built into the original NFS protocol and implementation from day one, by the geniuses at Sun who originally designed it. The network is the computer is insecure, indeed.
And most engineers at Sun knew that (and many often took advantage of it). NFS security was a running joke, thus the moniker "No File Security". But Sun proudly shipped it to customers anyway, configured with terribly insecure defaults that let anybody on the internet mount your file system. (That "feature" was undocumented, of course.)
While I was a summer intern at Sun in 1987, somebody at Sun laughingly told me about it, explaining that was how everybody at Sun read each other's email. So I tried it out by using that technique to mount remote NFS directories from Rutgers, CMU, and UMD onto my workstation at Sun. It was slow but it worked just fine.
I told my friend Ron Natalie at Rutgers, who was Associate Director of CCIS at the time, that I was able to access his private file systems over the internet from Sun, and he rightfully freaked out, because as a huge Sun customer in charge of security, nobody at Sun had ever told him about how incredibly insecure NFS actually was before, despite all Sun's promises. (Technically I was probably violating the terms of my NDA with Sun by telling him that, but tough cookies.)
For all Sun's lip service about NFS and networks and computers and security, it was widely know internally at Sun that NFS had No File Security, which was why it was such a running inside joke that Sun knowingly shipped it to their customers with such flagrantly terrible defaults, but didn't care to tell anyone who followed their advice and used their software that they were leaving their file systems wide open.
Here is an old news-makers email from Ron from Interop88 that mentions mounting NFS directories over the internet -- by then after I'd told him about NFS's complete lack of security, so he'd probably slightly secured his own servers by overriding the tftp defaults by then, and was able to mount it because he remembered one of the host names in /etc/exports and didn't need to fetch it with tftp to discover it:
>From: Ron Natalie <elbereth.rutgers.edu!ron.rutgers.edu!ron@rutgers.edu>
Date: Wed, Oct 5, 1988, 4:09 AM
To: NeWS-makers@brillig.umd.edu
>I love a trade show that I can walk into almost any booth and
get logged in at reasonable speed to my home machine. One
neat experiment was that The Wollongong Group provided a Sun
3/60C for a public mail reading terminal. It was lacking a
windowing system, so I decided to see if I could start up NeWS
on it. In order to do that, I NFS mounted the /usr partition
from a Rutgers machine and Symlinked /usr/NeWS to the appropriate
directory. This worked amazingly well.
>(The guys from the Apple booth thought that NeWS was pretty neat,
I showed them how to change the menus by just editing the user.ps
file.)
>DonHopkins on Sept 28, 2019 | parent | context | favorite | on: A developer goes to a DevOps conference
>I love the incredibly vague job title "Member, Technical Staff" I had at Sun. It could cover anything from kernel hacking to HVAC repair!
>At least I had root access to my own workstation (and everybody else's in the company, thanks to the fact that NFS actually stood for No File Security).
>[In the late 80's and early 90's, NFSv2 clients could change their hostname to anything they wanted before doing a mount ("hostname foobar; mount server:/foobar /mnt ; hostname original"), and that name would be sent in the mount request, and the server trusted the name the client claimed to be without checking it against the ip address, then looked it up in /etc/exports, and happily returned a file handle.
>If the NFS server or any of its clients were on your local network, you could snoop file handles by putting your ethernet card into promiscuous mode.
>And of course NFS servers often ran TFTP servers by default (for booting diskless clients), so you could usually read an NFS server's /etc/exports file to find out what client hostnames it allowed, then change your hostname to one of those before mounting any remote file system you wanted from the NFS server.
>And yes, TFTP and NFS and this security hole you could drive the space shuttle through worked just fine over the internet, not just the local area network.]
Sun's track record on network security isn't exactly "stellar" and has "burned" a lot of people (pardon the terrible puns, which can't hold a candle to IBM's "Eclipse" pun). The other gaping security hole at Sun I reported was just after the Robert T Morris Worm incident, as I explained to Martha Zimet:
>Oh yeah, there was that one time I accidentally hacked sun.com’s sendmail server, the day after the Morris worm.
>The worm was getting in via sendmail’s DEBUG command, which was usually enabled by default.
>One of the first helpful responses that somebody emailed around was a suggestion for blocking the worm by editing your sendmail binary, searching for DEBUG, and replacing the D with a NULL character.
>Which the genius running sun.com apparently did.
>That had the effect of disabling the DEBUG command, but enabling the zero-length string command!
>So as I often did, I went “telnet sun.com 25” to EXPN some news-makers email addresses that had been bouncing, and first hit return a couple of times to flush the telnet negotiation characters it sends, so the second return put it in debug mode, and the EXPN returned a whole page full of diagnostic information I wasn’t expecting!
>I reported the problem to postmaster@sun.com and they were like “sorry oops”.
The NFS protocol wasn't just stateless, but also securityless!
Stewart, remember the open secret that almost everybody at Sun knew about, in which you could tftp a host's /etc/exports (because tftp was set up by default in a way that left it wide open to anyone from anywhere reading files in /etc) to learn the name of all the servers a host allowed to mount its file system, and then in a root shell simply go "hostname foo ; mount remote:/dir /mnt ; hostname `hostname`" to temporarily change the CLIENT's hostname to the name of a host that the SERVER allowed to mount the directory, then mount it (claiming to be an allowed client), then switch it back?
That's right, the server didn't bother checking the client's IP address against the host name it claimed to be in the NFS mountd request. That's right: the protocol itself let the client tell the server what its host name was, and the server implementation didn't check that against the client's ip address. Nice professional protocol design and implementation, huh?
Yes, that actually worked, because the NFS protocol laughably trusted the CLIENT to identify its host name for security purposes. That level of "trust" was built into the original NFS protocol and implementation from day one, by the geniuses at Sun who originally designed it. The network is the computer is insecure, indeed.
And most engineers at Sun knew that (and many often took advantage of it). NFS security was a running joke, thus the moniker "No File Security". But Sun proudly shipped it to customers anyway, configured with terribly insecure defaults that let anybody on the internet mount your file system. (That "feature" was undocumented, of course.)
While I was a summer intern at Sun in 1987, somebody at Sun laughingly told me about it, explaining that was how everybody at Sun read each other's email. So I tried it out by using that technique to mount remote NFS directories from Rutgers, CMU, and UMD onto my workstation at Sun. It was slow but it worked just fine.
I told my friend Ron Natalie at Rutgers, who was Associate Director of CCIS at the time, that I was able to access his private file systems over the internet from Sun, and he rightfully freaked out, because as a huge Sun customer in charge of security, nobody at Sun had ever told him about how incredibly insecure NFS actually was before, despite all Sun's promises. (Technically I was probably violating the terms of my NDA with Sun by telling him that, but tough cookies.)
For all Sun's lip service about NFS and networks and computers and security, it was widely know internally at Sun that NFS had No File Security, which was why it was such a running inside joke that Sun knowingly shipped it to their customers with such flagrantly terrible defaults, but didn't care to tell anyone who followed their advice and used their software that they were leaving their file systems wide open.
Here is an old news-makers email from Ron from Interop88 that mentions mounting NFS directories over the internet -- by then after I'd told him about NFS's complete lack of security, so he'd probably slightly secured his own servers by overriding the tftp defaults by then, and was able to mount it because he remembered one of the host names in /etc/exports and didn't need to fetch it with tftp to discover it:
>From: Ron Natalie <elbereth.rutgers.edu!ron.rutgers.edu!ron@rutgers.edu> Date: Wed, Oct 5, 1988, 4:09 AM To: NeWS-makers@brillig.umd.edu
>I love a trade show that I can walk into almost any booth and get logged in at reasonable speed to my home machine. One neat experiment was that The Wollongong Group provided a Sun 3/60C for a public mail reading terminal. It was lacking a windowing system, so I decided to see if I could start up NeWS on it. In order to do that, I NFS mounted the /usr partition from a Rutgers machine and Symlinked /usr/NeWS to the appropriate directory. This worked amazingly well.
>(The guys from the Apple booth thought that NeWS was pretty neat, I showed them how to change the menus by just editing the user.ps file.)
>-Ron
I posted about this fact earlier:
https://news.ycombinator.com/item?id=21102724
>DonHopkins on Sept 28, 2019 | parent | context | favorite | on: A developer goes to a DevOps conference
>I love the incredibly vague job title "Member, Technical Staff" I had at Sun. It could cover anything from kernel hacking to HVAC repair!
>At least I had root access to my own workstation (and everybody else's in the company, thanks to the fact that NFS actually stood for No File Security).
>[In the late 80's and early 90's, NFSv2 clients could change their hostname to anything they wanted before doing a mount ("hostname foobar; mount server:/foobar /mnt ; hostname original"), and that name would be sent in the mount request, and the server trusted the name the client claimed to be without checking it against the ip address, then looked it up in /etc/exports, and happily returned a file handle.
>If the NFS server or any of its clients were on your local network, you could snoop file handles by putting your ethernet card into promiscuous mode.
>And of course NFS servers often ran TFTP servers by default (for booting diskless clients), so you could usually read an NFS server's /etc/exports file to find out what client hostnames it allowed, then change your hostname to one of those before mounting any remote file system you wanted from the NFS server.
>And yes, TFTP and NFS and this security hole you could drive the space shuttle through worked just fine over the internet, not just the local area network.]
Sun's track record on network security isn't exactly "stellar" and has "burned" a lot of people (pardon the terrible puns, which can't hold a candle to IBM's "Eclipse" pun). The other gaping security hole at Sun I reported was just after the Robert T Morris Worm incident, as I explained to Martha Zimet:
>Oh yeah, there was that one time I accidentally hacked sun.com’s sendmail server, the day after the Morris worm.
>The worm was getting in via sendmail’s DEBUG command, which was usually enabled by default.
>One of the first helpful responses that somebody emailed around was a suggestion for blocking the worm by editing your sendmail binary, searching for DEBUG, and replacing the D with a NULL character.
>Which the genius running sun.com apparently did.
>That had the effect of disabling the DEBUG command, but enabling the zero-length string command!
>So as I often did, I went “telnet sun.com 25” to EXPN some news-makers email addresses that had been bouncing, and first hit return a couple of times to flush the telnet negotiation characters it sends, so the second return put it in debug mode, and the EXPN returned a whole page full of diagnostic information I wasn’t expecting!
>I reported the problem to postmaster@sun.com and they were like “sorry oops”.
I've mention that one a couple times before:
https://news.ycombinator.com/item?id=29250313
https://news.ycombinator.com/item?id=21101321