Nevis Web Security Issues What was the issue?
Why was this changed without warning?
How should we set up our web pages now?

At 3:45 PM on 6-May-97, the links to root directories of the nevis1 disk packs were removed in /usr2/local/httpd/htdocs. This was done to eliminate a major security hole in the Nevis Web Site. The practical result of this is that some web links on existing pages that you created will no longer work.

What was the issue?

Until this change was made, it used to be that a URL of this form would work:

http://www.nevis.columbia.edu/usr6/ccfr/seligman
If you were to type this into your Web browser, you would see a list of all the files and directories in Seligman's account. You could then click on any of the files or directories to see its contents.

This could be very convenient. If you wanted to look at Seligman's files from a remote location, you could type in the above URL from any Web browser on the Internet. If you wanted to give a collaborator in Sweden the opportunity to look a particular directory, you could also just give them a URL. You wouldn't have to worry about anonymous FTP, guest logins, and the like.

The problem is that anyone on the planet could see those files as well, unless you specifically disabled read access to the file by chmod o-r filename. This was not restricted to just a few inquisitive hackers. In recent years, Web search services such as Yahoo, Excite, and Altavista have used "web robots" to gather information. These are programs that look at every single file accessible from every known web site and store the information in a searchable database.

Since all the Nevis disks were basically wide open, this means that all of your text files, including draft versions of articles and your private e-mail, could have been stored in such a database. Someone could go into Yahoo, search on "Bill Seligman", and find a reference to his name in an e-mail message you wrote three years ago and deleted, but whose text was still present in the file RMAIL~. An event such as this actually occurred at Nevis.

Why was this changed without warning?

It was necessary to close this security hole before making an announcement about it. Suppose we had said that the security hole existed and you had two weeks to correct your web sites. Then we would have drawn attention to the matter from hackers and robots searching on the words "security problem".

How should we set up our web pages now?

At this point, the URL listed above will not work. Neither will those URLs that implicitly relied on the security hole to work, e.g., http://www.nevis.columbia.edu/doegroup. A URL of the form

http://www.nevis.columbia.edu/~seligman/
will give a Web browser access to the directory ~seligman/WWW -- but not to any other directory in Seligman's account. If there is a subdirectory to the WWW account, ~seligman/WWW/data for example, then the following URL will give a browser read-access to all the files in that subdirectory:
http://www.nevis.columbia.edu/~seligman/data/
This means that Seligman can create a link in his WWW subdirectory to any other directory he wishes to share. For example, if he has files in /usr7/ccfr/seligman/publicdata/ that he wants to share with the world, he can execute the commands
cd ~seligman/WWW
ln -s /usr7/ccfr/seligman/publicdata pubdata
Then he can tell colleagues that if they wish to look at his files, they should use the URL
http://www.nevis.columbia.edu/~seligman/pubdata/

If you want to create a publically-accessible area for files that is not tied to your Linux cluster account, contact Bill Seligman. If you want a basic introduction to setting up a Web page at Nevis, look here.

The Internet is a vastly different world than it was five years ago, and we must learn to adapt. We are sorry for any inconvenience this change causes.


Back to the Nevis Computing Page.

Up to the Nevis Home Page.

E-mail: Send any comments or questions to the webmaster.