Our long-time friend, GRG, is back again, this time with tales of anti security...

A very long time ago, he worked at a University Computer Center. At the time, the school was the proud owner of two huge, hulking mainframes. (The faster of the two was big, gray, probably designed by a guy named Seymour, and was the fastest computer in the world for several years!) Unfortunately, the operating system was rather bare-bones. Thus, although you couldn't do much, you could do it without fear of the OS getting in your way. For example, you could store files (one directory per user), compile FORTRAN or COBOL or Pascal programs, or run SPSS, and that was about it. Unless you were willing to creatively think outside the box...

Also, another side effect of the bare-bones nature of the system, the security was a bit...weak. All the usernames, passwords, and permissions were kept in one unencrypted binary file. If you could get hold of that file, you had all the keys to the kingdom.

The system helpfully provided an ordinarily very useful feature where by if a program aborted, the system would keep the program's current files attached to the job. An interactive session was one long "job", so if you interrupted, say, the password change program, you would find the password file still attached to your job and you could read it at your leisure. Even more helpful, the dump program printed out 8 words per line which was the exact binary record length of each validation record. Thus, you could get a nice printout of the validation file with almost no effort at all.

After a while, the admins patched up this hole, sort of, by having the password program turn off terminal interrupts. That worked for about three days, until someone figured out that they hadn't turned off the "CPU time limit exceeded" abort. If you set your CPU time limit to 1 second, then ran a program that used up something like 0.990 seconds, and then chained to the password change program, the time limit would expire inside the password changer and you'd have the password file again. This state of affairs lasted about a month, but sadly, it too got patched.

Then somebody noticed that the operating system tried to be efficient, and if you had some FORTRAN "blank common" area, neither the OS nor the loader would initialize that area, so you'd see all kinds of garbage in your blank common. Sometimes you'd see data from other programs, editor buffers, and such. Hmmm, so you could peek at abandoned memory... Sure enough, if you ran the password changer and then dumped blank common, you could see the the I/O buffer that the password program used. It was conveniently 1024 words long so you'd have a peek at the 128 usernames and passwords around your username at a time. Handy.

Not to be outdone, someone else thought Hmmm, I wonder how they keep the password files synchronized between the two mainframes? This was before Ethernet, but both mainframes had access to a big box of extended memory... perhaps they passed the password file back and forth through that? It turns out the system came with a useful utility program named "DUMPECS" (Extended Core Storage). All you had to do was change your password and quickly type "DUMPECS" and you'd see the whole validation file printed out. They didn't clear ECS after each use. And conveniently the password file transfer happened at the same address in ECS that you'd get from DUMPECS. *Joy*

That went on for a few more months before ECS started returning all zeros on the first read. Darn. Then someone noticed that the regular usernames did not work during "system time", after midnight. Hmmm, how did they do that? The system wasn't very flexible, so they probably had to copy the real validation file to somewhere else and copy in a special validation file with just staff usernames. If you were lucky and they were a little bit tired at 6AM, they might copy the full file back but forget to delete it. Or they might forget to make it a private file. Or they might forget to password protect it. Anything can happen at 6AM. Sure enough, one morning there was a file called VALIJUN in the system directory, but it was password protected. Very clever. However the first password someone tried ("NUJILAV") worked!

There were other ways too. If the system got slow it was often due to disk backups to tape being run, and that left open the opportunity to watch for the tape operation finishing. With a little luck you could request the backup tape and the operator might be too lazy to check whether it was actually the backup application re-requesting the tape. Of course, the disk backups were unencrypted, and the first stuff on the tape was the system directories.

They never went to encrypted passwords. They couldn't because the account validation code ran in some small peripheral processors with 4K of memory. Not a lot of room for encryption code there.

Not a problem, though, because only trusted personnel could access the system.

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!