The RISKS Digest
Volume 8 Issue 21

Sunday, 5th February 1989

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…

Contents

`User friendliness' tradeoffs can lead to total nonsecurity
Eric S. Raymond
Capturing a password
Phil Karn
Collisions in DES
Jean-Jac. Quisquater
Re: Crashing a PDP-11/40 [static electricity]
Jeffrey Mogul
ATM error
Douglas Jones
Anecdotes: ping-pong robot; CCC breaks net
Konrad Neuwirth
Request for information: Health Hazards of Office Laser Printers
Keith Dancey
Re: Structured Programming
Michael J. Chinni
Info on RISKS (comp.risks)

`User friendliness' tradeoffs can lead to total nonsecurity

Eric S. Raymond <eric@snark.uu.net>
1 Feb 89 20:48:42 GMT
What would you say about a UNIX box vendor that included a section entitled
`How to crack into root privileges on this machine' in their manuals? Not
much that's printable? Read on...

Yesterday morning my evaluation T5100 arrived from the good people at Toshiba
America, their loan to my HyperNews project (it will be the field remote-test
machine). I had great playing with this sleek little machine, assembling
hardware and installing software and generally admiring the Neatness Of It
All. Finally, a true portable capable enough to run a real operating system!

Installation was easy; the documentation took pains to make the system and
its setup procedures accessible to people who hadn't necessarily seen a UNIX
before. Someone had obviously worked overtime on the `user friendliness'
factor. I was impressed.

Between that and my own level of who-needs-the-manuals UNIX expertise it wasn't
till this morning that I cracked the "T/PIX System Administrator's Guide",
flipped through the Table of Contents and got a rude shock. There, staring
up at me, was printed "Procedure 1.5: Forgotten Root Password Recovery"

"Ai yi yi!" I thought, and flipped hurriedly to the section. Sure 'nuf,
it was a blow-by-blow description of how to do the boot-mount-and-edit trick
every guru on a UNIX system with bootable floppies knows how to set up but
seldom talks about — and to make the trick easy the Toshiba people had
helpfully supplied a microfloppy already built to do it with!

I wonder how much the Toshiba people thought about what they're doing. In their
worthy concern with making it easier for novice administrators to recover from
dumb errors without calling in an expert, they've broadcast a procedure that
allows anyone who can get a copy of the tool disk and remember a few simple
instructions to crack *any* T5100 they can get physical access to. And since
these machines are portables it is unlikely they'll get much site protection.

If I needed one, this would have made a perfect and pointed reminder of the
opposition between convenience and security, and the risks of designing for
user-friendliness at all costs. As desktop and portable UNIX systems designed
for serious and potentially sensitive work proliferate, I wonder how many
vendors will make this kind of choice; how many others will leave that hole
open though undocumented because "that's the way it's *always* been done"; and
how many innocent users will become cracking victims for these reasons.

      Eric S. Raymond                     (the mad mastermind of TMN-Netnews)
      Email: eric@snark.uu.net                       CompuServe: [72037,2306]
      Post: 22 S. Warren Avenue, Malvern, PA 19355      Phone: (215)-296-5718


Capturing a password (Re: RISKS-8.18)

Phil Karn <karn@ka9q.bellcore.com>
Thu, 2 Feb 89 00:22:09 EST
I once passed a REVERSE "Turing test". Back at Bell Labs in the early 1980s,
we used a large PBX for terminal networking.  Everyone had two phones on
their desk: one for voice and another (with 212 modem) for data.

Late one night, my office-mate's data phone rang a few times and stopped.
Thinking that someone had put the wrong number into their UUCP database, I set
up a terminal and waited for the retry to see if I could spoof the UUCP login
procedure and figure out the system responsible. Sure enough, a minute later
the second call came. I typed "login: ". To my surprise, a human responded by
typing her login name! "Hoookaaaay, let's try this," I muttered as I typed
"Password: " The person obediently typed her password! After a few seconds I
revealed who I was.  Click. No more annoying calls.
                                                              Phil


Collisions in DES

Jean-Jac. Quisquater) < quisquat@prlb2.UUCP <jjq@prlb2.UUCP>
5 Feb 89 11:00:28 GMT
To avoid any incorrect rumor, here is the complete announcement:

We (Jean-Paul Delescaille and Jean-Jacques Quisquater) were able to find 3
collisions in DES using a network of workstations during some weeks.

Definition of a collision: given a message M and an cryptographic algorithm f
with 2 parameters M and K (the key), a collision is a pair (K1, K2) such that

  f (M, K1) = f (M, K2),

that is, for a fixed message M and using a cryptographic algorithm f, the key
K1 and the key K2 give the SAME encrypted message.

Jean-Jacques devised a new probabilistic distributed asynchronous algorithm for
finding collisions without any sorting and with a small storage (a la Pollard).
We used a fast implementation of DES in C (by Jean-Paul: about 2000 *
(encryption + change of key) / second/machine)

We used the idle time of a network of 20 SUN-3's and 10 microVAXes 
(a la Lenstra and Manasse). Total: about 100 Mips during one month.

 37
2  encryptions performed (about 20 potential collisions) only in software!

The message M is 0404040404040404 (hexadecimal form) for the 3 collisions.

Collision 1: found Fri Jan 13 23:15 GMT (birthday of Jean-Jacques!
Yes, it is another birthday attack (Hi! Don Coppersmith)).

   cipher = F02D67223CEAF91C
   K1     = 4A5AA8D0BA30585A
   K2     = suspense!

Collision 2: found Fri Jan 20 19:13 GMT

   cipher = E20332821871EB8F
   K1, K2 = suspense!

Collision 3; found Fri Feb  3 03:22 GMT

   suspense!

Conclusion: Friday is a good day for finding collisions :-)

Well, there is a problem because there is no proof we effectively found such
collisions.

Question 1: Find a protocol for proving or for convincing you that we know K2
for collision 1 (zero-knowledge protocols are useful in this context).

Question 2: Find a protocol for proving or convincing that we know
K1 and K2 for collision 2 (idem).

Question 3: Find a protocol for proving or convincing that we know
3 different collisions (idem).


Useful information: the nice paper by Brassard, Chaum and Crepeau,
``Minimum disclosure proofs of knowledge'', 1987.

The complete information will be given at EUROCRYPT '89, Houthalen, 
Belgium, with the restriction that the submitted abstract is
accepted :-) The paper will be sent in April if you want it.

Thanks are due to Paul Branquart, Frans Heymans, Michel Lacroix, Vincent
Marlair, Marc Vauclair, the members of PRLB for permission and active help in
the effective implementation of the distributed algorithm on their workstations.

Warning: There is no implication about the security of DES used for encryption.
Indeed these experiments only prove that DES is a good random mapping (a
necessary property for any cryptographic algorithm). However the use of DES for
protecting the integrity of files is not very easy and needs very careful
studies.

Jean-Jacques Quisquater                    (Program chairman of EUROCRYPT '89)


Re: Crashing a PDP-11/40 [static electricity]

Jeffrey Mogul <mogul@decwrl.dec.com>
31 Jan 1989 1101-PST (Tuesday)
In RISKS 8.18, Jeff Makey writes about a PDP-11/40 that could be
crashed by walking across the room and kicking the console terminal,
thereby transferring a static charge to the console and the CPU.

I can confirm this feature of PDP-11/40s.  When I was in high school,
around 15 years ago, we had a PDP-11/40 (it's hard to believe that this
machine, with 56Kbytes of RAM and a few Mbytes of disk, could serve 8
simultaneous users).  I used to use the console occasionally, and found
that when I was wearing a sweater knitted from acrylic wool I had to be
careful not to let my arms rub on the case of the terminal.

We also had to go around the terminal room every few hours and spray
some sort of anti-static mist over the ASR33s.  I don't know if this
really worked, or if we just had a placebo effect.

If a PC were this sensitive to static, typewriters would still be big sellers.
It was extremely unpleasant to have to reboot every few hours on a dry winter's
day.  I still remember the sound made when I typed at a full-duplex ASR33 just
after the computer stopped echoing.
                                               -Jeff Mogul


ATM error

Douglas Jones <jones@herky.cs.uiowa.edu>
Wed, 1 Feb 89 16:18:39 CST
I just had a run-in with an ATM that makes me wonder about the quality of
programs (or is it programmers) used in the banking industry.

I went through the normal sequence, putting in my card, entering my PIN,
and pressing the "FAST CASH, $25" button.

It came back with the error message:  "THE AMOUNT YOU REQUESTED IS NOT
DIVISIBLE BY $5.00."  Then it gave me the option of entering a new
amount or aborting the transaction.

I tried $50.00, $40.00, and $5.00, and got the same result each time.  I'd
bet the machine was out of money, but if this is the case, the error message
suggests incredibly ineptly written code.

Of course, a hardware error could add or drop a bit in a key storage location
to make it think I'd asked for an odd amount, but such errors are rare
enough that I wouldn't bet on it.

Oh yes, the ATM was relatively new, made by NCR, and at a very heavily used
location.
                        Douglas W. Jones, University of Iowa.


Anecdotes: ping-pong robot; CCC breaks net

Konrad Neuwirth <A4422DAE@AWIUNI11.BITNET>
Sun, 05 Feb 89 18:34:19 MEZ
There is a nice(? find out for yourself) story about a Ping-Pong robot built at
MIT. Now the guys who had built that machine were very proud of the device and
wanted to show it to Mr. Minsky.  First they explained to him how they built
it, and made it recognize round objects with a certain amount of reflecting
light, for what they had installed some lights, too. Now they turned on the
lights, and started the software. One fact is important: mr. minsky is bald.
They started the software, and he stand in front of the robot, directly in the
lights..

****T H A N G*****, and the robot hit the "ping pong ball".

The other one is about a German group of hackers (the CCC, Chaos Computer
Club) breaking into a net. First about the net: it is called BTX
(BildSchirmText = ScreenText) and is, well, sort of a mailbox system,
but really more one way, as the lines are 1200/75 baud. Now there are
some banks taking part in the system, too. And there are pages, which yu
have to pay for if you want to read them. Due to a security-leak, the CCC
found out the password of one of the big banks in the system. They set
up a page which you have to pay for, and made a computer (with the bank's
account) dial up that page again and again and again......
They had the software running for a whole night, and in the morning, had
130.000 DM on their account.

But that's not all: they had warned the german Bundespost, who runs the
BTX system, about the bug they had found in the system. The authities said
"we have a bug-free system". And imagine, they also said that directly
after the CCC had gone public with the hack! they said that the CCC must
have had spies in the bank.

-konrad

p.s.: the bug was reproduceable. About the pong story: you can find it
somewhere in Steven Levy's HACKERS book.

Konrad Neuwirth, Fernkorngasse 44/2/4, A-1100 Wien AUSTRIA
Phone : +43 / 222 /604 15 30


Request for information: Health Hazards of Office Laser Printers

<kgd@informatics.rutherford.ac.uk>
Thu, 2 Feb 89 12:55:09 GMT
This is a request for information, or pointers to relevant sources of
information, on the hazards of Laser Printers.   I am more interested
in the chemical health hazards than, say, heat and noise which are
easy to appreciate.  In particular, what is the wisdom of sharing
office space without active ventilation with one or more Laser Printers?

I have a reference to arsenic compounds present on the drum, and a
widely held "view" that the toner is carcinogenic, but nothing
substantial and no authoritative source for the hazards these may pose.

I am also aware that erosion printers deposit light metals or other
unpleasant material in the atmosphere, but then I am not familiar
with this type of printer ever being used inside a permanently
occupied office.

Perhaps the relatively recent development of desk-top laser printers pose
a new hazard in those countries which do not habitually air-condition
their offices?

Keith Dancey,                               UUCP:   ..!mcvax!ukc!rlinf!kgd
Rutherford Appleton Laboratory,
Chilton, Didcot, Oxon  OX11 0QX             
                                        JANET:       K.DANCEY@uk.ac.rl.inf
Tel: (0235) 21900   ext 6756


Re: Structured Programming

"Michael J. Chinni, SMCAR-CCS-E" <mchinni@ARDEC.ARPA>
Thu, 2 Feb 89 10:47:32 EST
One "war story" I can relate is the following.  As an R&D computer facility we
serve as what you might call a "job shop" for engineers at our site. One time
an engineer came to us with a several thousand line program that he wanted us
to put on our system (i.e. get it working).  After accepting the job we found
to our horror the the code was TOTALLY unstructured.  It had NO comments; had
no conection what-so-ever between variable names and their use; and frequently
used system-specific code without mentioning that it was system-specific OR
what the code did; and the entire program was replete with gotos.

It took us about 2 man-months of work to get that monstrosity working.
However, if the code had been "structured" it would have taken us no more that
2 man-weeks.

The moral of the story is that had the code been structured we would have saved
1.5 man-months of work. And since we charge by time spent on a job, it would
have saved much money.

Michael J. Chinni, US Army Armament Research, Development, and Engineering 
Center, Picatinny Arsenal, New Jersey  

Please report problems with the web pages to the maintainer

x
Top