An attack on paypal
Sunder
sunder at sunder.net
Wed Jun 11 08:07:20 PDT 2003
The problem with these stop crackers and hackers by law is that it allows
software developers to get away with leaving huge gaping security holes
unfixed. Anecodatal evidence: The classic well known Robin Hood and Friar
Tuck "hack".
These days, the bug wouldn't get fixed and the guys reporting it would
wind up in jail because they "convinced" the OS authors to fix the
bug. IMHO, not the right way to go at all.
from http://ftp.arl.mil/ftp/unix-wizards/V16%23017
scroll down a bit more than half way down the page (also available from
most other GNU sources)
Back in the mid-1970s, several of the system support staff at
Motorola discovered a relatively simple way to crack system
security on the Xerox CP-V timesharing system. Through a simple
programming strategy, it was possible for a user program to trick
the system into running a portion of the program in `master mode'
(supervisor state), in which memory protection does not apply. The
program could then poke a large value into its `privilege level'
byte (normally write-protected) and could then proceed to bypass
all levels of security within the file-management system, patch the
system monitor, and do numerous other interesting things. In
short, the barn door was wide open.
Motorola quite properly reported this problem to Xerox via an
official `level 1 SIDR' (a bug report with an intended urgency of
`needs to be fixed yesterday'). Because the text of each SIDR was
entered into a database that could be viewed by quite a number of
people, Motorola followed the approved procedure: they simply
reported the problem as `Security SIDR', and attached all of the
necessary documentation, ways-to-reproduce, etc.
The CP-V people at Xerox sat on their thumbs; they either didn't
realize the severity of the problem, or didn't assign the necessary
operating-system-staff resources to develop and distribute an
official patch.
Months passed. The Motorola guys pestered their Xerox
field-support rep, to no avail. Finally they decided to take
direct action, to demonstrate to Xerox management just how easily
the system could be cracked and just how thoroughly the security
safeguards could be subverted.
They dug around in the operating-system listings and devised a
thoroughly devilish set of patches. These patches were then
incorporated into a pair of programs called `Robin Hood' and `Friar
Tuck'. Robin Hood and Friar Tuck were designed to run as `ghost
jobs' (daemons, in UNIX terminology); they would use the existing
loophole to subvert system security, install the necessary patches,
and then keep an eye on one another's statuses in order to keep the
system operator (in effect, the superuser) from aborting them.
One fine day, the system operator on the main CP-V software
development system in El Segundo was surprised by a number of
unusual phenomena. These included the following:
* Tape drives would rewind and dismount their tapes in the
middle of a job.
* Disk drives would seek back and forth so rapidly that they
would attempt to walk across the floor (see {walking drives}).
* The card-punch output device would occasionally start up of
itself and punch a {lace card}. These would usually jam in
the punch.
* The console would print snide and insulting messages from
Robin Hood to Friar Tuck, or vice versa.
* The Xerox card reader had two output stackers; it could be
instructed to stack into A, stack into B, or stack into A
(unless a card was unreadable, in which case the bad card was
placed into stacker B). One of the patches installed by the
ghosts added some code to the card-reader driver... after
reading a card, it would flip over to the opposite stacker.
As a result, card decks would divide themselves in half when
they were read, leaving the operator to recollate them
manually.
Naturally, the operator called in the operating-system developers.
They found the bandit ghost jobs running, and X'ed them... and were
once again surprised. When Robin Hood was X'ed, the following
sequence of events took place:
!X id1
id1: Friar Tuck... I am under attack! Pray save me!
id1: Off (aborted)
id2: Fear not, friend Robin! I shall rout the Sheriff
of Nottingham's men!
id1: Thank you, my good fellow!
Each ghost-job would detect the fact that the other had been
killed, and would start a new copy of the recently slain program
within a few milliseconds. The only way to kill both ghosts was to
kill them simultaneously (very difficult) or to deliberately crash
the system.
Finally, the system programmers did the latter --- only to find
that the bandits appeared once again when the system rebooted! It
turned out that these two programs had patched the boot-time OS
image (the kernel file, in UNIX terms) and had added themselves to
the list of programs that were to be started at boot time.
The Robin Hood and Friar Tuck ghosts were finally eradicated when
the system staff rebooted the system from a clean boot-tape and
reinstalled the monitor. Not long thereafter, Xerox released a
patch for this problem.
It is alleged that Xerox filed a complaint with Motorola's management
about the merry-prankster actions of the two employees in question.
It is not recorded that any serious disciplinary action was taken
against either of them.
----------------------Kaos-Keraunos-Kybernetos---------------------------
+ ^ + :25Kliters anthrax, 38K liters botulinum toxin, 500 tons of /|\
\|/ :sarin, mustard and VX gas, mobile bio-weapons labs, nukular /\|/\
<--*-->:weapons.. Reasons for war on Iraq - GWB 2003-01-28 speech. \/|\/
/|\ :Found to date: 0. Cost of war: $800,000,000,000 USD. \|/
+ v + : The look on Sadam's face - priceless!
--------_sunder_ at _sunder_._net_------- http://www.sunder.net ------------
On Tue, 10 Jun 2003, Bill Frantz wrote:
> At 5:12 PM -0700 6/8/03, Anne & Lynn Wheeler wrote:
> >somebody (else) commented (in the thread) that anybody that currently
> >(still) writes code resulting in buffer overflow exploit maybe should be
> >thrown in jail.
>
> A nice essay, partially on the need to include technological protections
> against human error, included the above paragraph.
>
> IMHO, the problem is that the C language is just too error prone to be used
> for most software. In "Thirty Years Later: Lessons from the Multics
> Security Evaluation", Paul A. Karger and Roger R. Schell
> <www.acsac.org/2002/papers/classic-multics.pdf> credit the use of PL/I for
> the lack of buffer overruns in Multics. However, in the Unix/Linux/PC/Mac
> world, a successor language has not yet appeared.
More information about the cypherpunks-legacy
mailing list