Welcome to Volume 7! There have been 472 RISKS issues in the past 35 months. However, the number of contributions has been expanding dramatically of late as RISKS goes further out into the internet. (I note the big increase in messages from Australia!) (Countering that somewhat is the appearance of specialized groups, such as VIRUS-L.) To prevent RISKS readers from being totally inundated with the deluge, the proportion of messages emerging from my pipeline has been dwindling somewhat of late — as I sharpen my interpretation of the above guidelines. (Apologies to those of you who did not get any response at all — if you feel that your contribution was of PARTICULARLY BURNING INTEREST and that I might have missed it or not gotten it, please resubmit with a note — or think about refining it.) By the way, RISKS production will have to slow down a little during June, because of my schedule; so, be patient. Maybe with school recesses, discussion will slow down also. But the world never rests, and we can assume that there will be a few stellar cases of interest to RISKS. PGN
As one of the culprits who found this feature in Erik Fair's *.test message bouncer program, I'd like to mention a couple of ways to protect yourself (by the way, yes, it was an accident). What is a *.test message bouncer? If a user posts a message to "misc.test" or "alt.test" this bouncer program will mail the posted message back to the user. This is often used by sites to determine if their news feeds are making it out to the backbone (or, as in our case, to gather statistics to determine the best news propigation path). The symptom is that this one particular (the most popular) message bouncer will send mail to every address on every From: line in the message. This includes From: lines in the message body. Now that this feature has been widely publicised in the "news.admin" newsgroup, the best step is to warn everyone before some net-terrorist decides to cause real havoc. The message that caused the recent problems on the net had two features which, when combined, resulted in a mess. (1) the message had 109 From: lines in the body (2) it was a large ~62k message What happened? Every site that had the message bouncer installed sent out 109 62k mail messages. Also, many of these mail messages failed because of a bad address. This lead to them to be bounced back to the originating site (the one with the bouncer) to end up in the inbox of the Postmaster. Needless to say, many sites had their spool partitions and usr partitions filled to capacity within minutes of receiving that message. Also, there was a significant jump in uucp and Internet traffic (painfully expensive to long distance uucp sites). How can you protect yourself? If you're not running Erik's program, you are likely to be safe (check anyway to see if it has these same "features"). Modify your message bouncer to: (a) Send a reply to one "Reply-To:" or "From:" address (the first From: address in the header seems logical to me). (b) Don't send the entire message back, just the original header and a note saying "we got your message". Paul firstname.lastname@example.org ...!pyramid!comdesign!pst
I just returned from attending the IFIP/SEC-88 conference on the Gold Coast of Australia. It's a meeting that addresses protection of information systems in the broadest context. SEC-88 is the 5th in a series of roughly annual meetings, and is sponsored by TC-11, a technical committee of IFIP — approximately the international analog of AFIPS. In addition to doing a keynote talk on "Perspectives on Trusted Systems", one of the fun things for me was to participate in an evening public forum on social aspects of computer technology. In addition to myself, there were on the platform an Australian computer expert (who organized the conference) and two Australian politicians — one a regional official of the Labor Party and the other, a present conservative Member of Parliament. I had been cautioned that the subject would almost certainly center around the Australian ID card exclusively, and it did. By the by, the story that was told to me, and verified by something that I read down there, was that the only reason that the legislation did not go into effect earlier was that it contained a technical flaw; namely, in the haste of getting it ready, a switch-on date was inadvertently omitted from the law. This fact came from a prominent member of the Australian Computer Society. The argument that developed during the evening — and it apparently is the nub of the Labor Party position — is that Australia has too much tax fraud [sic] and that the ID card is the answer. It seemed to me that the proper word was "tax evasion." It seems that the Laborites feel that too much income is escaping the tax authority, and that it should be collected to make more revenue available for social and other programs. Obviously what Australia wants to do is corral the taxpayer, as the IRS does with its Taxpayer ID; Australia wants to be able to do the analog of tracking supplementary money flows as reported on the various form 1099s and similar documents here. Other than the tax-related matter, no other argument was given for the institution of a universal ID card and number. There was an amusing comment from the floor. A member of the Swedish delegation pointed out that Sweden has had a population register for decades, if not centuries, and Sweden has substantial tax fraud still. My concluding comment was to point out to the Labor person that it seemed to me that he had a solution in search of a problem. In the best system-analysis tradition, I observed that the tax problem could very well be real, but that it looked as though it had been assumed that a universal ID was *THE* answer. There clearly are other answers and the government ought to do a more careful analysis of alternatives. Something in the spirit of the US/IRS arrangement would meet their tax needs, without subjecting the Australian population to all the RISKS associated with a genuine universal personal ID. The whole thing was covered by a TV crew whose interviewer chaired the session. I was told that a lot of air coverage was given to the occasion the following night, but I did not see it. There seem to other RISKS in the Southern Hemisphere also; there has to be one somewhere in the following story. En route, I read an Auckland, NZ newspaper which reported a cable car incident. The Auckland cars are not in the spirit of the San Francisco ones but evidently more like an inclined railway running up and down a steep street in a more or less straight line. Seems as though a cable car had crashed into a bumper at the end of the line with some injuries, but the RISK content is in the final words of the article: "The City Council had just spend [NZ]$90,000 reprogramming the onboard computer." Willis H. Ware, RAND Corporation, Santa Monica, CA
Organization: The MITRE Corp., Washington, D.C. From the _Washington_Post_, 31 May 1988, page D-1 (without permission, of course) comes the following article (credited to _Newsday_): TEXAS TO HOLD A LANDMARK TRIAL ON COMPUTER TAMPERING BY 'VIRUS' Texas prosecutors are preparing to go to trial in one of the first criminal cases in the nation involving spohisticated tampering with a computer's programming. Donald Gene Burleson, a 39-year-year-old Fort Worth programmer, has pleaded innocent to charges of computer sabotage and burglary involving the USPA and IRA, Co., a Fort Worth-based insurance and securities concern. He is free on $3,000 bail pending a July 11 trial. Burleson has lost a civil action in connection with the alleged 1985 computer tampering, and has been ordered to pay USPA about $12,000 in damages and interest. Prosecutors charge that after being fired in September 1985, Burleson deleted records of thousands of sales commissions owed USPA employees from the company's computer system, and also introduced into the system a hidden program that would erase such data in the future. Davis McCown, head of the Tarrant County district attorney's economic crimes division, said in an interview last week that the program "had the ability to move through the [computer system], to change its name and to relocate." [discussion of Trojan horses and viruses (virii?)] [...] Burleson denied the charges and [said] that the company is blaming him for someone else's actions. "They really have no proof," [his lawyer] said. "Anybody could have done the deletions" from the commission payment records.
Date: 24 May 88 01:49:55 GMT >From uw-beaver!cornell!rochester!bbn!uwmcsd1!ig!agate!violet.berkeley.edu!willis Mon May 23 18:49:55 1988 From: email@example.com (Willis Johnson) Subject: How did this program burn out two monitors? Organization: University of California, Berkeley I recently compiled a program that is supposed to do graphics on a Hercules graphics adapter. I've used a similar routine before, and I would have sworn there was nothing wrong with the software. Maybe the files got corrupted. When I ran the .exe file, my monitor made a high-pitched whine, then the power light went off, and a crackling noise came out of the back until I pulled the power cord. Curious about whether this was a coincidence, I took the program to work and tried it on an extra monitor I had there. The second monitor burned out too! I thought it was impossible to damage my monitor and adapter with software. Does anybody have any ideas what caused this? I'll post the .exe file and source (in C) to any brave or curious souls who request them. The hardware: 1st time: homebrew PC clone with generic Hercules clone card Quimax DM-15 amber monitor. 2nd time: Leading Edge Model D, "turbo" with built in Hercules compatible adapter, Quimax DM-14 amber monitor (an earlier version of the DM-15). Neither video adapter was damaged. Both monitors are DEAD. Willis Johnson willis@violet.BERKELEY.EDU (415) 548 - 3023 >From uw-beaver!cornell!rochester!bbn!uwmcsd1!ig!agate!ucbvax!decwrl!labrea!glacier!jbn Mon May 23 22:29:15 1988 Path: microsoft!uw-beaver!cornell!rochester!bbn!uwmcsd1!ig!agate!ucbvax!decwrl!labrea!glacier!jbn From: jbn@glacier.STANFORD.EDU (John B. Nagle) Newsgroups: comp.sys.ibm.pc,comp.arch,comp.graphics Subject: Re: How did this program burn out two monitors? Date: 24 May 88 05:29:15 GMT Reply-To: jbn@glacier.UUCP (John B. Nagle) Organization: Stanford University This is an old known bug. You can burn out the IBM monochrome monitor by stopping the horizontal sweep while keeping everything else running, and the Hercules card gives you enough control to do this under software control. The video chip lets you select the horizontal and vertical sweep rates independently, and zero rates are possible. However, the horizontal sweep is used as the oscillator for a switching power supply, as is typical in TV circuits, and with the sweep rate at 0, DC flows through a coil with high inductance but low resistance, producing an excessive current that burns out the coil. Part of the problem is that the IBM monochrome monitor is a design lifted from an earlier, pre-PC product line, the IBM Displaywriter, and in that product, there was no potential vulnerability of this type.
My original message to RISKS, with the copy of the Daedalus article, contained (or more exactly, since my files do not indicate one way or the other, I believe contained) an explanatory introduction about Daedalus, and his splendid articles. It was not my intention to test the gullibility of the RISKS readership! Adding to the information that has since appeared about Daedalus: (i) he is, I'm pleased to say, based here in Newcastle, (ii) he has been claimed to be the world's most successful builder of perpetual motion machines! (A fascinating example, whose actual method of operation is still a matter of some mystery, is I understand in the Ontario Science Center, and (iii) he was the subject of a splendid documentary on BBC TV recently, possibly in the Horizon series, which is worth looking out for, not least for its account of his perpetual motion machines. Brian Randell
> For years now, we have been told that the cashless society is > just around the corner... If this is the true condition of the cashless society in UK, you are behind the Danish banks. For the last one and a half year I have been able to do shopping and pay with my DanKort (in english: DanCard) which is the card you receive from your bank if you want to have a cashcard. In the Danish system all the banks has join forces and developed a system with a card with crypt 4 digit PIN code on a magnetic stip, a independent company runs the ATM automats, the pay terminals in the shops etc. The system operated on high security level; you get three attempts to enter your PIN code correct. If you has not enter a valid code the card is automatical blocked and you have to go to your bank, to raise the blockade. The obvious RISK in this system is if anybody place a fraud ATM which just read the content on the magnetic stip and the PIN code the custom taps in on the keyboard. But at present I have not hear anybody trying this. Jacob Baekke, user of a DanKort.
The Unix dump discussion illustrates having to balance two risks — the risk of committing errors as an all-powerful superuser, vs. the risk of having an insecure system if access is improperly set for non-superusers. As pointed out by Brian Reid many months ago, giving system maintainers or administrators special privileges, such as write permission on system directories, has its own risks. Unix is a complex system, and setting certain protections has non-obvious side-effects. For example, dvk advises that disks should be protected r--r--r--; in other words, everyone will have read access to the raw disks. This is equivalent to giving EVERYBODY read access to ALL files on that disk! In some environments, this may be ok, but other environments may want users to have some privacy. Every site has to adopt some philosophy for dealing with Unix's all-or-nothing approach to privileges. I usually perform most system tasks as superuser, and after a long (and sometimes painful) learning process, I'm now careful enough not to destroy anything. -stan
Dumps should be run as "sys", or some other non-priv userID. Disks should be owned by "sys", and protected r--r--r--. Actually, r-------- is more appropriate... otherwise anyone who can get to /dev (which should be *anyone* since /dev/null is in there) can read the entire mounted disk, violating any security the filesystem was meant to offer. Running a debugger with macros for opening up the file system structure makes it easy to find files by hand... Mark Eichin SIPB Member & Project Athena ``Watchmaker''
Oopsie, oopsie! I meant to say "protect you disks r--r------", but my finger stuck and it came out "r--r--r--". If you do the latter, then anyone can read you disks, which is not such a great idea. -Dan Klein
This message gives some very sound advice; one can, and should, avoid root privileges if at all possible with UNIX. [... comment on r--r--r-- ...] There are also problems with doing system administration as someone other than root in a networked environment. Lots of people have their own workstations and can configure them any way they like, pretending to be any user who might have interesting privileges, like "sys". Sun's current version of NFS does not perform any serious validation, so if you export a filesystem to my workstation via NFS, I can read and write any file on it simply by setting up an account on my workstation with the appropriate user-ID. The only exception to this is root: an NFS client is never granted root privileges by an NFS server. So there may be reasons why some things HAVE to be owned by root, even when it would be better to avoid it, thanks to NFS. (Sun OS 4.0 apparently fixes this problem.) In this specific case, I don't think device files can be accessed under NFS (and you don't need to make the root filesystem exportable anyway), but anyone trying this kind of thing should be aware of the general problem. Dan Franklin
Please report problems with the web pages to the maintainer