Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!know!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!lll-winken!uunet!mcsun!ukc!reading!minster!forsyth
From: forsyth@minster.york.ac.uk
Newsgroups: comp.unix.wizards
Subject: Re:  Checkpoint/Restart
Message-ID: <651489391.12189@minster.york.ac.uk>
Date: 24 Aug 90 09:16:31 GMT
Organization: Department of Computer Science, University of York, England
Lines: 27

Checkpoint/restart facilities in older operating systems were
once suggested to me as a good place to start
if you wanted to break into the system
(only as a demonstration, of course).  They were indeed.
Some systems saved a lot of system state,
yet were careless about checking it when restarting the job.
The data might well be saved in a file (on disc or tape)
that could then be modified in helpful ways.

For instance, one operating system saved the equivalent
of the UNIX u area, and also the equivalent of the inode for each
file.  It was not too much work to patch the base/extent pointers for a file
to point to the part of the disc where the user names and passwords
were kept (unencrypted).  A program would open a file
and checkpoint itself; on restart, it would read the file
and print it out in an attractive form.

The information saved by some systems was so low-level
it is hard to see how it could be checked.
I suppose the information might have been encrypted instead.

How many of systems that provided checkpoints
also gave security problems (if only initially)?
For instance, Lars Poulsen mentions that the UNIVAC EXEC system would
crash if the checkpoint file was `ill-structured'.
That suggests a lack of checking, which could be turned
to a villain's advantage.