
Xerox Alto zero-day: cracking disk password protection on a 45 year old system - jjwiseman
http://www.righto.com/2018/01/xerox-alto-zero-day-cracking-disk.html
======
mattnewport
The comment from the owner of the disk he cracked is pretty great:

Doug Wyatt January 4, 2018 at 10:38 PM

I'm flabbergasted. That's my Alto disk you broke into!

The APL stuff is surely related to some work I did with Leo Guibas, showing
why lazy evaluation would be a really good idea for implementing APL: see
Compilation and delayed evaluation in APL, published January 1978. (That paper
gives me an enviable Erdős number of 3, since Leo is a 2.) I'm sure it's not a
complete APL implementation, just a proof of concept. It happens that my very
first part-time job at PARC, in 1973, involved writing decision analysis
software in APL -- on a timesharing system!

Given the AATFDAFD hint, I'd guess the real password is ADDATADFAD. This
derives from a project I did with Jef Raskin at UCSD in 1974. (He mentioned it
in this interview.) The Data General Nova we were working with produced some
garbled message with ADDATADFAD where it should have said ADDITIONAL, and it
was a running joke ever after. Strange, the things that occupy some brain
cells for over 40 years.

Thanks for an amusing blast from the past.

\-- Doug Wyatt (Xerox PARC 1973-1994)

~~~
joshstrange
My brain didn't parse the "Xerox PARC" bit at the bottom and I just assumed
that birth/death years and I got really confused as to how he replied to
something posted in 2018.

------
Keyframe
Reminds me of a year or two ago when I had to boot my old SGI. Forgot the user
password on IRIX and thought that this is where I'll be clever (hacking
terminals, matrix music in the background, etc.). Turns out, IRIX had 8
character limit for user passwords. Thanks to the modern GPUs and a passwd
file restored from the system (on a recovery console), a few hours later I had
the password brute-forced. I'll get to be clever hax0r next time, I guess.

~~~
mmjaa
Turns out I need to do that with my old SGI. Got any tips?

~~~
Keyframe
Multiple ways to do it. All lead to you getting to the /etc/passwd file and
the hash inside for the root.

If you have IRIX installation CD then you can even set the new password, but
you probably don't have it? You can also put the disk into another SGI, also
not what everyone has. If guest account is enabled, login with guest (no
password) and just cat the /etc/passwd. If guest account is not enabled, you
can do the cat via sash, which is a bit more compicated, like this:
[https://web.archive.org/web/20151023042224/http://crackaddic...](https://web.archive.org/web/20151023042224/http://crackaddict.com/~nate/hackirix.html)

Once you have your hash, do it with John the Ripper (GPU version). Store the
password int a text file in format of root:hash and run john the ripper on it.
Encryption is, AFAIK, DES so use john --format=des passwd.txt if john doesn't
autodetect which encryption it is (I remember I had to set it manually). It
can take awhile, depending on the GPU, but not that long.

If you run into trouble, I can have a look. I think I wrote down somewhere
what to do, in case I need it again.

~~~
mmjaa
Thanks for this, looks to be not a problem at all! Well, now I've got one less
reason to keep the SGI boxes wrapped up, thanks!

------
dingaling
Very cool that he found a flaw in the algorithm

But this is really the antithesis of what a zero-day originally was, which was
a crack circulated on _or even before_ the release day of software[0]. The
Alto is 45 years old :)

Odd how words and phrases can change so much over a short period of time that
they invert their meaning.

[0] that's what it meant in the early / mid 1990s when I was peripherally
involved. Now it seems to mean 'zero days of notification to the vendor'.

~~~
tqkxzugoaupvwqr
How did people get access to unreleased software?

~~~
dogma1138
Back then games had to be gold to be sent to the CD/Disk manufacturer, then
you had to receive the copies and send them to be packed or directly to the
distributors if they handled the finale packaging. This meant that a golden
sample could circulate for as much as 6 months (and even longer) before the
game would go on sale. Also as all support was pretty much phone support which
also included some basic gameplay support you would have support staff often
at 3rd party call centers who would require access to the game before it goes
on sale (for large games at least, small companies tended to have support in
house).

Today with digital distribution even if it's for patches only you don't care
about the game going gold the DVD could contain a build that is utterly
irrelevant pretty much every new install from disk requires a day 1 patch that
can be often as large as downloading the whole from scratch (pretty much every
console owner knows this, PC games also get a day one patch but digital
distribution is a given for the PC market these days).

So zero-day for games at least isn't that important anymore, also DRM is
harder to crack these games some games take months to crack, some don't get
cracked at all, some rely on a weaken DRM version to be released (e.g. STEAM)
down the line that can be cracked more easily.

For DVDs/BR today this also often happens you have full BR rips often weeks
before the official release date, sometimes months just because they are
already ready just waiting on the right time to go on sale or for some online
distribution exclusivity deal to end.

~~~
gambiting
I work for a large games publisher and we still do that in fact! I've recently
been on a trip to our customer service centre, and the guys and girls there
have access to early builds of nearly all of our games so that when the game
comes out they can provide advice on day one. And yes, I too was surprised to
find out that they do provide actual gameplay advice if someone calls with a
question - every desk had several massive game guides for our games just in
case.

~~~
dogma1138
It doesn't surprises me that they still do that but with how easy it is to
track builds these days and the fact that games today are released broken with
"we'll fix it after launch" mentality it's not really that much of a source
anymore.

Early builds that might not function outside of the internal environment
aren't much of a deal the last leak I remember that got a scene release was
probably the Doom 3 Alpha.

------
mrpippy
My own adventure disabling PowerBook Password Security on an old Mac:

[https://bslabs.net/2016/01/30/disabling-powerbook-
password-s...](https://bslabs.net/2016/01/30/disabling-powerbook-password-
security/)

~~~
kens
Looks like a very similar form of protection and a similar way of defeating
it.

------
jjwiseman
Passwords like "HGFIHD" and "AAJMAKAY" look like initialisms. It might be fun
to try to decode them. (xxxAKAY on a Xerox PARC disk from the 70s/80s... could
it be?)

~~~
kens
I should mention that I didn't want to leak someone's actual password (even if
it's 40 years old), so I perturbed the passwords slightly. The real password
doesn't exactly end in AKAY, so it's not Alan Kay. (Apologies for throwing
cold water on your clever idea.)

~~~
pieguy
There's a decent chance the passwords you found aren't the actual passwords
either, considering how easy it is to generate collisions for the hash
function.

------
MikeBVaughn
I always find security measures on old-school systems interesting. They always
seem more geared towards keeping semi-honest mischief makers out than serious
security. Which makes sense, based on the context of the time I guess.

IIRC, the Xerox Pilot OS was purely cooperative multitasking with a single
shared address space.

------
dogma1138
They should totally file for a CVE for this.

~~~
kens
Someone needs to come up with a catchy name and a logo for this exploit.

~~~
tda
From the article:

> This attack is called XeroDay

~~~
kens
Yes, I updated the article based on the discussion here. But I still need a
logo :-)

~~~
msla
Ha! Great day in the morning! Thank you!

------
KindOne
When can we expect the security updates for the Alto?

------
raphman
German IT news site heise.de posted a nice tongue-in-cheek article about the
vulnerability: [https://www.heise.de/newsticker/meldung/XeroxDay-Zero-Day-
Sc...](https://www.heise.de/newsticker/meldung/XeroxDay-Zero-Day-
Schwachstelle-bei-Xerox-Alto-gefunden-1elf-3934443.html)

------
z3t4
When programmers and mathematicians use the word "trivially" it really means
"I'm smarter then you".

------
izacus
> Salting passwords also protects against password attacks using precomputed
> rainbow tables, but that wasn't a concern back then.

Hmm, if not to defend against rainbow tables... why were the passwords salted
back then?

~~~
teh_klev
From the article:

 _One problem with hashed passwords is if two users have the same hash, then
you know they have the same password. A solution (invented in Unix) is to hash
some random bytes (called salt) along with the password to yield the stored
hash. Since different users will have different salt, the hashes will be
different even if the passwords are the same. (Of course you need to store the
salt along with the hash in order to check passwords.) Like Unix, the Alto
used salted and hashed passwords._

------
colehasson
Something nice to discuss at least.

