I worked in the HOSS (Home Office Software Support--we had other names,
but this was my favorite) -20 Monitor Group from mid-1978 through 1980.
This was the era of Release 3, 3A, and 4. I fixed monitor bugs, but I
also was solely responsible for maintaining EXEC. So we got an SPR in
from a customer saying that a negative offset given to the GETJI JSYS
(in Release 3) would crash the system. I realized right away that there
was a potential exploit.

The GETJI JSYS returns job information about a specific job, It's
primarily used by SYSTAT, or DBELL's SYSDPY prog, or perhaps by
accounting stuff. The arguments are:

AC1: job number, or -1 for current job, or 400000+TTY number
AC2: negative of the length of the block in which to store the
information in the left half, and the beginning address of the block in
the right half
AC3: word number (offset) of first entry desired from job information
table

So the argument in AC3 makes it sound like there is a "job information
table" lying around in core, and the JSYS just copies data from monitor
address space into user address space. But the information that the
user program can request doesn't lie in a single table in the monitor,
so the JSYS is actually implemented by doing an XCT into a table
(GETJIT) for each requested offset. Many of the entries are in fact
indexed moves from some monitor table, but some of them are CALLs to
routines that calculate the required data.

But here's the thing: the version 3 monitor checked to make sure that
the user-provided offset didn't go off the end of the GETJIT table, but
it didn't check for negative offsets! This means that the user program
could make the monitor execute any one instruction in the monitor
address space. So, what one instruction would be useful? You notice
that GETJI only uses the first three ACs? But the JSYS dispatch code
always copies four user ACs into the monitor address space. So you jump
into MDDT (you don't have to be privileged to do this, and it gives you
the monitor symbols), and then:

1/ -1
2/ -1,,PAT..
3/ 4-GETJIT
4/ SETOM CAPENB
GETJI$X

The (negative) offset calculated in AC3 points to the instruction in
AC4. That's the one that sets all the bits on in the word containing
the enabled capabilities. Your job now has WHEEL enabled.

This was fixed just in time for Release 3A. Rich Cower was editing the
source while kibitzers were looking on. His initial edit wasn't going
to work--I don't remember the error--but we kibitzers provided the
correct patch. I was watching, and maybe Greg Zima, and/or David Bell?

Scott
--
Scott Hemphill hemphill@alumni.caltech.edu
"This isn't flying. This is falling, with style." -- Buzz Lightyear

On Saturday, May 8, 2021 at 12:19:26 PM UTC-7, Scott Hemphill wrote:
> I worked in the HOSS (Home Office Software Support--we had other names,
> but this was my favorite) -20 Monitor Group from mid-1978 through 1980.
> This was the era of Release 3, 3A, and 4. I fixed monitor bugs, but I
> also was solely responsible for maintaining EXEC. So we got an SPR in
> from a customer saying that a negative offset given to the GETJI JSYS
> (in Release 3) would crash the system. I realized right away that there
> was a potential exploit.

I know it is TOPS-10 instead of TOPS-20, but this is reminding me of the
QUEUE/RUN: bug. It was a little before my time, but I believe I heard it
only second or third hand.

That someone submitted the bug report with PUBLISH checked,
assuming that they wouldn't actually do that, but they did.

gah4 <gah4@u.washington.edu> writes:

> On Saturday, May 8, 2021 at 12:19:26 PM UTC-7, Scott Hemphill wrote:
>> I worked in the HOSS (Home Office Software Support--we had other names,
>> but this was my favorite) -20 Monitor Group from mid-1978 through 1980.
>> This was the era of Release 3, 3A, and 4. I fixed monitor bugs, but I
>> also was solely responsible for maintaining EXEC. So we got an SPR in
>> from a customer saying that a negative offset given to the GETJI JSYS
>> (in Release 3) would crash the system. I realized right away that there
>> was a potential exploit.
>
> I know it is TOPS-10 instead of TOPS-20, but this is reminding me of the
> QUEUE/RUN: bug. It was a little before my time, but I believe I heard it
> only second or third hand.
>
> That someone submitted the bug report with PUBLISH checked,
> assuming that they wouldn't actually do that, but they did.

I suspect that there were several QUEUE bugs. It was nice that it had
JACCT set, so it could be coerced to do all sorts of things that weren't
intended. The name "QUEUE/RUN" is highly suggestive. I'm familiar with
another QUEUE bug, which we used at Caltech to alter the running monitor
to cause "SET TTY TIDY" (which I believe was only used by APL terminals,
which were non-existant at Caltech) to instead set the privilege word.
I believe Mike Gilbert wrote the exploit. I decrypted his encrypted
code to study the method, which I may detail if there is any interest.

Scott
--
Scott Hemphill hemphill@alumni.caltech.edu
"This isn't flying. This is falling, with style." -- Buzz Lightyear

Scott Hemphill <hemphill@hemphills.net> writes:

> I suspect that there were several QUEUE bugs. It was nice that it had
> JACCT set, so it could be coerced to do all sorts of things that weren't
> intended. The name "QUEUE/RUN" is highly suggestive. I'm familiar with
> another QUEUE bug, which we used at Caltech to alter the running monitor
> to cause "SET TTY TIDY" (which I believe was only used by APL terminals,
> which were non-existant at Caltech) to instead set the privilege word.
> I believe Mike Gilbert wrote the exploit. I decrypted his encrypted
> code to study the method, which I may detail if there is any interest.

Oh, yes, please do! We so seldom get tales from the trenches these days!

--
Rich Alderson news@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen

On Saturday, May 8, 2021 at 7:54:04 PM UTC-7, Scott Hemphill wrote:

(snip)

> I suspect that there were several QUEUE bugs. It was nice that it had
> JACCT set, so it could be coerced to do all sorts of things that weren't
> intended. The name "QUEUE/RUN" is highly suggestive. I'm familiar with
> another QUEUE bug, which we used at Caltech to alter the running monitor
> to cause "SET TTY TIDY" (which I believe was only used by APL terminals,
> which were non-existant at Caltech) to instead set the privilege word.
> I believe Mike Gilbert wrote the exploit. I decrypted his encrypted
> code to study the method, which I may detail if there is any interest.

There was a Diablo terminal, and someone might have had an APL
wheel for it. I thought I was remembering that someone did that, but
it is a long time by now. Otherwise, the LA36 allows for an APL ROM.

In any case, yes, post the stories!

gah4 <gah4@u.washington.edu> writes:

> On Saturday, May 8, 2021 at 7:54:04 PM UTC-7, Scott Hemphill wrote:

>> I suspect that there were several QUEUE bugs. It was nice that it had
>> JACCT set, so it could be coerced to do all sorts of things that weren't
>> intended. The name "QUEUE/RUN" is highly suggestive. I'm familiar with
>> another QUEUE bug, which we used at Caltech to alter the running monitor
>> to cause "SET TTY TIDY" (which I believe was only used by APL terminals,
>> which were non-existant at Caltech) to instead set the privilege word.
>> I believe Mike Gilbert wrote the exploit. I decrypted his encrypted
>> code to study the method, which I may detail if there is any interest.

> There was a Diablo terminal, and someone might have had an APL
> wheel for it. I thought I was remembering that someone did that, but
> it is a long time by now. Otherwise, the LA36 allows for an APL ROM.

I remember that option specifically for the LA120. Was it also available for
the LA36 (which means out DEC salescritter lied to us at UChicago)?

--
Rich Alderson news@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen

Rich Alderson <news@alderson.users.panix.com> writes:

> Scott Hemphill <hemphill@hemphills.net> writes:
>
>> I suspect that there were several QUEUE bugs. It was nice that it had
>> JACCT set, so it could be coerced to do all sorts of things that weren't
>> intended. The name "QUEUE/RUN" is highly suggestive. I'm familiar with
>> another QUEUE bug, which we used at Caltech to alter the running monitor
>> to cause "SET TTY TIDY" (which I believe was only used by APL terminals,
>> which were non-existant at Caltech) to instead set the privilege word.
>> I believe Mike Gilbert wrote the exploit. I decrypted his encrypted
>> code to study the method, which I may detail if there is any interest.
>
> Oh, yes, please do! We so seldom get tales from the trenches these days!

OK, here goes. I think this was somewhere around 1974, give or take a
year. I don't remember which version of TOPS-10 we were running, but we
had a KA-10, and student accounts at Caltech had been set to allow
unlimited computer time.

The holy grail was the JACCT bit. If you get could get that bit set,
you could do anything else you wanted to do. The monitor had rules for
assigning JACCT to a program: it had to come from [1,4] (SYS), and it's
name had to match an internal list of names. Note that no attempt was
made to also match the extension (the executable might have been an .EXE
or a .SAV file) but that means that if you managed to write an
executable to [1,4] named LOGIN.XYZ, then it would run with JACCT set.

Enter QUEUE. Disk space was always in high demand, and the monitor
strictly enforced a quota system. The LOGOUT quota was smaller than
what you had available while you were logged in. So if you had
generated a listing which put you over LOGOUT quota, it was convenient
to use QUEUE's /RENAME--I don't actually remember if this was the name
of the switch--which would rename the file to QUEUE's own system
directory. (I'm foggy about which specific directory this is,
too, [3,3]?) And then QUEUE would delete the file after it had printed.
But it might be that you changed your mind: the file you had printed
was important and you needed to get it back. So if you cancelled the
print request, QUEUE would move the file back to your own directory.

There's just one more piece to the puzzle. QUEUE had a nifty,
not-very-well-known feature. If you were debugging QUEUE, you needed to
be able to do so without interfering with the live system queue. So you
could use the logical name "QUE", as in

.ASSIGN DSK QUE

This meant that QUEUE would look for queue data files and text files in
your own directory, and not disturb the system queue. (I'm sure that
some of you reading this have leapt ahead to the conclusion... :-)

Anyway, so you create an executable named LOGIN.XYZ in your own
directory, along with a queue data file that says that you had performed
the command:

.QUEUE/RENAME LOGIN.XYZ[1,4]

Then you cancel the print request, and QUEUE very helpfully puts
LOGIN.XYZ "back" to where it came from, in [1,4]. I think eventually
QUEUE was fixed to clear its own JACCT bit when it was run in this
debugging mode.

Scott
--
Scott Hemphill hemphill@alumni.caltech.edu
"This isn't flying. This is falling, with style." -- Buzz Lightyear

On Thursday, May 13, 2021 at 1:55:23 PM UTC-7, Rich Alderson wrote:

(snip, I wrote)

> > There was a Diablo terminal, and someone might have had an APL
> > wheel for it. I thought I was remembering that someone did that, but
> > it is a long time by now. Otherwise, the LA36 allows for an APL ROM.

> I remember that option specifically for the LA120. Was it also available for
> the LA36 (which means out DEC salescritter lied to us at UChicago)?

I wrote that one after reading about it. It didn't say that anyone
actually produced the ROM, though, only that an option for it existed.

http://www.columbia.edu/cu/computinghistory/la36.html

Seems to say that it existed. I was looking for a picture of the
keyboard, which would show the switches, but I didn't find one.

On Thursday, May 13, 2021 at 8:58:56 PM UTC-7, Scott Hemphill wrote:

(snip)

> OK, here goes. I think this was somewhere around 1974, give or take a
> year. I don't remember which version of TOPS-10 we were running, but we
> had a KA-10, and student accounts at Caltech had been set to allow
> unlimited computer time.

OK, I didn't get there until 1976, so after all these, but I do remember
discussions about them.

I think I remember one from David Bell related to modifying the
monitor on the swap file, and then convincing it to be swapped in.
But all the good ones had been fixed by then.

> The holy grail was the JACCT bit. If you get could get that bit set,
> you could do anything else you wanted to do. The monitor had rules for
> assigning JACCT to a program: it had to come from [1,4] (SYS), and it's
> name had to match an internal list of names. Note that no attempt was
> made to also match the extension (the executable might have been an .EXE
> or a .SAV file) but that means that if you managed to write an
> executable to [1,4] named LOGIN.XYZ, then it would run with JACCT set.

I think I remember when EXE was new, and before that was
only SAV. SAV is a word for word copy of memory, but EXE is
compressed in some simple way. But I forget now, will it run
a file with any extension? Maybe if it is EXE, then the uncompress
is done, otherwise not?

> Enter QUEUE. Disk space was always in high demand, and the monitor
> strictly enforced a quota system. The LOGOUT quota was smaller than
> what you had available while you were logged in. So if you had
> generated a listing which put you over LOGOUT quota, it was convenient
> to use QUEUE's /RENAME--I don't actually remember if this was the name
> of the switch--which would rename the file to QUEUE's own system
> directory. (I'm foggy about which specific directory this is,
> too, [3,3]?) And then QUEUE would delete the file after it had printed.
> But it might be that you changed your mind: the file you had printed
> was important and you needed to get it back. So if you cancelled the
> print request, QUEUE would move the file back to your own directory.

Oh, I had forgotten about QUEUE/RENAME but it does sound familiar
now that you mention it.

Quota also reminds me that not so long after I got there, FILDAE
appeared, to allow some more interesting file protection systems.
There was one that allowed your programs, run by others, to access a
file, and also log the access. There was a game program that did this,
and some were not so interested in having the access logged.
So, a program was written to access this file (which would fail) in
a tight loop, and then get logged. Of course after not so long the
file exceeded the quota, but that wasn't checked until the user
actually logged in. So, then, the file had to be deleted before the
user could log out, and so likely without looking at it.

On Thursday, May 13, 2021 at 1:55:23 PM UTC-7, Rich Alderson wrote:

(snip)

> I remember that option specifically for the LA120. Was it also available for
> the LA36 (which means out DEC salescritter lied to us at UChicago)?

This one: http://www.mirrorservice.org/sites/www.bitsavers.org/www.computer.museum.uq.edu.au/pdf/EK-LA3635-OP-002%20LA35%20&%2036%20DECwriter%20II%20User's%20Manual.pdf

mentions the "alt char. set" switch.

I suspect that if someone at Caltech wanted this, they would write their own ROM,
but I don't remember anyone doing that.

gah4 <gah4@u.washington.edu> writes:

> I think I remember when EXE was new, and before that was only SAV. SAV is a
> word for word copy of memory, but EXE is compressed in some simple way. But
> I forget now, will it run a file with any extension? Maybe if it is EXE,
> then the uncompress is done, otherwise not?

..SAV files are "compressed", in that they consist of IOWDs giving a length and
start address for a run of nonzero words immediately following the IOWD; repeat
ad necessitatem. Before this mechanism was invented, the PDP-10 operating
systems used a .DMP file, which was an exact copy of memory contents with no
compression at all. (NB: WAITS, the SAIL OS, still uses .DMP files, having
diverged from the PDP-10 monitor at version 4S72.)

..EXE files are "compressed" in that *empty pages* are left out of the directory
(page 1 of the file), but all the contents of any page with at least 1 nonzero
word are put into the .EXE file.

Neither Tops-10 nor TOPS-20 cares about the extension beyond having a default
if one is not specified. On TOPS-20, that is of course .EXE. On Tops-10,
there is first a check for .EXE, and if one is not found then the system looks
for a .SAV.

--
Rich Alderson news@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen