The Risks Digest

The RISKS Digest

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Volume 21 Issue 95

Tuesday 12 March 2002

Contents

ATTBI / Eudora / SSL
Jock Gill via Dave Farber
'Phantom Menace' typing is just a Microsoft speech feature
Dale Hawkins
Re: Yet another case of a program changing your input
Gene Wirchenko
Re: Air Force seeks better security from Microsoft
Tom Poe
Jei
Disclaimers
Michael Bacon
Re: Loosing It's Grammer Skill's
Michael Bacon
Klaus Brunnstein
Mike Albaugh
Merlyn Kline
Dave Williams
Re: The RISK of ignoring permission letters
Rob Slade
Greg Searle
George C. Kaplan
Michael Bacon
Re: Welland Canal Bridge runs into ship
Dave Gillett
Re: LED lights can reveal computer data
Nick Simicich
Peter B.
REVIEW: "Incident Response", Kevin Mandia/Chris Procise
Rob Slade
Info on RISKS (comp.risks)

ATTBI / Eudora / SSL

<Jock Gill <jock@jockgill.com>>
Tue, 12 Mar 2002 10:03:52 -0500

  [From Dave Farber's IP list.]

Eudora users who are ATTBI customers might want to know this.

As Eudora users will know, ATTBI Broadband [formerly Road Runner or
MediaOne] does NOT support Eudora -- only MS products.  What they may not
know is that ATTBI's instructions for re-configuring Eudora to work with
ATTBI contain a very peculiar instruction in lines 10 and 17 = suggesting
that you MUST select SECURE SOCKETS WHEN RECEIVING.

This is in fact NOT TRUE, as David Reed helped me to discover last night.
If you do follow their instructions and select the SSL feature, you will
discover that your RETURN address MUST be the same as your LOGIN name.
This, obviously prevents a return address other than the ATTBI domain.  So,
if you have your own domain and wish to use it in the RETURN field in
Eudora, do NOT select the SSL functions in steps 10 & 17 of ATTBI's online
instructions -- see their web site.

Trying to be a good dooby, I explicitly followed ATTBI's online
instructions, only to discover the above problem.  When ever I tried tied to
use <,jock@jockgill.com> as my return address, I got error 553 from the
ATTBI servers.

Calls with very long wait times to ATTBI, and chats with them online, were
fruitless to the point of their suggesting the 553 error message was an
Eudora problem.  The ATTBI techs had no idea what so ever about the
relationship between the so called SSL requirement and is effect to force
you to use your ATTBI login in name for your return address.

Makes you wonder why we ever trust large organizations.  As David might say,
the power of the edges to collectively organize around problems solved this
problem in very short order -- once I gave up on the old notion of turning
to the central authority.

Jock Gill < jock@jockgill.com > <www.jockgill.com <http://www.jockgill.com/> >
Interactive Digital Studies

  [For Dave's IP archives see:
    http://www.interesting-people.org/archives/interesting-people/
  ]


'Phantom Menace' typing is just a Microsoft speech feature

<Hawkins Dale <rhdale@yahoo.com>>
Tue, 12 Mar 2002 13:30:48 -0800 (PST)

Slashdot (slashdot.org) and others are reporting that "some Windows XP users
are finding random words inserted into their text as they write. The problem
is caused by XP's speech recognition system, which is turned on by default
by some manufacturers. It's listening to the random noise you get even when
the mic is turned off."

Microsoft is blaming the problem on some computer manufacturers who enable
this feature by default in their installation of the operating system.

Draw your own conclusions regarding the risks of adding powerful features
that users are unaware of.

Hawkins Dale


Re: Yet another case of a program changing your input (RISKS-21.94)

<genew@mail.ocis.net (Gene Wirchenko)>
Tue, 12 Mar 2002 08:16:44 GMT

Funny.  On Sunday, I was doing an Excel tutorial as part of an accounting
course.  The tutorial was setting up a grades spreadsheet system.  I ran
into the same problem of short grades being overridden by longer ones!

Then there was Word miscorrecting a word in an e-mail address for me
recently.  Unfortunately, the lab computers at my college have the Word
settings set so that spelling corrections are automatically accepted.  While
this can be turned off, it must be done every login.  What a bother.

My college is University College of the Cariboo.  The domain is
cariboo.bc.ca.  Word miscorrected "cariboo" to "caribou".  I'm glad that I
noted it as it happened as this was on my resume for co-op.

Just to add to the fun, Word does some substitutions.  Try typing a line
with a number of asterisks.  Word will replace it with blocks.  Sometimes,
you can delete this line.  Sometimes, you can't.  I have also had horizontal
lines inserted that I couldn't get rid of.  I had a draft for a report that
I had to retype, because I couldn't get rid of the lines.

Gene Wirchenko


Re: Air Force seeks better security from Microsoft

<tom poe <tompoe@renonevada.net>>
Tue, 12 Mar 2002 10:14:54 -0800

> "The military and the government don't really have too much choice at
> this point except to start to put pressure on Microsoft and others to
> improve software security," Erbschloe says.

Hi: Well, Erbschloe, you're wrong.  You have an easy, easy choice to make.
If $13 Billion in taxpayer losses isn't enough to switch OS and tighten
security for the Air Force, there's something terribly wrong in the Computer
Economics workshop?!!  Thanks, Tom


Re: Air Force seeks better security from Microsoft (Poe, RISKS-21.95)

<Jei <jei@cc.hut.fi>>
Tue, 12 Mar 2002 19:25:58 +0200 (EET)

Sounds to me like we need a law that empowers the consumers to demand their
money back if the products prove to be faulty.

But didn't the US lawmakers just make a law that empowers the software
makers to enforce whatever licences they like?

Software quality will not only get worse, but it will be impossible to
publicly state that it sucks.  Publishing security holes will also likely be
equal to legal suicide.

The only thing we'll get is a public mirage of better security and
functionality, while in reality things will actually be a lot worse.

Oh well.


Disclaimers

<"Michael (Streaky) Bacon" <streaky@baconsonline.com>>
Tue, 12 Mar 2002 07:47:47 -0000

A friend sent me the following disclaimer at the end of an e-mail he
received from a contact in the BBC (British Broadcasting Corporation).  It
reads (in part):

  "Please note that the BBC monitors e-mails sent or received. Further
  communication will signify your consent to this."

Now this presents a dilemma because, merely by responding, you consent to
the monitoring - making it challenging to refuse whilst keeping a convenient
and effective communication channel open.

Anyway, if the external correspondent uses (say) telefax and the internal
correspondent uses e-mail -- is that "communication".

If one does not consent (and can successfully communicate this without
compromising one's position), can one's internal correspondent continue to
send me e-mails - without them being monitored?

Further, since the first part of the 'disclaimer' says that, "the BBC
monitors e-mails sent", there is the unanswered question, "Was the original
e-mail monitored - WITHOUT the recipient's consent?"

Additionally, what constitutes a 'response'?  If the original message had
requested a 'read' or even 'received' response - often automatically sent --
would this be a 'consent' to the monitoring?

Differences between 'opt-in' and 'opt-out' are exploited by marketeers (see
several other threads, most recently Knox, RISKS 21.94), but RISKS arise
when those who write disclaimers are ignorant of the technology involved.

Also, why pick on only one form of communication?  How long before the
'thought police' in the BBC extend their monitoring to the telephone,
telefaxes and letters?

Michael (Streaky) Bacon


Re: Loosing It's Grammer Skill's (Searle, RISKS 21.94)

<"Michael (Streaky) Bacon" <streaky@baconsonline.com>>
Tue, 12 Mar 2002 07:18:22 -0000

I recently reviewed some pages on the Web site of a major computer
manufacturer and, among other issues, found several solecisms, grammatical
errors, strange and tortuous phraseology, mixed persons, typographical
errors and differences in how separate hypertext links to the same 'off
site' page were treated.  A particular classic was: "...  challenges of
reliability, scalability, and manageability that are needed ..." -- I hadn't
realised that anyone *needed* challenges!

On enquiry I was told that no-one reviewed for content, as the pages were
written by subject matter experts.  Any reviews were to check conformance
with corporate presentation style.  But even that alleged check missed the
incorrect presentation of the company name in one instance.

SMEs may know their subject, but clearly that isn't grammar, law or risk
management.

The risks are manifold, and include: inappropriate material being
accidentally or deliberately posted; the company being committed to do
something they never intended to do; corporate liability being attracted in
a manner that is not properly (risk) managed; any corporate commitment to
quality being thereby degraded.

Michael (Streaky) Bacon


Re: Loosing It's Grammer Skill's (Searle, RISKS 21.94)

<Klaus Brunnstein <brunnstein@informatik.uni-hamburg.de>>
Tue, 12 Mar 2002 09:54:21 +0100

Concerning Greg's complaint about some impact of contemporary publication
support software qw cause in reducing the quality of English (or AmGlish?)
writing, another -- possibly more serious -- cause may be related to what I
call the "imperialism of English": when multi-million non-native English
speakers and writers are forced to use English as communication vehicle, how
can someone assume that "quality English" may result? Moreover, differences
between "island English" and "American English" may also contribute to bad
grammar (as well as manuals even from English companies).

On the other side, we observe that German students use publication software
to produce better looking papers though at significantly lesser grammatical
quality. This tendency which is also observable in schools may not only be
attributed to usage if IT!

My 2 cents (yes, we have also cents in Germany now), with my apologies for
possibly bad grammar and expression :-)

Klaus Brunnstein (March 12, 2002)


Re: Loosing It's Grammer Skill's (Searle, RISKS-21.94)

<albaugh@spies.com>
Tue, 12 Mar 2002 08:25:13 -0800 (PST)

> ... "Driver's Wanted"

I believe Greg has misunderstood. They are trying to warn you that they are
a "family business", and that there are outstanding warrants for the driver
of this cab.  Perhaps you will choose this cab for a sense of adventure.
Perhaps you will decide that arriving at the airport with a half-dozen
police cars in hot pursuit is not your cup of tea.  Either way, you have to
applaud their honesty.


Re: Loosing It's Grammer Skill's (Searle, RISKS-21.94)

<"Merlyn Kline" <merlyn@zyweb.com>>
Tue, 12 Mar 2002 10:25:35 -0000

  [I omitted a comment on "Driver's Wanted" similar to Mike Albaugh's
  preceding message.  PGN]

[...] as you point out:

> Sure, I know what they really mean,
and
> English is defined by its common usage over an extended period of time.

So what's the problem? Sure[1], it's annoying when the language drifts away
from the dialect you had hammered in to you at school, but that's life. It's
not wrong; just different. If you want annoying, you should try being a
British English speaker reading Risks![2] In fact, as has been mentioned on
Risks before, there are actual risks here: e.g. American English has lost
the distinction between "ensure" and "insure". Here in Britain, I'm happy to
deal with someone who ensures risks won't be realised, but not so happy to
deal with someone who just insures. In America, I can't tell which is
which. One of my favourite examples of this type of error is a notice in a
local music store that says "CDs cannot be returned for a refund. This does
not effect your statutory rights." (No, I bet it doesn't!). I'm not sure
this is even an error in America, let alone funny[3].

The evolution of language is driven by a fantastically complex and
ultimately self-correcting system. If (e.g.) the taxi firm starts to suffer
because everyone thinks their drivers are wanted criminals, eventually there
will be another drift in the language to enhance the distinctions between
possession, plurals and elision.

Anyway, isn't your complaint really about the failings of an education
system that is apparently incapable of helping its clients understand the
simple rules related to the use of apostrophes in English?

>  Are we doomed to accept bad grammar as the official standard?

We are :(
Chaucer, even Shakespeare, would be horrified by what we call English.

Merlyn Kline

[1] Arrgh! I'm drifting into American English idiom! The power of context!

[2] Perhaps you are. See [1].

[3] OTOH perhaps I am mislead by the ever increasing abuse of these two
words, and the distinction remains in American English as well as
British. I'm not sure.


Re: Loosing It's Grammer Skill's (RISKS-21.94)

<Dave Williams <dave_williams@compuserve.com>>
Tue, 12 Mar 2002 14:31:28 +0000

You are talking about the rise of the Apostrophe Virus (also known in the
UK as the Greengrocers' Virus, because the misplaced apostrophe only used
to appear on hand lettered signs in fruit and vegetable shops)

The rise of DIY publishing, in print and on the Web, has propagated this
virus to the point that it now appears in national newspapers,
advertisements, and on major Web sites; all published by people who ought to
know better. The problem is compounded by the long-term shift to a less
literate culture, where words are less cared for, and spellcheckers are
assumed to handle all grammar issues.

As people see the misplaced apostrophe more and more in established
media, the virus becomes legitimised, and so they are more likely to use
an apostrophe, on the principle that it's best to put it in just in case

The probable future is that in time, the use of the apostrophe-s will become
the default for all occurrences of the letter s at the end of a word. So we
are soon likely to assume it's normal to see apostrophe's at the end of
word's, even though reader's of mature year's might think it suck's.

Dave Williams (or should that be William's?)

  [DIY = Do-it-yourself, a.k.a. samizdat, which might inspire a
  self-publishing outfit called Sammy's.Dot.com?  PGN]


Re: The RISK of ignoring permission letters (Knox, RISKS-21.94)

<Rob Slade <rslade@sprint.ca>>
Tue, 12 Mar 2002 11:18:53 -0800

Our recommendation in regard to spam, for those who did not want to expend
the time and effort required to track down the spammer and his upstream
provider, has always been to ignore it.  This new style of spam is rather
more problematic.  The United States now has a slew of legislation in regard
to spam: various states have their own, and I believe that there is federal
legislation as well.  The legal questions boggle the mind.  Is this just
another address harvesting scheme, like the old "reply to this message if
you want off the list" types?  Does a failure to respond to this type of
message constitute a legitimate "acceptance" on my part?  (Particularly for
those of us from outside the US?)

> This is NOT requesting permission. This is warning you that by NOT
> responding, you are implicitly consenting to them sending you spam. With
> UCITA, this might even become legally acceptable (like click-wrap licenses).

Yet another twist to the legal questions.  Would this kind of thing be legal
in Virginia?

> Finally, note how they try to play it cool in the last paragraph, talking
> about how I 'requested' to be notified of special offers.

Apparently I've done all kinds of things on the net that I've never actually
done.  I've even been signed up in some weird kind of pyramid/mlm scam that
I've never heard of ...

rslade@vcn.bc.ca  rslade@sprint.ca  slade@victoria.tc.ca p1@canada.com
http://victoria.tc.ca/techrev    or    http://sun.soci.niu.edu/~rslade


Re: The RISK of ignoring permission letters (Knox, RISKS-21.94)

<"Greg Searle" <greg_searle@hotmail.com>>
Tue, 12 Mar 2002 08:34:58 -0500

The best thing that you can do when you receive this type of message is to
REPORT IT.  This message itself is unsolicited e-mail.  If you report it to
the ISP that it was sent through, then the ISP may enforce its Acceptable
Use Policy, and make the offending company think twice about this practice.
Spammers are good liars.  Call the lie and report the abuse, pointing out
that you DID NOT request the message.


Re: The RISK of ignoring permission letters (Knox, RISKS-21.94)

<"George C. Kaplan" <gckaplan@ack.berkeley.edu>>
Mon, 11 Mar 2002 16:38:34 -0800

> With UCITA, this might even become legally acceptable ...

I don't know about whether UCITA makes this legal, but it's commonly
accepted that such "opt-out" links don't actually remove you from the
spammer's mailing list.  Instead, they confirm that there's a real person
reading e-mail sent to your address, thus ensuring that you'll end up on
*more* mailing lists.

> Finally, note how they try to play it cool in the last paragraph, talking
> about how I 'requested' to be notified of special offers. This is an
> outright lie.

If they lie to you about this, don't you think they'll lie to you about
what their opt-out link does?

George C. Kaplan, Communication & Network Services, University of California
at Berkeley  1-510-643-0496  gckaplan@ack.berkeley.edu


Re: The RISK of ignoring permission letters (Knox, RISKS 21.94)

<"Michael (Streaky) Bacon" <streaky@baconsonline.com>>
Tue, 12 Mar 2002 07:27:05 -0000

This presents a compound RISK.  On the one hand, not replying appears to
give consent to continuing to receive e-mail; on the other hand, replying
confirms your e-mail address - which can then be resold as a legitimate,
active, human-attended address.

Michael (Streaky) Bacon


Re: Welland Canal Bridge runs into ship (RISKS-21.61)

<Dave Gillett <dgillett@deepforest.org>>
Tue, 12 Mar 2002 14:08:06 -0800

The freighter Windoc, which was hit by a lift bridge last summer, losing its
wheelhouse and funnel and catching fire, has made the news again.

Windoc was apparently one of twelve freighters wintering over in Hamilton
harbor, and one of three of those to break loose from their moorings in 130
kph winds last week.  The ship drifted for about 5 km before grounding close
to a major highway.

No obvious computer connection, just follow-up on an old item....


Re: LED lights can reveal computer data (NewsScan, RISKS-21.94)

<Nick Simicich <njs@scifi.squawk.com>>
Mon, 11 Mar 2002 22:07:41 -0500

It is not quite true that no one has looked at reading computer data from
LEDs before.  In the 1990 timeframe, there was a brand of scuba computer
called the Orca Delphi that would dump recordings of your depth profiles to
a LED which normally functioned as a decompression warning LED.  You put it
in dump mode by disconnecting the power (9v lithium or alkaline battery) and
reconnecting it within a few seconds.

As you can imagine, most diving computers are designed on the "KISS"
principle.  Errors in these computers could cause a life threatening
condition - by incorrectly calculating your decompression obligation, they
could put you at risk.  An inexperienced diver might not detect that the
answers that the computer was calculating was wrong. But they are purposely
simply devices. They may not even have an "on" button, for example---they
may turn on in response to water pressure, conductivity, or, in the case of
this computer, the fact that you turned on your air (this computer also
tried to estimate how much air you had left in minutes based on how rapidly
you were using it, so it had a high pressure air connection).  This frees
you from the task loading of having to remember to turn the computer on.
Many do not have an off switch - once they determine that you have
"completely decompressed" according to their mathematical model, they turn
off automatically.  The point here was that the engineers did not want to
add the complexity of an extra electrical interface to this computer for
dumping - they wanted two inputs, the water pressure and tank pressure
transducers, one power input, and the lcd panel for output.  And the LED to
call your attention to warning issues.  The point was to try and get a
second use out of this LED as a data output device.

In any case, the company had promised a dump device for the computer and
never delivered.  The method of memory dumping was not initially announced,
although they eventually mentioned, at a lecture, that it was going to be a
"light pen". Someone noted that under some circumstances, disconnecting and
reconnecting the power to the computer (it was a nine volt battery) caused
the LED to light up for a few seconds at half brightness.  I made a call to
the engineer and he admitted that yes, that was their planned dump method --
they flashed the LED at 2400-8-N-1, and simply dumped the memory.  The dump
was in this format:

 >000 C7 FF C0 48 C0 01 8D A5 8D A0 C7 FF C0 47 C0 07
 >010 89 97 8D 9A 84 40 84 33 80 2E 80 2B 80 2C 80 2D

...and so on.  That is, it dumped in ascii characters, complete with offsets
at the beginning of each line, and a crlf at the end.

There was a checksum for some of the memory, but not much of it.

I'm not an electronics person, and, whereas there were circuits published
(on rec.scuba), we were never able to get anything that worked reliably.  We
tried the approach of reading the LED directly, and it was difficult to hold
the detector in the exact alignment required for the duration of the dump.
It was actually so difficult to get a good dump by reading the light from
the LED that we built a circuit that measured battery voltage instead.  The
company engineers had the same problem, I heard.  I also heard that they had
problems getting consistent readings because of LED brightness differences
and positioning under the faceplate.  The engineer suggested the battery
method to me - and whereas I was able to breadboard a circuit and get a dump
with it, I was not enough of an electronics person to be able to build one
that would adapt to various battery voltages - mine would only work with a
fresh lithium battery and an oscilloscope for tuning.

Obviously, Loughry has a great deal more skill than we did in reading these
LEDs.

Search google in rec.scuba for the words "orca delphi dive dump device".
There are some posts from 1990.

Nick Simicich - njs@scifi.squawk.com


Re: LED lights can reveal computer data (NewsScan, RISKS-21.94)

<peter@whirled-routers.com>
Mon, 11 Mar 2002 15:53:49 -0800

I'll believe it when I see it.
The articles actually state, that no one got it to work yet.
Until then : FUD !

Peter B.

Whirled Routers, 200 Pier Ave. Suite 39, Hermosa Beach, CA 90254 USA
310 376 8755 / fax 8785


REVIEW: "Incident Response", Kevin Mandia/Chris Procise

<Rob Slade <rslade@sprint.ca>>
Tue, 12 Mar 2002 07:49:30 -0800

BKINCDRS.RVW   20020108

"Incident Response", Kevin Mandia/Chris Procise, 2001, 0-07-213182-9,
U39.99
%A   Kevin Mandia mandiak@erols.com
%A   Chris Procise authors@incidentresponsebook.com
%C   300 Water Street, Whitby, Ontario   L1N 9B6
%D   2001
%G   0-07-213182-9
%I   McGraw-Hill Ryerson/Osborne
%O   U$39.99 905-430-5000 fax: 905-430-5020
%P   509 p.
%T   "Incident Response: Investigating Computer Crime"

Part one is supposed to provide us with the basics of incident
response.  Despite the assertion, in the introduction, that such
response deals with much more than computer crime and that incidents
can vary widely, chapter one details a deliberate and malicious
intrusion into a computer system, by an incredibly inept attacker,
using inside information.  Chapter two provides a definition of
incident response, but it does lean heavily towards crimes, law
enforcement involvement, and directed attacks.  The material also
assumes that an incident response team can be called upon or formed at
short notice.  The suggestions for advance preparation, in chapter
three, do cover a broad range, but the writing is not always
organized, and the material has gaps and covers many topics
superficially.

Part two purports to deal with technical issues.  Chapter four deals
with guidelines for investigations, but, again, concentrates only on
directed attacks from outside the organization.  The computer forensic
process, in chapter five, is limited to retention and copying of
evidence.  There is a rather terse review of Internet Protocol header
information in chapter six.  Chapter seven lists some information
related to network monitoring and logging.  "Advanced Network
Surveillance" (chapter eight) examines a few of the more convoluted
exploits.

Part three describes operating system functions associated with system
investigation.  Chapters nine to twelve list a number of utility
programs that can be used to obtain system information.

Part four is a grab bag of material dealing with special topics,
chapter thirteen dealing with routers, fourteen the Web, and fifteen
various servers.  A number of security and security breaking tools are
enumerated in chapter sixteen.

The emphasis in this book is adversarial: seeing incident response as
primarily a matter of active defence against an active attacker.  Most
companies will probably see incident response as a matter related to
technical support: an endless stream of incidents, most of which are
trivial, and a select few of which indicate serious problems.  As
such, the book does, occasionally, point out some matters to consider,
and possibly new practices to adopt in order to deal with those
isolated events that are important enough to turn over to law
enforcement agencies.  However, overall, the text does not provide
much guidance in preparing for and responding to serious incidents.

copyright Robert M. Slade, 2002   BKINCDRS.RVW   20020108
rslade@vcn.bc.ca  rslade@sprint.ca  slade@victoria.tc.ca p1@canada.com
http://victoria.tc.ca/techrev    or    http://sun.soci.niu.edu/~rslade

Please report problems with the web pages to the maintainer

Top