Text File

RISKS-LIST: RISKS-FORUM Digest Thursday 14 April 1988 Volume 6 : Issue 61

FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Contents: Obscure C contest gaffe (Matthew P Wiener) Risks of Lap-Tops in Exams (PGN) Re: Macintosh Power switch (Greeny) Crimes of the Depressed (Vin McLellan) More evidence for an old risk -- Enigma (Dave Mankins) Norwegian embezzlement (Eirik Kim Pedersen via David Edwards) Race, identification, and muddly thinking (David Thomasson) "Race" as ID (Will Martin) Re: File "RISKS-6.FEYNMAN" -- and a ghost story (Jerry Leichter)

The RISKS Forum is moderated. Contributions should be relevant, sound, in good taste, objective, coherent, concise, nonrepetitious. Diversity is welcome. Contributions to RISKS@CSL.SRI.COM, Requests to RISKS-Request@CSL.SRI.COM. For Vol i issue j, ftp kl.sri.com, cd stripe:<risks>, get risks-i.j ... . Volume summaries in (i, max j) = (1,46),(2,57),(3,92),(4,97),(5,85).

----------------------------------------------------------------------

Date: Sun, 20 Mar 88 20:16:47 pst From: weemba%garnet.Berkeley.EDU@violet.berkeley.edu (Matthew P Wiener) Subject: Obscure C contest gaffe

The obscure C contest, whose past winners were recently distributed on comp.sources.unix, had a curious gaffe. The programs were named after the winners, and the Makefiles produced similarly named binaries. The user's mindset is to puzzle with the programs to figure out what they're doing. The documentation is deliberately cryptic, and all unusual behavior is considered par for the course.

So guess what happens when Larry Wall is a winner?

I tried out "wall" as indicated, and got all my input echoed back in a broadcast message, and error messages about various ttys being unwriteable. Hmm, thinks I, what's Larry up to this time? I try some more input, and get this same stupid echo and error messages. Hmm, thinks I, maybe running it in Emacs isn't a good idea. Etc.

So I ended up annoying a dozen people for a minute before I noticed the discrepancy between the documentation's references to "lwall" and the Makefile's references to "wall". Oops, thinks I. "wall" is the standard UNIX facility for writing a message to all users.

For an amusing variant of this, consider the possible reactions among some users were his name Larry Rogue. ("Gosh, 1000 bytes and it plays a full game of rogue! How does he doooo that?")

And while I'm at it, let me predict that within a year or two, a fiendishly obscure virus is going to be among the winners.

ucbvax!garnet!weemba Matthew P Wiener/Brahms Gang/Berkeley CA 94720

------------------------------

From: neumann@csl.sri.com Date: Thu, 14 Apr 88 08:51:24 -0800 Subject: Risks of Lap-Tops in Exams

Harvard Business School faculty member Mark Albion has confirmed that students can take their finals on blue books or they can use lap-top computers. There are potential problems with taking an exam using a lap-top computer. Some of the exams last up to four hours, presenting the risk that a computer's batteries will die during the test. And Albion said that on at least one occasion, a computer glitch erased a student's whole exam. [From Bob Greene's column in the San Francisco Chronicle, 13 April 1988]

A usually reliable source suspects that the students get blank disks from the professor, so they can't be tempted to bring in a disk with lot of information on it! But what about storing your course notes? What about modems linking students to one another for interactive collusions? What about Trojan horsing the competition? What about planting a Trojan horse on the diskette so that when the professor tries to load it, HIS memory is contaminated -- e.g., with a program to change the grade database? The fertile minds of students can undoubtably come up with other exciting scenarios.

------------------------------

Date: Wed 13 Apr 1988 21:22 CDT From: GREENY <MISS026%ECNCDC.BITNET@CORNELLC.CCS.CORNELL.EDU> Subject: Re: Macintosh Power switch

>...Ive heard that the macintosh power switch really doesnt turn off the power

This is correct but only with respect to the MAC ii and the Lisa.... on both of these machines, when one turns off the power, the machine transfers control to a SHUTDOWN MANAGER which then takes care of powering down the hard drives, and what not....to turn on the machine one simply presses the power switch again. *OR* in the case of the Mac II one can simply select SHUTDOWN from the Special menu and the machine will shutoff on its own -- to reactivate the machine, one hits the RESET key on the keyboard.

When shutdown is selected on an SE or a Plus or whatnot, the SHUTDOWN MANAGER simply displays a message saying (basically) "its ok to shut off your mac now..." and does nothing else....you have to take care of powering down your hard drive, etc...

hope this helps....for more info on this see Inside Macintosh vol. V (I think....) available from Addison-Wesley Greeny

Bitnet:MISS026@ECNCDC Disclaimer: If it's really me on this account, then I might be responsible, but if it's not, then who can you blame?

------------------------------

Date: Thu 14 Apr 88 04:43:46-EDT From: "Vin McLellan" <SIDNEY.G.VIN%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU> Subject: Crimes of the Depressed

The April 18th issue of Business Week had an interesting aside in a major story on "Stress: The Test Americans Are Failing," a general round up on the impact of layoffs, mergers, and technological changes, particularly in middle management. With automation already undermining job security, particularly among middle managers, post-Crash budget cuts have led to to widespread layoffs among white collar professionals. All of this excacerbates the long-term trend of middle managers coming to the conclusion that their corporate "parent" is quite willing to betray them, to sacrifice them as a budgetary footnote, and thus doesn't deserve loyalty... perhaps not even honesty.

The Wall Street culture displays new and growing problems in alcohol use, fear, anxiety, and poor morale among employees and executives. Reports the Business Week research team: "Often employees who lose their jobs react with furious anger. 'In the extreme, they shoot somebody,' says (grad school prof Robert Dewar.) Acts of sabotage, particularly of records and computer data,are common. Human resource executives at half a dozen big companies privately admit to destructive outbursts by laid-off managers."

Donn Parker of SRI used to talk a lot about corporations never realizing how much trust they had invested in employees with EDP access, authority, and responsiblity. It sounds like some, just because they've acted with the callous capitalism we expect of MBA-trained managers, are learning the hard way. These corporate rebellions seem to be seldom reported -- except when a broker shoots his former boss, as happened last week here in Boston -- but there is an sad saga of RISKS unfolding out there. Where does it impact security budgets? Perhaps in demand for post-password access systems, tokens and biometrics. What executive (what employee for that matter) can't learn a few other employees' passwords in any given week?

Vin Mclellan, The Privacy Guild, Boston, MA (617) 426-2487

------------------------------

Date: Thu, 14 Apr 88 10:31:04 EST From: Dave Mankins <dm@diamond.bbn.com> Subject: More evidence for an old risk -- Enigma

Alfred Hodges biography of Alan Turing, ``Alan Turing: The Enigma'', relates the story of deciphering the Enigma encryption system. The key to the decipherment was making a clever guess as to the plaintext (successful guesses were known as `cribs') for a single word in a message, and then matching the message against that word in hopes of finding the proper setting for the rotors of the Enigma, which would allow you to decrypt the whole message.

While this might seem like a hopeless task, military messages have a stereotyped form and a limited vocabulary (words like ``attack'' and ``General'' keep cropping up), making the task much easier. Hodges says (p. 184):

Nor was it a trivial matter to guess the probable word, nor to match it against the cipher-text. A good cipher clerk, indeed, could make these operations impossible. The right way to use the Enigma, like any ciphering machine, was to guard against the probable word attack by such obvious devices as prefacing the message with a variable amount of random nonsense, inserting X's in long words, using a `burying procedure' for stereotyped or repetitious parts of the transmission, and generally making the system as unpredictable, as un-mechanical, as was possible without the loss of comprehensibility to the legitimate receiver. If this were done thoroughly the accurate `cribs' required for the Bombe [the cryptanalytic device designed principally by Turing for attacking the Enigma code] could never be found. But perhaps it was too easy for the Enigma user to imagine that the clever machine would take care of itself, and there were often regularities for the British cryptanalysts to exploit.

Cracking the Enigma naval code made it possible for convoys to avoid U-boats, and made it possible for the British Navy to locate and destroy U-boats. The sudden change in the tonnage sunk by the U-boat offensive once the naval Enigma was cracked led to an investigation by the Germans. Says Hodges (p. 201):

In fact, the operation _had_ betrayed Alan's success, for the German authorities decided that the positions of the supply vessels had somehow been disclosed, and set up an investigation. Their experts, however, ruled out the possibility that the Enigma cipher had been broken. Instead, they pinned the blame upon the British secret service, which enjoyed a high reputation in German ruling circles. It was a diagnosis remote from the truth. [Hodges elsewhere says the British military, told the Enigma decryptions came from the Secret Service, ignored them for the most part, since the Secret Service had a reputation for being wrong 80% of the time.] They had assigned an _a priori_ probability of zero to Enigma decryption, and no weight of evidence sufficed to increase it...

The Bombe method, which was central to the system, hung upon a single thread. If, to be on the safe side, the Germans had gone over to a double encipherment of _every_ message, then there would have been no more cribs, and all would have been lost. At any time, the mere suspicion that something had gone wrong might stimulate such a change...

It's an old moral: your security may be foolproof, but the people trying to subvert it might not be fools.

------------------------------

Date: Mon, 21 Mar 88 19:42:06 EMT From: NMIEP%NOBERGEN.BITNET@CUNYVM.CUNY.EDU Subject: Norwegian embezzlement Resent-From: David L. Edwards <DLE@csl.sri.com> from Security@Rutgers

Maybe the latest incident on computer embezzlement? Two employees of the largest Norwegian clearing house, Bankenes Betalingsentral BBS, are charged with attempted fraud.

The scheme was apparently in accordance to the old dream of redirecting transactions to other accounts. The particular day of the attempt, there were to be a large number of social security benefit transfers. The possible outcome is said to be app. ! 250 million. One of the two had an operator type job, with access to tapes. However, the whole thing was set up in such a way that it was easilly detected by regular security checks.

This hopefully shows that security does work, and that the notion that no cases have ever been spotted due to security routines, is not true.

Eirik Kim Pedersen

------------------------------

Date: Thu, 14 Apr 88 15:49:40 EDT From: David Thomasson <ST401405%BROWNVM.BITNET@MITVMA.MIT.EDU> Subject: Race, identification, and muddly thinking

Les Earnest writes in reply to my earlier note:

>Thomasson apparently believes that everyone belongs to some race >and that that race is determinable. He probably also believes >that all dogs belong to some breed. I would like to accompany >him to a city pound somewhere and listen to him identify all the >mutts there.

"Apparently believes...probably believes" -- more Straw Men. In fact, I believe that virtually everyone can be put into some racial category that is very useful for purposes of identification, even though such categories are not biologically precise. As for the rest of the above, Earnest's argument has gone to the dogs.

>The things that Mr. Thomasson lists [hair color, eye color] at >the end are useful identification properties. "Race" is not, >unless you are a racist.

Granted the biological imprecision of racial categories, one must consider their usefulness in identifying people. In three years with a police department, I never knew of a case in which this imprecision worked against the purpose of identification. I knew of hundredes of cases in which racial classification helped greatly. This is a matter of plain fact, and to suggest that one is a racist for pointing it out is absurd. By the way, the term "racist" is only as clear as one's definition of "race" -- something that Earnest says is signally unclear. Once again, confusion runs rife in RISKS.

>Color of skin and color of hair _are_ useful for identification >and may reasonably be included on a drivers license.

I agree. In my experience, "race" has been roughly equivalent to "color of skin" in police work. So, while it's true that "race" is biologically imprecise (even incorrect), those who use race for identification purposes aren't concerned about biology -- no more so than when they use "build" -- stocky, thin, average, etc. Should we brand the latter as "buildists"?

------------------------------

Date: Thu, 14 Apr 88 15:41:07 CST From: Will Martin -- AMXAL-RI <wmartin@ALMSA-1.ARPA> Subject: "Race" as ID

Inspired by the follow-on discussion of "race" as a valid datum for driver's licesnses and suchlike documents: Obviously, since "race" is such an undefinable term, and an individual's "race" cannot be accurately determined by merely looking at them, the ID factor should be changed to "skin color".

How would one know what to put in a "skin color" block on a form? Well, you would have a chart, with various colors on it, like a paint-chip match-up chart or the kind of things medical technicians use to match the colors in a test tube when they are mixing reagents with specimens. Each chart-entry color block would have a number, and you'd put that number on the form.

But, you ask, where on my skin would I match this chart? Well, that IS a problem -- a fair-skinned person's skin color can vary from pale white in the winter to fiery red or reasonably tan in the summer or after exposure to UV light, and this is likely to be apparent on parts of the body exposed to the sun -- face, hands, arms, maybe even legs or torso. Darker-skinned people also have variations in their skin color, though the range may be less dramatic.

Therefore, the "official" area of comparison will have to be some part of the body normally NOT exposed to sunlight. Where will that be? Well, I guess, for reasons of decency, the only part allowable will be the buttocks. Normally covered, yet readily exposable for comparison purposes. Therefore, after this procedure is implemented, the normal citizen's response on being approached by a policeman or other official who will need to identify them will be to turn their backs, pull down their pants, and bend over, presenting the skin on their buttocks for an official comparison....

:-) Adds new dimension to the old "Assume the position!" command, eh? :-) Will Martin

------------------------------

Date: Thu, 14 Apr 88 17:16 EST From: "Jerry Leichter (LEICHTER-JERRY@CS.YALE.EDU)" <LEICHTER@Venus.YCC.Yale.Edu> Subject: Re: File "RISKS-6.FEYNMAN" and a ghost story

[Sorry about the FTP difficulty. Jerry and I had a dialogue on an FTP problem that seems to permit get stripe:<risks>risks-6.feynman ... TO WORK, BUT NOT cd stripe:<risks> FOLLOWED BY get risks-6.feynman ... Beats me. Also, some systems are CASE SENSITIVE, and add further confusion. PGN]

Reminds me of a great "ghost story" from the days when we had a pair of 20's here. A bad block in just the wrong spot on the disk - in the directory structures, I guess - could lead to a crash whenever it got touched. Such a bad block appeared in a bulletin board; every time a message got posted to the bulletin board, the system would crash.

The kicker: It was the CRASHES bulletin board, where information about system crashes was posted. -- Jerry

------------------------------

End of RISKS-FORUM Digest ************************