[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: paper tapes: B-5500 CANDE Extended ALGOL program



> To: deltoids@mcws.net
> From: Aron Insinga <ainsinga@infomation.com>
> Subject: paper tapes: B-5500 CANDE Extended ALGOL program
> Mime-Version: 1.0
> 
> Anyway, here's the most interesting thing I found:
> a B-5500 CANDE Extended ALGOL program.
> I did *not* write it or use it.
> Would anyone like to either 'fess up or provide an analysis?
> (Gary, maybe you can use it as an example of an early '70s
> security problem? :-)
> Before anyone complains about the formatting,
> remember that it was probably done on a 110 baud TTY.
> 
> - Aron
> 
> 1010 BEGIN COMMENT A PROGRAM TO SNATCH USERCODES AND PASSWORDS;
> 1020 FILE TTY REMOTE (1,9); FORMAT OUT ID (/"PASSWORD SNATCHER"/);
> 1030 ALPHA NEWUSER; BOOLEAN SAVETIME; LABEL EXIT;
...
> 1300 "USERCODES"/"   AND"/"PASSWORDS"/"  REVISED 6/30/71"//64("-")/),

...

God, never thought to see that again.  It's a program to crack file
security on the B5500 and print out all of the users and their passwords.
It's a little fuzzy, but the work was done by myself, Jodie with some
help from a UofD student who can identify himself if he chooses.  8-)

Basically at some point in 1970/1971, Delta students had gotten access
to the University's B5500 and found it fascinating.  We'd gotten some
MCP and XALGOL manuals via the Burroughs sales office on Concord Pike
(Clark?) and scrounged various interesting listing from the trash and/or
dumpster at Smith Hall (Wes?).  A key to this was a listing of a program
called "night/maint", which was some kind of daily reporting program.
From that we found the names of some special accounts, and I think were
able to get a printout of the OS (MCP) & CANDE from a system acccount
that had readable source-code files.  Dr. Dave may also have gotten
some MCP/Compiler listings for us, I'm not sure which came from where.

The basic principle was that the Burroughs disk/file-system wasn't
all that secure and that programs writting in XALGOL could do things
that were nominally "priveliged".  The beginning of the disk was the
system part with normal user files above a boundary called the "fence".

The disk directory was a file located below the fence - Non-priveliged
users/programs weren't supposed by be able access below the the fence,
and would get a message "invalid PRL" trying to read/write there,
however looking at the MCP code to find out what an "invalid PRL" was,
we found that the check would allow reading/writing all but the
one record on each track that it actually checked for.  PRL turned
out to be "programmed release" - in Burroughs terms a write was just
a trasnsfer to buffer, when full a "release" actually committed the I/O.

Anyway, once we could read/write most of the disk, the object became
to find the entry for a desired file in the disk directory and change
to owner to be yourself - TIME(-1), at which point you could open the
file.  The the user/password file turned out to be clear text, hidden
behind about 30 blocks of noise.  Voila, space past the noise, print
out the users and their passwords, then change the owner back.

My recollection was that this was done over the summer before students
got involved with Delta, by kids involved in Dr. Dave's Thursday evening
computer seminar.  The intial work was done in the computer center after
studying the night/maint listing, in the process Jodie mis-coded a write
to the wrong file and scribbled his name all over the disk directory!
The final work with the passwords took place in Dupont hall and I think
we printed several copies on yellow teletype paper.  I used to have one,
but I suspect my mother has trashed the box it was in.

We weren't "caught" doing this, however I think the "Invalid PRL"
messages from the initial playing showed up one the console and alerted
the computer center staff.  Since some of us were also involved in the
"learn Fortran" course at PMC in Chester, we then took the program up
there, where we had access to another B5500 that was a commerical
timesharing system operated by Philco/Ford Aerospace.  Apparently B5500
admin's were a pretty close circle and they'd been alerted to something
and when we used a UofD guest account on their system to print out their
passwords it got back to the UofD and we got nabbed at the UofD and
banned from the B5500 (acounts were courtesy of Dr. Dave) and threatened
with legal action, though nothing came of it.

I guess there were some lessons that that maybe had some bearing on
things once I got involved in sysadmin stuff at Delta, but I think it
was mostly just added interest in OS issues.  Some good passwords were
46EDEL for UofD system accounts (the staff/academic services office
when 360 was the university computer center), and many of the Philco/Ford
passwords (commerical accounts!) were still "lock" and "key".

There were other Burroghs hacks that I wasn't invovled in.  One was based
on the fact that the Burroughs system was an early example of "virtual
memory" and arrays could be mapped to files.  CANDE, the timesharing
monitor was a special program that ran under the OS and multi-tasked the
timesharing users, it kept info about the users in arrays/hidden files -
files starting with digits wouldn't show up in directory listings, but
you could open them by name.  Someone found out that by over-writing the
"user ID" in one of those files and crashing CANDE or the system, when
it recovered you'd be restarted as a priveliged user.

Later in the B6700 days, with an XALGOL program, you could set the
privelige bit for your own process or corrupt the file system by creating
a file a/b/c/.../x/y/z, implying 25 directory levels.  This stuff all got
passed around and people always felt compelled to try some themselves.
On of the things that the XALGOL compiler would let you do was to get a
various intrinsics (like SYS$ functions) that weren't defined for the
normal compiler.  After they blocked access to the XALGOL compiler, I know
we scoped out the idea of creating "backup tapes" were we could include
object file fudged to allow access to the special intrinsics, but I
guess the actual faux backup tape doing was left to later generations.

For it's day, the B5500 MCP was quite sophisticated, but not too secure -
it was basically a batch system, with timesharing grafted on and better
work on timesharing/security was being done elsewhere DEC's PDP-6 & PDP-8
vitual machines and the Multics project.

						George