3. "We were not very happy ..." is an understatement

posted Sep 15, 2010, 6:35 PM by Jeff Ogden   [ updated Sep 29, 2010, 7:05 AM ]
The following is one item from the sidebar article "Some Days Were Better Than Others" which appeared in the 13 May 1996 issue of the UM IT Digest (the "Goodbye MTS" issue):

The first MTS Workshop in Newcastle, England, took all the MTS developers away from Ann Arbor near the end of a term during which a U-M class had been assigned the problem of finding security holes in MTS. While no one was particularly surprised that these students found some holes, we were not very happy when they took advantage of their illegal access and started wreaking havoc in the system. This happened at a time when international networking was still very new and very primitive. To get a connection back to U-M, we had to use a very slow and unreliable long-distance phone connection from Newcastle to London, where the only international network connection in the United Kingdom was, in order to fix the security problems in Ann Arbor.
          –Mike Alexander

I remember working  with Mike Alexander, Scott Gerstenberger, and George Helffrich from a terminal in the Newcastle machine room. The network connection was a dial-up call to the BPO network which had a new X.25 interconnection to GTE's TELENET network which in turn had an interconnection to the Merit Network which was connected to UM's MTS system. We'd been challenged by Elizabeth Barraclough at the start of the MTS Workshop when she said that she expected that someone would make such a connection work before the Workshop was over. And after some arm twisting with the folks at the BPO, we were in fact able to make the connection work. At the time we didn't realize how we'd be using the new connection in just a few days time.

The long distance call, the network, or something was pretty noisy and unreliable. So unreliable that we didn't trust it to patch the system directly. Instead we put the system status commands into a file, printed the file out a few times and read it over very carefully, sent messages to the console warning the system operators in Ann Arbor about what we were going to do, and then sourced the file. It worked OK and we put the same patch into RAMROD. This kept the lid on things until some of us returned home and could fix things for real.

The task of patching the UM system was made considerably easier because an MTS distribution had recently been sent out and there were MTS listings in the Newcastle machine room that either exactly matched the system running back in Ann Arbor or were very close.

And after I got back to Ann Arbor, I got a message from Gavin Eadie (the Workshop coordinator) asking if UM would pay the bill for the use of the network. We did.

The class, Computer and Communication Sciences 673, Advanced System Programming, taught by Bernie Galler and Larry Flanigan, had 12 students.  The results from the class, without any mention of the "havoc", were reported in a widely referenced paper:

Hebbard, B., et al., "A Penetration Analysis of the Michigan Terminal System", ACM Operating Systems Review, pp. 7-20, Vol. 14, No. 1, January 1980. A PDF of the paper is available here.

From the paper:

This project was undertaken by a graduate-level computer science class at the University of Michigan in Ann Arbor. It was done at the invitation and with the full cooperation of the University of Michigan Computing Center, which is interested in assessing and improving the security of its operating system, the Michigan Terminal System (MTS).

The members of this team each had the advantage of several years' experience as users of MTS and had access to all user-level documentation and manuals. Since system documentation was made available to the team as well, the meeting time during the first few weeks of the project was devoted entirely to learning as much as possible about the internal structure of MTS. Members of the Computing Center staff gave lectures on their respective areas of responsibility, explaining in some detail the internal structure of various components, pointing out sources of more detailed documentation, and giving some introduction to the mountains of assembly-code listings.

Not mentioned in the paper was the fact that there was an explicit bargain struck between the UM Computing Center and members of the class. The CC staff would help the class get started and give them access to source code, the class was free to test out their ideas on MTS as long as they did not disrupt the operation of the system, and if they needed to do any tests that might be disruptive, they would come to us and we'd setup a test environment where they could do their tests safely. That bargain was not fully honored and I remember being annoyed with Bernie and Larry for not doing more to bring the class back into line.

All of the problems discovered by the class were fixed shortly after the developers returned from the UK. That isn't to say that there weren't other problems that had yet to be discovered.