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…
Extra! Extra! Read all about it!
Yes, informed sources report that this week's newspapers may carry a
story about how a persistent intruder broke into over 30 US computers.
This tale, brewing for about 2 years, tells of a methodical attack on
hundreds of military and defense contractor's computers. Unknown to
him, we silently monitored him at Lawrence Berkeley Laboratory,
where we traced his connections and recorded all his keystrokes.
The intruder used a variety of networks, including the Milnet/Arpanet, MFEnet,
Tymnet, Datex-P, and analog telephone services. Despite his convoluted
pathways, we traced him back to his lair in West Germany. By cooperative
efforts of law enforcement people and network managers, we developed traceback
methods to trace him halfway around the world in less than 2 minutes.
A part of the story is in the German popular magazine QUICK of April 12, 1988.
Apparently, they somehow got a copy of my laboratory notebook. From those
notes, they wove a tale of high-tech intrigue, starring a mad scientist who
dwelled in a "communal living situation" in Berkeley. Following their
publicity, reporters have interviewed me, and I expect newspaper publicity in
either the Daily Planet or some other great metropolitan newspaper.
But the complete story will appear in the May issue of the Communications of
the ACM. We had planned no publicity until the issue was in the mail, but
alas, the German magazine printed it, and the cat was out of the bag. The
real scoop is in the May CACM, so make sure your ACM dues are paid up!
Cheers to all RISKeeS,
Cliff Stoll CPStoll@lbl.gov
[I am very grateful to Cliff, the super-scoop-er, for contributing this
mere bag-cat-tell tale teaser. This is the eve of the annual IEEE
Symposium on Security and Privacy, at which more than a few RISKS
participants will be taken away from their RISKS fixes — so they'll
just have to watch the papers. Stay tuned for further developments. PGN]
After some contacts with some well-informed DEC users and DEC
software engineers, I have gathered the following information:
The `urgent update' solves some problems with Local Area VAX clusters
(LAVc), associated with VAX Workstation Software (VWS). Following the `new
DEC philosophy', DECs security staff doesnot wish to more precisely inform
its users; moreover, only a few DEC software engineers have been informed.
The update contains 1134 blocks (plus Kid Install), and it contains totally
new images of 5 VWS modules: SYS, TTDRIVER, WTDRIVER,UIBSG, DBGSSISHR,
together with a list of several more patches. The reason for this update has
evidently been discussed in the German DECUS meeting, held in Aachen, March
1988; when the discussion is available in printed form, I will inform you.
Unfortunately, the update may have produced a new secutity problem, as
indicated in the INFO-VAX letter of Darren Griffith which I add for your
information:
----------copy of D.Griffith INFO-VAX letter--------------
Delivery-date: Tuesday, April 12, 1988 at 13:59 GMT+0100
Send-date: Monday, April 11, 1988 at 13:50 GMT-0100
From:Darren Griffiths <S=dagg;OU=csa4;O=lbl;P=gov;C=nn>
To:<S=info-vax;OU=kl;O=sri;P=com;C=nn>
Subject:DEC's security patch. Just say no!
Date: Thu, 7 Apr 88 20:10:22 PDT
DEC recently released a mandatory update to VMS that fixes some problems in
SYS, TTDRIVER, WTDRIVER, UISBG and DBGSSISHR. Upon installing this update
on a LAVc some problems were experienced, people running VAXstations that
use the VAX Workstation Software may want to read this before installing the
fixes on their systems.
It seems that one of the fixes was to a known problem with the way device
protections are assigned under VWS. When you create a new window the software
creates a new device WTAx: that is basically a copy of the template workstation
device WTA0:. The "problem" that was "fixed" is that some of the protection
bits get changed when the new device is created, the fix stops this from
happening. The problem does introduce a security hole so I am trying to avoid
being too specific.
So far all of this sounds quite nice, the problem is corrected and things
should go on as normal. Unfortunately another problem is introduced. When you
create your first window on the workstation LOGINOUT is running with a system
UIC and the window is created by opening the template device WTA0 and having
another device created for you, when you then decide that it would be exciting
to have a second window and you try to auto-login, the process is created with
your UIC and privileges. LOGINOUT opens up WTA0: expecting to get a device
allocated to it, the device is created but cannot be allocated to you because
the security patch fixed the protection bits very nicely and your process
doesn't have privilege to look at the device.
This problem can be avoided in four ways.
1) Don't install the patches at all.
2) The problem doesn't occur if your **DEFAULT** privileges include
something like READALL, that way you will be able to get the DEVICE.
Note that all you need is read access to be able to allocate a
non-shareable device like a workstation window.
3) If you've already installed the patch and don't want to be give
everyone privileges you can remove the patched version of
SYS$SYSTEM:TTDRIVER.EXE, put the old one back and reboot.
4) You can uncomment the lines in SYS$MANAGER:UISBG.DAT that allow
you to have another option in the workstation menu that will let
you login without auto-login. This way you just have to type
your username and password each time a window is created.
I have contacted DEC about the problem and hope to have an answer very soon,
I'll let the net know when this answer comes in. If anyone has any questions
or further information let me know.
--Darren
Lawrence Berkeley Labs
DAGG@LBL.GOV
------------------end of Darren's e-letter------------------
After having discussed the problem described here with DEC
security experts, there could be a problem with AUTO-LOGIN
when a second window is opened; nevertheless, I follow DEC's
advice that users should NOT follow one of `Darren's four ways'
since this might re-install the security problem just patched away.
Klaus Brunnstein, University of Hamburg, Faculty for Informatics
In RISKS Volume 6 : Issue 49 the following program fragment appeared:
10 PRINT 1000
GOTO 10
1000 FORMAT ('+', 132*'-')
This reminded me of a colleague at the University of Queensland who used
to use a loop with the same FORMAT statement to almost-perforate forms
("tear along dotted line"). The risk, of course, was not when he had got
it right, but in all the attempts to find the right value for the
iteration limit... The operators became pretty fed up with reloading the
paper when the value was too high and he sliced it through!
A friend of mine recently received a new ATM card in the mail, with a notice
saying the old one had expired. In the following, card A is the old, expired
card, and card B is the new one. Here's what happened:
1. Not realizing that A had expired, he used it in an ATM. Since it had
expired, the machine ate the card.
2. The bank discovered the card in the machine, and a "new card event"
occurred — he was issued a third card (C). Apparently, the
bank did not check to see *why* the card was in the machine.
3. Next, he tried to use card B. This time, the machine ate it because
previous cards were invalidated when the bank issued card C.
Now, his question is: will the machine eat card C when he uses it? The
person he talked to at the bank assured him it would not, but he's a
little skeptical....
Win Treese, DEC/Project Athena
>I suppose all I'm saying is that if it was forseeable or deduceably likely a >programmer is in some way culpable when the system breaks down. > (yes/no ?) As noted by another RISKS author in the same issue: it's under our noses. See John Shore's article in the April 1988 CACM. --eugene miya
We always talk about computer induced RISKS in this group. I encounter a wrongly programmed cash register every month and the system crackers are scanning telephone pre-fixes all the time (my answering machines fields these). Let's talk about some personal BENEFITS! 8-) Yesterday, I went to the post office to purchase several rolls of stamps for an ACM chapter mailing. The Office has these vending machines with a big added box to the side to recognize and collect large sums of money. I don't know if they have micros in them (I hope so otherwise this isn't a computer BENEFIT). I've done this before, but I feel a bit uncomfortable putting $20s into these machines (just the size). With the increase in postage, I now also have to put $5s in as well. The $5s I got from McDonalds (near the on-base Post Office) were a bit worn. The first was not accepted (fair enough). The second had some trouble, but it was taken. Time to insert the next $20 for a roll. It would not take it. But it was clean and just came from my automatic teller. I looked up to discover that the $5 had registered twice ($10) even though it took only one bill! Now that's postage! Let me know when Email can do this. Anyway, these machines have "programmed limits" on the amount of money they can process. It won't take $20 (I need a ROLL for a stamp machine and these cost $25). I can't get change, the coin return is not hooked up to the bill recognizer, so I have to buy some smaller packages of stamps. The ACM (me in this case) comes out $5 in stamps ahead. Forget color copiers (oops, almost said that trademark) and change makers, how do I repeat what I just did? --eugene miya NASA Ames Research Center, Moffett Field, CA [Be sure to read the instructions FIRST. They say PLEASE READ THE INSTRUCTIONS BEFORE DEPOSITING BILLS... There can be some nasty side-effects if you don't — e.g., if the selction you want is OUT -- no facility for a refund. PGN]
In Risks 6.61, Will Martin suggests using a color chart for finding the
answer to the "Skin color:" question on various forms. Although his
suggestion was made in a humorous sense, I would like to point out a risk
to this as well as other areas more applicable to this forum. Not all
people see colors in the same way. Many people are color blind to one
extent or another (actually, the preferred medical term is color deficiency,
since most "color blind" people can see some colors just fine--I prefer
color blindness since most people know what it means). I personally am
red-green color blind, which means that I have difficulty distinguishing
some shades of red, green, and brown (pink and purple are also sometimes
difficult). When we recently purchased an aquarium, I, enjoying scientific
experiments, purchased a number of water test kits to monitor pH, ammonia
levels, water hardness, etc. Every time I test the water, I carefully mix
the water with the reagent... and ask my wife what the result is!
Many potential risks associated with color blindness have been identified
and dealt with. For example, the colors in most traffic lights are chosen
to be identifiable to color blind people--the reds and greens which can
cause problems are ignored. However, many software developers do not
consider such matters. For example, I recently saw a videotape demo of
a distributed systems modeling tool which used color to indicate the
state of the various parts--green meant one thing, and gold meant another.
The problem is, I couldn't tell them apart easily. A good design practice
is to let the user customize the colors to his or her own tastes and
abilities, but this raises another risk: that you get used to your own
customized setup, and have problems interacting with other people
who use a different one. For example, when I use Unix, I have an alias
"ty" which uses the program "more" to display a file a screenfull at
a time. When a novice Unix user needs help, I invariably try to use
my personal command on their account, which doesn't work.
A related problem is the fact that red is often used to indicate danger or
urgency. Red is also the hardest color for me to see--some shades seem much
darker than they really are. On many color terminals and computers (such as
the IBM PC), I can barely read red characters on a black background--the color
choice for many important warning messages. Many color blind friends have the
same problem. May I suggest treating red as black, and for urgent messages
either using white on red or red on white? I probably don't need to stress the
importance of color choice (and possibly field testing with color blind people)
for systems where a missed warning message can cause a serious risk.
Rick Sidwell
[I trust Stendhal was not color blind! PGN]
In the end any attempt to neatly categorize animals of any kind,
including people, is bound to fail... there must always be problematical
borderline cases. This goes for such obvious cases as Race and Religion,
but applies equally well to such things as gender, nationality, and species.
Eastern Blue Jays interbreed with Scrub Jays in Texas and
Stellar's Jays in Colorado. But they are still considered separate
species, because the indeterminate cases are so rare --- 99.9% of the
time the birds you see WILL look like one of the ones in the field guide.
If intermixing continues, the distinction will eventually have to be dropped.
For example, red-shafted and yellow-shafted flickers are now considered
only commonly-occuring color patterns of one species.
The same goes with race in people --- it is a useful identifying
trait only because the "problem" cases have been for the most part exceptions.
As the number of mixed-race people increases, as it must, the distinction
gradually loses statistical value.
The only sure way to create clean-cut categories is to force
your measured property onto some well-defined set like the Real Numbers
and put in an arbitrary dividing line, or to legislate that indeterminate
cases are not legally recognized.
If the value on line 16 is at least 14,451 but not over 14,550 and your
filing status is 1 or 3 your California tax is $338...
[Note that if you use the tax schedule instead of the tax table, you get
a (slightly) different result. And whether or not you round to even
dollars or not throughout your return also produces different results.
Clean-cut, but not clear-cut. PGN]
Re: a message about "RACE=OTHER" defaulting to "RACE=WHITE". This is hearsay, so take it with a grain of salt, but I was told by a friend that he started filling the ethnicity slot on forms at UCB with "prussian". This apparently did not default to "white".
Tom Betz writes in RISKS DIGEST 6.58: > A question I would find most interesting to discuss here would be the > question of this Republic within the Republic. How are the lives of those > who are too ill-educated to use these tools effectively going to be affected > by the increased power of those of us who >do< use them? They are going to be affected greatly. "Power Corrupts" is not precisely what I'm getting at, but power permits abuse. Did the FCC know what hit them when those x-thousand letters arrived? Put that power in the hands of the few who would abuse it, and they will. So it's important to temper their ability to do so. Can someone be slandered through a public forum if there are 100 other people in the forum willing to stand up and help defend them? When it's out of the public eye, then it's a different thing. With power comes responsibility, and networks have to be able to teach responsibility and tolerance to their members to assure that they are not used wrongly. > Do we have a responsibility to do whatever we can to spread the power around > to these people? To prevent abuse, we must give those who would be abused the ability to defend themselves. In order to do this, we must get them to use the tools. > How can we do this? How can our computers help us help them? Good question. It's difficult. But I think distance education is a start. Promote the use computer networks as an educational tool throughout the world. Teach people to speak, read and write. As this happens, new communities are created: isolated people discover that they are not alone in life, that others share their thoughts and feelings. This will give them the initiative to bring themselves up out of dispair. > Serious questions.... The world has a number of BIG problems to solve, like pollution, wars, overpopulation, and famine. Perhaps, through computer networks, we can enable the world the to save itself. Paul Shields, Technical Support Manager for the Native Computer Communications Network, York University, Toronto Canada. shields@yunccn.UUCP, ...utzoo!yunexus!gen1!yunccn!shields
> .. test button to see if the LED has failed
Better still would be to have (say) a green LED for positive indication of 'it
is safe to ascend'. Green might be difficult to see underwater. Maybe just a
solid red LED for 'safe' and a *seperate* flashing red LED for 'wait'.
Mike
Preliminary Program — PRODUCTIVITY: PROGRESS, PROSPECTS, AND PAYOFF
27th Annual Technical Symposium of the Washington DC Chapter of ACM
Gaithersburg, Maryland June 9, 1988
Sponsors:
Washington DC Chapter, Association for Computing Machinery;
Institute for Computer Sciences & Technology, National Bureau of Standards
Key Dates:
Register by June 1, 1988 and save over 10% of at door rate
Register by May 1, 1988 and save an additional 15%
Special rate for full time students
Productivity is a key issue in the information industry. Information
technology must provide the means to maintain and enhance productivity. The
symposium "Productivity: Progress, Prospects, and Payoff" will explore
theoretical and practical issues in developing and applying technology in an
information-based society.
Keynote address: "Near Term Improvements in Productivity"
Howard Yudkin, President and CEO, Software Productivity Consortium
Plenary panel: "What Are the Impediments to Improving Productivity?"
Walter Douherty, IBM
Phil Kiviat, SAGE Federal Systems
Marshall Potter, U.S. Navy
Al Scherr, IBM
Parallel sessions:
Processes and Tools for Higher Software Economics and Reuse
Software Productivity Uncertainty in Software Requirements
Software Specification Tools Development
Panel-Data Management Standards Expert Systems and Knowledge
A Key to Enhanced Productivity Engineering in Software Engineering
For more information, contact the Symposium General Chairman:
Charles E. Youman, DC Chapter ACM, P.O. Box 12953, Arlington, VA 22209-8953
(703) 883-6349 youman@mitre.arpa
PRODUCTIVITY: PROGRESS, PROSPECTS, AND PAYOFF — Preliminary Program
[Please Pardon Persistent Alliteration. P.]
Please report problems with the web pages to the maintainer