On 9/16/2015 6:36 PM, Jon Elson wrote:
On 09/16/2015 01:29 PM, Paul Koning wrote:
I never had any incentive to look for holes in CDC operating systems,
but I still remember a simple hole I found in OS/360, about a month
after I first wrote a program for that OS. It allowed anyone to run
supervisor mode code with a couple dozen lines of assembler source
code. I found it on OS/PCP 19.6, but I noticed in graduate school
that it still worked on the university's 370 running OS/MVS 21.7.
(The magic? Use the OS service to give a symbolic name to a location
in your code, with a well chosen name, then give that name as the
name of the "start I/O appendage" in an EXCP style I/O request.) paul
Yup, the classic breakin was you set up an exception handler with SPIE
(specify program interrupt exit, I think) and then do a divide by
zero. This gives the handler the PSW of the problem program. You turn
the P bit of the PSW off and return. The stock OS would actually
ALLOW you to DO this, and just return to the user program now in
supervisor state! It was a VERY simple fix, you just don't allow any
exception handler to change the state of the P bit. But, MANY systems
did not do that check.
The SPIE fix was fixed in MVT 21 which we ran at UMR in my memory before
I left in 75. I know of at least three of us who wrote up exploits,
which stored the PSW to show supervisor state, and let it go at that.
That was on the UMR 360 / 50
The really fun "trojan" was a console logger that was around which
watched the MVS VS1 console screen for changes and rendered a scrolling
rendition of the log on a terminal. The computer operators at our
remote site didn't have that working with their remote Hasp workstation,
only had the entries pertinent to locally submitted jobs. This was on a
370 / 158 at University of Missouri, Columbia.
Also there was a password logger which watched all the TSO logins, and
logged the password and account for every user. That exploit still
existed when I left. The IBM code had an 8 byte double word in which it
stored a "scrambled" version of the password for use by jobs that needed
authentication (way before RACF or such) and could verify w/o
re-prompting a lot for the password. However when you entered your
password the first 8 characters, which were all that were used for
authentication were stored for a few cycles in that same word.
So to get the password, you watched the login state, and as long as the
process was logged off, the entry was zero. You would grab the values
and store the first value that appeared after it went non zero and about
99% of the time it was the clear text.
Fun times.
So MANY other weaknesses could easily be caused by accident. Like,
the file that contained valid account numbers was often not
protected. Anybody could just print out that file.
Jon
