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…
David Kennedy <76702.3557@compuserve.com>
Wed, 5 Mar 1997 16:59:16 -0500
http://www.nasa.gov is NASA's home page. It appears it was hacked last
night. It's off-line now. When a mirror of the hacked page is posted,
I'll let you know if someone else on the list doesn't first.
If my report is accurate, the hacked page included:
>Our mission is to continue where our colleagues the ILF left
>off. During the next month, we the members of H4G1S, will be
>launching an attack on corporate America. All who profit from
>the misuse of the internet
"ILF" refers to the Internet Liberation Front who attacked GE and others in
December 94. The only person who has claimed to be a member of the ILF is
Christopher Schanot, a then-high schooler from St. Louis, who's in jail for
what he did. He broke into systems using a password provided by a classmate
who was the son of an employee of one of the systems he entered. He also
used password sniffers to capture legitimate passwords that were passed over
the net unencrypted.
The rest of the hacked NASA page is some mundane pro-hacker stuff about
Kevin "Condor" Mitnick and Ed "Bernie S" Cummings.
Lesson: Running a web site requires somebody to take the time to know about
the vulnerabilities and *do* something about them. There are no quick
fixes. As William Hugh Murray, a colleague, says, "There is no magic."
Dave Kennedy CISSP National Computer Security Assoc 76702.3557@compuserve.com
Two More Microsoft Internet Explorer Bugs
David Kennedy <76702.3557@compuserve.com>
Fri, 7 Mar 1997 02:12:18 -0500
1. EliaShim warns of security hole in Internet Explorer
Courtesy of the COMTEX Newswire via CompuServe's Executive News Service
> PC Week Online (March 6, 1997) - Less than a week after the discovery of a
> potential security gap in Internet Explorer 4.0, Microsoft Corp. may have
> another hole to fill. EliaShim Ltd., an anti-virus company, claims it has
> identified security problems in Microsoft Internet Mail and News
> applications. "Hostile links" can be embedded in newsgroup messages or in
> messages received by Internet Mail as shortcuts, company officials said.
2. Another Internet Explorer Bug Found
Courtesy of the COMTEX Newswire via CompuServe's Executive News Service
> REDMOND, WASHINGTON, U.S.A., 1997 MAR 7 (Newsbytes) — By Bob Woods.
> Another bug in Microsoft's [NASDAQ:MSFT] Internet Explorer (IE) World Wide
> Web browsing software has been discovered by a group of University of
> Maryland students. The students posted their results at their Web site
> today, and claimed that the bug could let a hacker remotely break into a
> user's computer or install viruses onto the system. UMD students David
> Ross, Dennis Cheng, and Asher Kobin found the bug in IE 3.01.
Microsoft acknowledges the bug but hasn't defined it full impact.
> The bug apparently centers around IE's Iframe, or floating
> frames feature.
The patch for the URL/LNK bug does not fix the UMD student's bug.
> The students' Web site is at http://dec.dorm.umd.edu/ .
> Microsoft's IE site is at http://www.microsoft.com/ie .
Dave Kennedy [CISSP] Research Team Chief, National Computer Security Assoc.
Another MacInTax "Glitch"
David Kennedy <76702.3557@compuserve.com>
Fri, 7 Mar 1997 02:12:21 -0500
Intuit warns of MacInTax glitch
Courtesy of the COMTEX Newswire via CompuServe's Executive News Service:
> MacWEEK Online (March 5, 1997) - Intuit Inc. this week sent a letter to
> its MacInTax users detailing a potential pitfall for electronic
> filers. Users who fail to save their documents before filing them
> electronically may receive word from the IRS of an incomplete filing. The
> company said the problem will likely affect only a small percentage of
> users, as most would opt to save their work before transmitting
> files. However, there are some customers who tend to go straight to the
> electronic filing function without saving.
Patch at http://www.intuit.com/ or by disk.
> In a statement, Intuit Vice President Larry Wolfe said the problem is
> "absolutely covered" under Intuit's general product guarantee. "If a
> customer has filed an incomplete electronic return with MacInTax, Intuit
> will pay the penalty plus any interest assessed by the IRS," he said.
Dave Kennedy [CISSP] Research Team Chief, National Computer Security Assoc.
Re: 12/99 problem
"Clive D.W. Feather" <clive@demon.net>
Fri, 7 Mar 1997 08:19:07 +0000
This looked like a Y2K problem at first sight. However, it isn't. Some names
are changed to protect me from defamation suits.
I work for a major ISP, and many of our customers pay us monthly by credit
card. This problem hit a whole batch of customers at once, but I'll just
pick one and call him or her C. C has a card issued by a major bank, who
we'll call B. We use a major credit card organisation in the UK for all
credit card transactions; let's call them V.
When a customer signs up with us, they quote card number and expiry date,
which we enter on to our computer. Each month we take that data and send V a
packet of the form
Re: 12/99 problem
<msb@sq.com>
Fri, 7 Mar 97 11:11:44 EST
Clive Feather writes:
> This looked like a Y2K problem at first sight. However, it isn't.
Sure it is. Without Y2K, who would have thought of choosing the month/year
"12/99" as an out-of-band flag value? In fact it's a particularly silly
Y2K error, since 99/99 would have fitted the field length just as well.
> But just whose is the error ?
Either B's or V's, but in order to tell which, we'd have to know what they
said to each other and when. Did V tell B that they needed to know their
expiry rollover pattern in order to validate transactions, or did they just
assume that because B had been using a 3-year rollover they always would?
If the former, then did B inform V that their practice was being varied this
time, and if so, did they do it in timely manner so that V could be prepared
for it?
Mark Brader, msb@sq.com SoftQuad Inc., Toronto
Computer glitch leads to police friendly fire
"J.R.Valverde (jr)" <jrvalverde@samba.cnb.uam.es>
Fri, 07 Mar 1997 18:30:08 WET
The Vasque Country in the north of Spain has a strong terrorist group, ETA,
which -among other activities- often attacks the Police.
Last week there was a sad incident: two secret police groups started
shooting each other. The reason? According to the government it was all due
to a computer glitch.
Things are said to happen like this: that afternoon there had been a bombing
in town. One group of civil-dressed secret policemen saw a group of armed
guys in a car and started off after them. Of course, first thing they did
was call the central offices to ask for information on the car and its
owner. Here comes the computer bug: they could not get any information and
assumed those guys were the terrorists that had done the bombing.
The other car was loaded with secret policemen too. They saw that they were
being followed by armed civil-dressed people in a car, could not get any
information either and assumed they were being pursued by terrorists that
were after them to kill them in a second coup de main and fled away.
You can see what happened. At some point the first car stopped, the second
did the same, all them took their arms, all them got alarmed at seeing each
too their arms, someone shoot first, and hell was left loose...
The problem? relying on computers for tasks where human lifes are involved
and not having adequate fail-safe systems.
jr
Phil Agre <pagre@weber.ucsd.edu>
Thu, 6 Mar 1997 19:01:15 -0800 (PST)
[He's right. Phil]
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
This message was forwarded through the Red Rock Eater News Service (RRE).
Send any replies to the original author, listed in the From: field below.
You are welcome to send the message along to others but please do not use
the "redirect" command. For information on RRE, including instructions
for (un)subscribing, send an empty message to rre-help@weber.ucsd.edu
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Date: Thu, 6 Mar 1997 21:53:39 -0500
>From: Dean Esmay <esmay@syndicomm.com>
Subject: mouse-based interfaces
[...]
I was both pleased and disturbed to read Jay Hersh's comments on GUIs and
the disability community in your recent RRE mailing, and a bit concerned
about some of your comments on his thoughts. Not that either of you are
wrong, but you aren't exactly right either.
The deaf child, the woman with multiple sclerosis, and the blind man all
have fundamentally different needs, none of which are necessarily
compatible. Given that, I'm not sure who Jay Hersh thinks he's talking
about when he refers to the "community" needing to fight against
mouse-centric interfaces, and I am even less sure that the waters aren't
further muddied by your comments about the efficiency of keyboard
interfaces.
I worked for a number of years in an employment agency for the disabled, and
have attended and even led workshops on how to make computers more
accessible to the disabled. I think three things should be kept in mind
before anyone tries to influence how computers interact with people:
1) GUIs are substantially beneficial to some disabled users.
2) The problem with computer software not working well for some people has
been around far longer than the widespread use of GUIs.
3) There is no one solution (to date) that works well for everybody.
Prior to GUIs, the visually impaired did pretty darned well. After all,
text-based software can often be easily adapted to speech synthesis. While
there were things to complain about, the blind generally did pretty good.
But the blind are not the only members of the disability community, and the
non-blind disabled were often still faced with serious aggravations, or
even locked out in the cold. GUIs fixed that for many of them.
A number of devices exist that substitute for the traditional mouse, the
best of which is a strap-on headset with which a person with no use of
hands can point by merely moving her head (or even just her tongue if neck
mobility is limited) and "clicking" with a puff of breath. Your beloved
EMACS is normally worthless to a woman without arms. But give her an
interface where she can point and click with her hands-free mouse, "type"
clicking on the keys of a floating on-screen keyboard that feeds her
"keystrokes" to the window of her choice, and that responds to specific
voice commands for shortcuts, and she can do anything you can. In today's
GUI world, most properly-written software can use such special tools
without need for modification or special programming.
It's also probably unfair to lump Apple in with Microsoft. Apple has a long
history of working with the disability community. Back in the old Apple II
days, they manufactured special devices to help the disabled use their
computers. When the Mac came along, they cooperated enthusiastically with
the manufacturers of the hands-free mouse and similar devices, and worked
hard to make their GUI and their API work effortlessly with such special
tools. Apple also put a good bit of money into developing and testing
their Easy Access and Closeview extensions, which ship free with every
Mac/OS machine and vastly improve the interface for many disabled people
(including some with partial vision). They even include system software
extensions to make voice control possible in any program, and powerful
built-in scripting that can automate many tasks in many applications.
Of course, Apple comes up short with some, especially the blind. That
section of the community has generally stayed with the text interface
operating systems that work best for them. But still, Apple has arguably
done much to adapt to people with special needs, for which they deserve
credit.
But let's set aside Apple, which is only one imperfect company. The fact is
that today, a majority of the disabled can use much Windows software right
off the shelf, too. This is a tremendous step forward from ten years ago.
But the same GUI which has helped so many others is forcing the blind to the
sidelines. It's damned hard to adapt a GUI to a speech-synthesized,
sight-free world. It's not impossible; some very clever macro-based
work-arounds do exist. But much more needs to be done to address this
problem.
There badly needs to be a widespread discussion of issues like applications
and APIs which just plain ignore the needs of the disabled. We need to
encourage elimination of unnecessary popup menus and dialogs, buttons with
graphics but no text, buttons with text but no graphics, hierarchical
pull-down/pop-up menus that are a bitch to navigate if you can't see well or
have poor coordination, and more. The blind also have a need for more
productivity and utility software written specifically with them in mind;
the market is large enough now that, while it might not be much of a blip on
Microsoft's radar screens, it's more than enough for small companies and
cottage industrialists to make decent money. I've met a few people who
write that kind of software for a living, but there's room for more.
I commend you for bringing this issue to wider attention, and I hope you'll
talk more about it in Red Rock Eater. But I urge you not to get lost in
generalizations about what a vague, unspecified "disability community"
needs, or tangle that up with what you find most useful for yourself.
In any case, thanks for doing something to at least start people thinking
about these issues!
http://www.syndicomm.com/esmay
Trusting the software vendor (Re: Atkinson, RISKS-18.85)
Matt Welsh <mdw24@cl.cam.ac.uk>
7 Mar 1997 12:09:01 GMT
> ... you trust the retailer to sell you only legitimate product ...
It's interesting that Microsoft should defend Authenticode with this
analogy, when in fact Microsoft itself has been known to distribute CD-ROMs
with viruses. Given that I can't even "trust" Microsoft software obtained
through traditional distribution channels, by what stretch of belief am I
supposed to concede that Authenticode will solve this problem for
non-traditional channels?
M. Welsh, Cambridge Computer Laboratory
"Rich" computing versus security (Re: Atkinson, RISKS-18.85)
Matt Welsh <mdw24@cl.cam.ac.uk>
7 Mar 1997 12:24:05 GMT
>Users want and demand a rich computing experience. ...
It seems that it would be worthwhile in the course of this discussion to
step back a bit — instead of merely attacking or defending Authenticode,
why don't we look at the basic statement used to defend ActiveX?
Paraphrasing, "In order to have a rich computing experience, applications
must forgo some degree of security."
This is a contentious statement. A great deal of work has been done in both
the academic and industrial computing communities to develop computing
environments which enable 'sandboxing' of code and still provide a 'rich
computing experience' - e.g., flashy graphics, I/O device and network
access, and the like. Although with the advent of Java we are starting to
see these ideas in the mainstream, they're not particularly new.
It is far easier to verify and trust my Java Virtual Machine implementation,
for example, than it is to verify and trust every ActiveX control which comes
my way. In the former case we are basing our trust on the developers of
the computing environment - in the latter, upon every software developer
who ever writes or has a hand in every ActiveX control we use. In the
former case, the security of the system can be verified and is enforced
through technical means; in the latter, only through social and legal ones.
I know which one of these I'd rather employ.
M. Welsh, Cambridge Computer Laboratory
Re: ActiveX security: The other side (Rath, RISKS-18.87)
"Wayne K. Gerdes" <w.k.gerdes@larc.nasa.gov>
Fri, 07 Mar 1997 11:29:56 -0500
Having done a proposal for development of a worm/agent based software
distribution system similar to ActiveX or FTP inc's CyberAgent I have done
some serious thinking about the security problems. A truly useful piece of
software must have access similar to a standard user account, or at least a
captive account. Java's sandbox model is wonderful if the idea is to
provide graphics using the local machine's CPU power. It is, however, very
difficult to perform useful work with such a system, where useful work is
defined as, say word processing involving references to active objects and
saving files locally. A more scientific example might be performing
calculations as part of a distributed computation and forwarding the results
to some arbitrary destination. Another example might be querying a series
of remote databases and forwarding the results. These examples require the
ability to address arbitrary hosts, require disk storage space, and/or a
vanity of other access and privileges. The primary problem is that Windows
3.1 thru Windows 95 does not have the security features to isolate such
programs. Under "more advanced" operating systems such as UNIX, VMS, or
Windows NT, to name just a few, it is possible to create a "larger sandbox",
via separate accounts, captive accounts, disk quotas, limiting system calls,
etc. Note that even this will not eliminate the security problem(s). It is
always the temptation to install new software with root privilege or
equivalent. It is almost always possible for hackers to find some OS bug to
exploit. As readers of this digest know, even well intentioned programs
often corrupt data, crash machines etc.
The next element of the security problem, is the surprisingly high quality
of web distributed software. Despite the many security concerns of down
loading and executing some arbitrary piece of software written by Unknown,
most people do it and the worst thing that usually happens is that it
crashes. AS Mr. Rath notes, most people want to "just get on with it".
Security warning messages about "Should this program be allowed to access
the disk?" or "Accept this cookie?" quickly become annoying and get turned
off. Under these circumstances the current digital certificate and code
signing is a reasonable approach. What the current system does lack is
degrees of trust. It might be reasonable to require a very large bond
before issuing a AAA certificate and a small one for a BBB certificate. Web
sites could be established to rate the reliability of new software.
Something like Cancel Moose could be developed to chase down and deactivate
certificates belonging to errant software. Instead of downloading
certificates they might be implemented as active objects stored at well
known web sites. This would make the process of revoking them MUCH easier.
Looked at from this view point ActiveX vs Java can be seen as sort of
large scale beta testing of "the REAL solution".
Wayne K. Gerdes w.k.gerdes@larc.nasa.gov (757)864-1520 (AST, Data Systems)
Flight Electronics Tec. Div, Systems Integration Branch MS 152D
Lab monitoring (Re: Fraudulent use of e-mail addresses, RISKS-18.87)
Fritz Schneider <fritz@columbia.edu>
Fri, 7 Mar 1997 17:10:47 -0500 (EST)
Just a quick response to Andrej Panjkov's article regarding a bad
experience he had with e-mail forged in his name. After relating his
situation, Mr Panjkov gives the following advice:
> Lessons: monitor undergraduate computers carefully. At the very least,
> register users. And use PGP. Perhaps, we should all periodically sweep
> the web to see where our names are ending up?
Although in theory I agree with all of these suggestions (ignoring
the impracticality of the last), I question the wisdom of assuming that
misuse of technology such as the net will be perpetrated by the younger
generation.
There is no reason to necessarily suppose that older (graduate)
students are any more ethical than their younger (undergraduate)
counterparts. In fact, it seems to me that the BIGGEST risk comes from
those with more education, skills, and experience. Therefore if one can
only monitor one lab but not both, it would be more prudent to keep an eye
on those with the resources to carry out the most destructive acts.
I am, however, not convinced that mere "monitoring" of a computer
lab can prevent forged e-mail...
The Risk here: 1. Assuming that age/education is inversely
proportional to ill intent.
Fritz Schneider [ fritz@columbia.edu ]
Risks of crying wolf
David Lesher <wb8foz@netcom.com>
Fri, 7 Mar 1997 04:48:27 GMT
I am in Maryland [301], but the local calling area extends across DC [202]
into Virginia[703]. Within that area (which also includes parts of 410 and
soon will have 240 and 443), calls are 10D, with a leading "1" not
necessary. (Rather; without it, you are assured the call is not toll.)
So I tried to call 703 715 xxxx, in the Vienna area. But I got an
intercept, telling me that THAT number was now in the 540. (540 was
split from 703 last year, with Risks of its own after Bell sent
postcards to the WRONG group of customers...)
Now, AFAIK, no part of 540 is DC-Metro. And 715 did not move. But I gave it
a try, and sure enough, Bell decided "540-715X" was a 301 #, (Gaithersburg,
local to me) but one out of service. (With no "1" it knew better than to try
540-715-xxxx.)
Now, 715 is *still* in 703. So that intercept is bogus. But look who likely
gets wrong numbers from believing it: 540-715 if/when it's created, and 301
540-715x.
The Risks? Well, believing the error message may do you more harm than
good. And as the sparse NPA space turns increasingly dense, others won't
have the benefit that I received; that of the wrong number I dialed being
idle.
Did Arthur C. Clarke see THIS coming, too ;-?
wb8foz@nrk.com (301) 56-LINUX
Moonlighting on safety-critical systems
Jonathan Bowen <J.P.Bowen@reading.ac.uk>
Fri, 7 Mar 1997 09:24:45 GMT
Below is a possibly worrying message which I received recently. (Name and
contact details are blanked out.) Who takes the responsibility if things go
wrong?
Jonathan Bowen, Univ. of Reading, Department of Computer Science, Whiteknights,
PO Box 225, Reading, Berks RG6 6AY, UK http://www.cs.reading.ac.uk/people/jpb/
>Date: Thu, 6 Mar 1997 19:05:30 +0000
>From: xxxxxxxx <xxxxxxxx>
>To: J.P.Bowen@reading.ac.uk
>Subject: wanted
>Would it be appropriate for you to [post] this opportunity on your system?
> WANTED - Moonlighter with mixed signal simulator and formal verification
> tools to modify a circuit for a medical device. Reply confidentially to
> FAX xxx xxx xxxx.
The SEI Conference on Risk Management
Carol Biesecker <cb@SEI.CMU.EDU>
6 Mar 1997 18:54:32 GMT
The SEI Conference on Risk Management:
Managing Uncertainty in a Changing World
April 7-9, 1997, The Cavalier Hotel, Virginia Beach, Virginia
For the most current information about the SEI Conference
on Risk Management and other SEI events, visit our Web site at
www.sei.cmu.edu/products/calendar.html
For additional information about the conference, contact
SEI Customer Relations
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213
Phone, Voice Mail, and On-Demand FAX
412 / 268-5800
E-mail: customer-relations@sei.cmu.edu
World Wide Web: http://www.sei.cmu.edu
The keynote speakers are
. Dr. Paul G. Kaminski, Undersecretary of Defense Acquisition and Technology
. General Alton D. Slay, USAF (ret), Slay Enterprises, Inc.
. Timothy Lister, The Atlantic Systems Guild, Inc.
Five half-day tutorials are being offered during the morning of Monday, April
7, 1997.
Two panel sessions are planned for the afternoon of Tuesday, April 8, and
the morning of Wednesday, April 9.
A special track is planned for invited program managers to talk about
their risk management experiences. This track starts Monday afternoon,
April 7, 1997, and runs in parallel with two more tracks, Acquisition/Risk
Management in Practice and Theory, Models, and Lessons Learned.
The Ethics of Electronic Information in the 21st Century
Les Pourciau at UMem <POURCIAU@MSUVX1.MEMPHIS.EDU>
Fri, 07 Mar 1997 09:02:55 -0600 (CST)
THE ETHICS OF ELECTRONIC INFORMATION IN THE 21st CENTURY
September 26-28, 1997
The University of Memphis {Libraries & Information systems & Linder Center
for Urban Journalism & Division of Research and Graduate School & Marcus
Orr Center for the Humanities & Cecil C. Humphreys School of Law &
Fogelman College of Business and Economics }
Fogelman Executive Center, The University of Memphis, Memphis TN, U.S.A.
http://www.people.memphis.edu/~operations/fec_list.htmlx
Additional Memphis Web Site: http://www.memphistravel.com
Abstracts due by 25 April 1997. [Check website for details.]
Please report problems with the web pages to the maintainer