James S. Lipscomb Home Page
        This page

0. Introduction
1. Story #1: APL login failed; you are now NASA.
2. Story #2: Undocumented )TPRIV system operator command.
3. Story #3: "Bs...! I am the operator. Who are you?"
4. Story #4: Peter Calingaert: How a real engineer thinks.
5. Story #5: Discovering the secret 2-i-beam and 3-i-beam operators
6. Story #6: A system error gave us unrequested full visibility into all private workspaces
7. Story #7: Trolling a high school jerk, and wrap-up
   

Introduction

These are stories of the IBM APL\360 programming language in 1967-1968 when it was finishing development, not yet a product.  These are personal e-mails that I sent separately to Dr. Fred Brooks.  As personal e-mails these stories at times directly address Dr. Brooks and assume familiarity with the UNC department of Computer Science.

Many stories infrequently over time, at the end of each story a teaser for the next, the primary purpose being to always have a future for Fred to look forward to as things were bad for him.  Fred responded positively by e-mail to these APL stories, and those replies give me peace to believe that I may have done OK.

I am one of Dr. Brooks' doctoral students, link at top left of page.

Story #1: APL login failed; you are now NASA.

In 1967 IBM set up an APL terminal, based on an IBM Selectric typewriter, in my high school (Belmont Hill School, Belmont, MA) and others.  A modem connected to a timeshared IBM 360/50 at IBM Research.  IBM was testing the market for teaching programming in secondary schools, like schools using PCs this century.  50 years ago IBM Research was in a way 30 years ahead.  But high school students dialing in to a central server?  What could go wrong?  How about everything?  Seven stories below, not all about things gone wrong, but most.

Here is the first thing to go wrong.  No me in this story - another student at my high school.  I heard about it the next day.

Hint #1: We dialed Yorktown on the modem, waited for the tone, pushed the connect button, and then typed ")<UserNumber>".  Later, ")SAVE", then )OFF" when done, but just pushing the modem disconnect button also logged off just after the line dropped, with an autosave to CONTINUE.  In my experience, the word "just" usually precedes a hidden, enormous problem.

Hint #2: Moreover, since the keyboard had no way to communicate a halt to a long running APL program, we could just push the modem disconnect button, dropping the line and within a few seconds the connect button, restoring the line, which could be done since it was only partly dropped.  Specifically, the receiving modem on the big wall of modems on the far side of the IBM 360/50 room would see the phone line go dead, then live, and respond by keeping the login session alive on the port while an interrupt was sent to any running program.  All this was fundamental to voice calls too; one could hang up the phone in one room and pick up in another if quick, and one could flash the line by pounding the handset cradle switch.

Hint #3: A student at my high school dialed the Yorktown number and pushed the modem connect button, but then mystery.  Typing ")<UserNumber>" gave an error message that the login command was invalid, and then the terminal spaced 6 spaces to the right.  He tried ")<UserNumber>" again, same error, and again 6 spaces to the right.  Could it really be?  "1+1" followed by hitting the Return key gave "2".  So yes, he really was logged in without having done so.

")FNS" showed not the student's functions but others unknown.  A thinking adult might have logged off - but - high school.  "NASA" appeared frequently in the function comments as onlookers became a crowd.  They printed more functions attempting discern what NASA was doing.

Technical cause, obvious by now: Perhaps the NASA employee or contractor was about to reconnect while signaling an interrupt, or perhaps a telephone line glitch dropped him the second before, or less likely he had pushed disconnect intending a log off.  But no matter the cause of NASA's disconnect, by thin chance during the seconds that the IBM 360/50 computer's modem was waiting on the dropped line our high school student dialing in connected to the NASA open port, following which the modem/computer treated the disconnect-connect as a user interrupt request and kept the NASA session live.

Next, the NASA person presumably failed to reconnect.  Then, as I heard later from our faculty advisor, NASA dialed back in but login denied as already logged in.  Someone was using his account!  He quickly called the IBM 360/50 operator who issued a ")BOUNCE" to the session's port number, which froze our terminal, and presumably saved a CONTINUE workspace with NASA's unsaved changes, so it's all good.

Short days later IBM made a fix on their side.  NASA handed IBM some cause for motivation is the nice way of saying what I heard from our faculty advisor, poor guy.  He never knew what we were up to and then had to clean up.

Postscript: IBM wanted to find out what it would be like to have high school students from around the country dialing into shared systems, and we helped IBM on that, but they never said thank you.

Story #2: Undocumented )TPRIV system operator command.

The APL\360 undocumented )TPRIV system operator command expressed a little of the principle of least privilege before Jerome Saltzer's publication.

I heard about the )TPRIV command, undocumented and unknown in any written APL history I know, when in 1967 or 1968 my high school APL pals and I drove from Boston to Yorktown Heights to see the IBM 360/50 that we dialed into, as IBM tried out pre-release APL in some high schools to test the educational market.  No teachers with us of course.  Either Adin Falkoff or Richard Lathwell had agreed to meet us, I do not recall, so "our host".  From the local hotel we arrived early morning.  The receptionist kindly let us in to his office, so that we high school students could read the papers on his desk I guess, the desk of mister not-pleased-when-he-arrived.

After a cool down our host spoke about APL beyond our student manual.  I was struck by what he said after describing the )PRIV[1] system operator command with which the operator could give operator privileges to a specified port for the duration of its session.

Our host told of an unofficial )TPRIV system operator command.  It was programmed at the request of Larry Breed.  TPRIV stood for Tiny PRIVilege, as it gave just some operator privileges to his port session.  Other APL developers we were told did not understand why just those privileges were wanted by Breed.  By my thinking this sub-setting improved safety from accident and had propriety.

In 1974, the principle of least privilege[2] (PoLP) was published by Jerome Saltzer[3], covering process, user, and program privilege.  Saltzer perfected PoLP reasoning that traces back two years before to Needham[4].  But 4-5 years before even Needham )TPRIV preceded PoLP in the limited context of user privilege.  However, )TPRIV will not be remembered by history, and needn't be I suppose, but for it I admire Larry Breed.

References

[1] APL manual showing the )PRIV command on appendix pages A-2 - A-3 but next to it no )TPRIV command, of course.
https://apps.dtic.mil/dtic/tr/fulltext/u2/729941.pdf

[2] The principle of least privilege: Giving a user account or process only those privileges which are essential to perform its intended function.
https://en.wikipedia.org/wiki/Principle_of_least_privilege

[3] Saltzer, Jerome H. (1974). "Protection and the control of information sharing in multics". Communications of the ACM. 17 (7): 388–402.

[4] Needham, R. M. (1972). "Protection systems and protection implementations". Proceedings of the AFIPS '72 Fall Joint Computer Conference, December 5-7, 1972, Part I. pp. 571–578.

Story #3: "Bs...! I am the operator. Who are you?"

APL story #2 left off in 1967 or 1968 as my high school APL pals and I had driven from Boston to Yorktown Heights to see the IBM 360/50, where we stand now.

Our host walked our little group to the far wall with towering shelves of telephone modems.  Not much for crowds, I hung back.  Another student called me over to the Selectric typewriter by the CPU.  This was the APL operator's console where atop first fan-folded page was the secret[1] operator's login number )314159.  I wrote it down unobtrusively. (I feel that I remember that there was a password too, "G", but that memory feels uncertain).

On the drive back to Boston that student began bragging and was asked for the login number.  "Don't worry.", he said, "I have it right here.", as he pulled out the first page of the operator's log ripped right off of the console.  Boos all around.  Way to go.  Way to keep a low profile.

So, did IBM Research, now knowing that they had been compromised perform a security audit?  Let's see.

One afternoon we tried logging in with )314159, and as expected this login was in use.

But one morning before the start of APL's two-shift operation a student tried )314159 repeatedly, getting no response, until he did.  He was logged in.  He was the operator.  Evidently IBM Research morning procedure was thus:

(1) Start up the APL system connected to live telephone modems;

(2) allow time for everything to be perfectly just so;

(3) carefully tap in )314159, the operator's login number on, but not restricted to, the physical console.

Our student beat the clock.  Either there was no password[2] on )314149, or maybe was the letter "G".  Memory fades with time, but either way -- 1960's cyber security.

The student, having no plan, idly poked around his operator workspace.  In came an )OPR message from an ordinary terminal port number, "Who are you?"  The student's )MSG reply to that port, "I am the operator.", which, to be fair, was sort of true.  Response, "Bs...! I am the operator. Who are you?"  Had there been more to the conversation I think I should have heard.  For the student things to see and do, with users from around the country logging in, the stakes rising.

One may hope to imagine the machine operator's escalating vexation before his last resort, a shutdown, possibly hard, taking everybody with it, and perhaps it saved to )CONTINUE workspaces.

IBM's dream of learning what would happen if high school students dialed in to a shared mainframe continued to come true.

Nobody at my school was interested in trying )314159 again.  No agenda.  We just did stuff to relieve the tedium.  Well, tedium but for Peter Calingaert's wonderful thin blue binder; story below.


References and Note

[1] The console operator's number was unknown to ordinary users.  APL user manuals from 1971 and 1968 below do not show the console operator's login hardwired to )314159, nor, as far as I can see, how the installer would set the login number.  Communication to the console operator was with the )OPR command (second URL below), which does not need a port number or login number parameter, just something like: )OPR HELLO WORLD.
https://apps.dtic.mil/dtic/tr/fulltext/u2/729941.pdf
http://www.softwarepreservation.org/projects/apl/Books/APL360ReferenceManual

[2] Optional password set by )OFF:MYPASSWORD was implemented about that time by 1968, see [1] above.

Story #4: Peter Calingaert: How a real engineer thinks.

APL story #3 left off in high school where we had logged in as the APL system operator )314159 while, "We just did stuff to relieve the tedium."

Tedium, as in having to evaluate "high school education units" from IBM via. SRA (Science Research Associates), most at a junior high school level really.  Not where anyone wants to go back to.

Tedium but for one, one wonderful thin blue binder, a unit on group theory, a new world concisely and beautifully explained.  It was illustrated through APL examples and exercises at a confident, smooth cantor that would not buck off the student.  "Who wrote this?", I wondered and examined the author's name: Peter Calingaert.  I did not suppose that I should ever meet him.

Years passed.

Peter Calingaert invited me to his office to tell me the Ph.D. requirements added since my courses.

I should know:
  * B-trees;
  * Group theory.

Before I could speak he instructed me to return in a week (or maybe two) with an answer, so I left.

A week or two later found me back in Peter Calingaert's office.

PC asked about B-trees, and I replied that although not part of the curriculum, when I took computing theory class from Gyula Mago he covered both B-trees and balanced B-trees (perhaps more data structures than computing theory, but with Mago B-trees will not be omitted).

Then PC asked about group theory.

My reply, "Well, you taught me group theory."

PC's expression did not change, of course, but behind his glasses his eyes did something.  An average person might have replied, "No".  Sometimes I tell this story of PC's reply to teach the accuracy with which a real scientist or engineer thinks and speaks, not in assumption-laden overreach, but to precise boundaries.  He spoke slowly.

"I don't remember teaching you group theory."

My reply, "It has been a long time. I was in high school."

I placed on his desk the thin blue binder he had written so many years previous.  Peter Calingaert looked at the cover for awhile.  Peter Calingaert turned every page, pausing more than a moment over each.  Time passed.  My hand received the binder from Peter Calingaert for a second time, this time in person.

I do not remember that further words were spoken before I left.

Story #5: Discovering the secret 2-i-beam and 3-i-beam operators

APL story #4 left off in 1967 or 1968 with me in high school evaluating "educational units" from SRA.  Tedium but one.

Contributing to the tedium was that the APL terminal had been running a few months, and we had learned the operators.  What about something new?  A student became curious about the overstruck character operators, like lamp, "comment" for newbies, (intersection small circle) and reversal (circle and residue).  Might there be other overstruck character operators not in the users guide?  A natural question, soon to go progressively wrong.

He began typing:
operator, backspace, operator.
"Nonce Error" I think, or similar response, indicating and invalid operator.
Another operator, backspace, operator.
"Nonce Error".

Time passed.

Base, backspace, residue, which looks like the cross-section of an i-beam.
"Valence Error" I think, or similar response indicating invalid operands.
Ah ha!  If all that is wrong now are the operands, then the operator is valid!

The i-beam overstruck character operator had been found.

Now to figure out the operands, and thank you so to the APL team for language consistency that allowed for this 2-step discovery process.  Had the i-beam operator been specially programmed to give a Nonce Error unless the operands were just right our explorer would have cruised right by.  APL, consistent to a fault.

Experimentation found operands that did not produce errors:
* The number 2 on the left and one integer on the right.
* The number 3 on the left and two integers on the right.

More trials by the growing crowd, at some point including me, deduced that the 2 read the right-operand-specified word from the workspace.  The 3 set the near-right-operand word location to the far-right-operand value.  Peek and Poke.

Knowing that, I wrote an APL program using 2-i-beam to print on the Selectric typewriter terminal the entire contents of the loaded workspace.  Each printed line had left-to-right the starting address of the next few words and then their values as integers, hexadecimals, and characters.  I skipped lines that repeated, saving some pages.

The structure of the symbol table at the high-order end of the workspace caught my interest.  Variable names with too many characters to fit into one word were split with a pointer to a remote second word with the remaining characters.

We found our login number in a word near the low-order end the workspace, then to wonder: What if we loaded public library workspaces?  Yes, each had a login number in the same location blabbing the workstation's creator or owner.  I think I recall that we found login numbers in metadata of user-written functions too, not sure.

The other students worked up a list of login numbers.  Not me.  Out of my bounds.  Toolsmith from the start I just built the tool, so I was innocent, sort of.  Speaking of which, we never tried logging in on these login numbers perchance some might lack passwords, because just not interested, so we were all good there, sort of.

On our trip to visit IBM Research to see the IBM 360/50 computer that ran APL (stories #2 and #3, continuing as follows) one student abruptly presented the list: "Who's logins are these?"  Our IBM host's astonished reply, "Where did you get those!?", and, as he stared, spoke the names of APL luminaries, disappointingly not paring names to login numbers out loud.  We told him all about how we did it of course.

2-i-beam and 3-i-beam later became privileged operators[1], so perhaps now the system operator must issue a )PRIV to one's port, which IBM Research may have originally had in plan.  I like to think so:

(1) They had something dangerous (2-and-3-i-beam) needed for troubleshooting;

(2) They already had a way to shield other dangerous things from ordinary users, the )PRIV and )TPRIV commands;

(3) APL was still in development, so one must presume that they planned to leisurely harmonize (1) with (2) before product release with security by obscurity good enough till then, not.

APL cybersecurity was therefore hardly first priority but I may hope taken seriously, except for modem interrupt accidental login (story #1), physical security of the operator's console ")314159" (story #3), workspace contents in plaintext (this story), and, well, next story.

We high school students never knew when i-beam security began.  We were done playing with 2-i-beam and never did anything with 3-i-beam because, as with not trying logins, just not interested.

Well, next story: A system error gave us unrequested full visibility into all private workspaces system wide, one a time with some patience.

[1] APL i-beam function.  "There were some privileged i-beams which performs (sic) functions analogous to peek and poke. .... " – Lobachevsky Jun 21, 2017 at 8:21:
https://stackoverflow.com/questions/44656779/apl-i-beam-function#comment76325487_44658496

Story #6: A system error gave us unrequested full visibility into all private workspaces

 
Of my tales of unpolished pre-release APL\360, this is the one that I am most sure you have not heard from the APL team, who might want this blunder most forgotten, and therefore should be most remembered.

APL story #5 left off in 1967 or 1968 with students at my high school using 2-i-beam to find user login numbers.

I do not recall being involved in this next tale directly, but OK indirectly, but otherwise not, except for receiving consequences of course.  Backing up to the beginning, here is what the participants at my high school told me:

A student in spring 1968 was indexing into a vector that I heard was named FIVELONG.  Perhaps it had 5 elements FIVELONG[1] to FIVELONG[5].  During routine development the index went out of bounds, perhaps FIVELONG[6].  Instead of an INDEX ERROR, he saw an unfamiliar integer.  Larger indices returned other unfamiliar integers.  For indices so big that the vector would have to have been larger than his APL workspace, he still got integers.

He met with students who had studied the printed output of my 2-i-beam program that dumped every word in a workspace (previous story).  They recognized his integers as the contents of his APL workspace starting part way through for small indices of FIVELONG.

By design when APL detected an internal error, to preserve workspace integrity the user got a CLEAR WS message, and the workspace in memory was wiped out.  Then the user had to reload from the most recent manual )SAVE.  Quite the shock.  I learned to save frequently.  For FIVELONG one scenario consistent with events is that during an undetected system error the array size value may have been damaged, perhaps overwritten by an enormous value.  After that, since there was evidently no periodic sanity check (nowadays assertion check) of array size, the bad size would persist with saves.  Also no real-time check for one workspace invading another's address space.  Runtime efficiency.

FIVELONG indices past the end of our workspace were reading words in the workspace adjacent in memory.  Repeated looks saw a succession of workspaces as they, or we, swapped in. Knowing the location to look from the output of my 2-i-beam scanner, the students collected more login numbers from these drive-by workspaces of users so incautious as to be logged in while my colleagues were.

The students were not interested in converting my workspace dump program from 2-i-beam to FIVELONG to extend to adjacent workspaces the reach of comprehensively printing user data and programs or to try to look further to two workspaces adjacent or to reach for potential untold gifts between beyond and segmentation fault or even to assign values to distant elements of FIVELONG to see if that changed adjacent workspaces or beyond.  No, just kids that something landed on, and they did a little with it.

IBM found out or was told.

Over the summer of 1968 while my high school was offline IBM Research figured out how to smooth this wrinkle by clearing all of my high school's saved workspaces.  Then in the fall, everybody had to start everything all over.  OK for some, but I was off to college, having left behind a program that calculated and printed GPA ranked lists by grade level of all students in the high school.  I had written it at the school administration's request and ran it my senior year repeatedly as grades came in, for administrators to track student standing.  For data entry they gave me the lock combination to the room with the master binder of grades.  Substantial APL code plus data, all wiped.

I found out when in Fall 1968 I stopped by high school from college, the students I had trained to continue said that they were worried that had they typed in the GPA ranking program from the seven pages of printouts I had trained them from, plus the hundreds of names from the binder, then something might not have worked, so they had done nothing.

Story #7: Trolling a high school jerk, and wrap-up

APL story #6 left off in 1968 with my high school colleagues spying into adjacent memory guided by my 2-i-beam workspace dump program.

In high school one evening I found a student starting an all-night computationally-intensive knights tour APL program testing probabilities of success of his brute force algorithm.  I admonished him that our high school had agreed to IBM not to be a computation hog, not to take advantage of everything being provided free, but the word kept was not in his vocabulary.  He asked me to continue his program when I was done.  I said yes.

When I finished with me I made a lightweight impromptu impostor, "occasionally succeeding", but really just rapidly printing similar output, complete with his chessboards with beginning and ending random knight positions.  Random, but taking care that the beginning and ending squares were not the same.  Would have been a giveaway.

In my defense it was late at night, and I was absolutely sure that no one was looking.

Then the door swung open.  My dad, homeward from working late, was wondering what little Jimmy was up to.  Over the cacophonous clatter of the Selectric typeball he ended our exchange with, "I hope I never get you mad. You'll get back at me -- and I won't even know!"

Minutes later, simulated hours later, for the topper, during one of my program's regular output pauses, coded for this moment, I scrolled down to blank paper below, interrupted my program, launched my classmate's (so yes, I ran his program), scrolled back up to just below my simulated output, interrupted his program, which printed the interrupt occurring in his code, and tore off from the paper below to hide the phooey on you switcheroo.

The next day, as I feigned interest, he told me that his program did not run quite all night, but that somebody stopped it after a few hours.  Customer satisfaction is one of two possible final quality checks.

Bearing in mind this story plus my high school 2-i-beam snooping I suppose that when on my application to graduate school at the UNC Chapel Hill Computer Science department I included of high school APL a spare list of highlights, I did not think to completeness or to detail.



James Lipscomb