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…
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 pst!comdesign@pyramid.com ...!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: willis@violet.berkeley.edu (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