The RISKS Digest
Volume 23 Issue 30

Monday, 5th April 2004

Forum on Risks to the Public in Computers and Related Systems

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

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…

Contents

GM recalls Cadillac SRX
Monty Solomon
Firetruck steers itself into tree
Caleb Hess
800,000 cards overcharged at Wal-Mart stores
Monty Solomon
News24's not-very-restrictive access restrictions
Cody Boisclair
Time records often altered, job experts say
Bob Schuchman
4.6-million DSL subscribers' data leaked in Japan?
Chiaki Ishikawa
Pilot study of cybercrime against businesses
Michel Kabay
Risks of broadband upgrades
Jeremy Epstein
Too Many Pips!
Andrew Watkins
Fighting back at spam, viruses, etc.?
Neil Youngman
Risks of malicious code in MIDI instruments/robots
Kenji Rikitake
Net hoaxes snare fools all year
Monty Solomon
Re: Bridge construction mismatch
Stephen Poley
Darryl Smith
Re: AT&T Alerts Consumers About the Latest Scams
Pekka Pihlajasaari
Netsky.P and iframe src=??cid variant
Rob Slade
Latest Citibank scam...
Cody Boisclair
Who's in charge of the e-mail virus war, and are we losing?
Steve Summit
Re: Buffer overflows and Burroughs/Unisys
Crispin Cowan
Info on RISKS (comp.risks)

GM recalls Cadillac SRX

<Monty Solomon <monty@roscom.com>>
Fri, 2 Apr 2004 17:57:08 -0500

General Motors Corp will recall 12,329 Cadillac SRXs equipped with all-wheel
drive, following two reports of a software anomaly that causes a one-second
delay in the anti-lock brakes activating to stop the vehicle — reportedly
only in the first few seconds of driving when the SUV is moving slowly.  One
owner crashed his SRX into his garage wall following the brake delay, but
was uninjured.  (Buick Rendezvous SUVs are also being recalled because of a
faulty latch on the liftgate.)  [Source: Reuters, 2 Apr 2004; PGN-ed]
  <http://finance.lycos.com/home/news/story.asp?story=40999216>


Firetruck steers itself into tree

<Caleb Hess <hess@cs.indiana.edu>>
Fri, 02 Apr 2004 13:31:39 -0500

A major US manufacturer of firefighting apparatus has begun offering an
electronically controlled all-wheel steering option for its large
trucks. The system offers three driver-selected operating modes, in which
the rear wheels are either locked in straight-ahead position, or angled with
or in opposition to the front wheels.

One such truck, owned by the town of Natick, Massachusetts, was recently
involved in a collision with a tree. Firefighter union President Danny
Hartwell said the truck's rear axles turned on their own as the truck
traveled to a call. "The back end wrapped around a tree and there was
nothing the guys could do about it," Hartwell said. The truck manufacturer
examined an onboard computer and determined the accident was not caused by a
mechanical error.  However, the analysis also showed human error was not a
factor.

Quoting from the manufacturer's description, "The entire system is designed
for fail-safe operation.  System interlocks and a self-diagnostic
troubleshooting system are in place to enhance safety and reliability."

<http://cms.firehouse.com/content/article/article.jsp?sectionId=46&id=28508>


800,000 cards overcharged at Wal-Mart stores

<Monty Solomon <monty@roscom.com>>
Sun, 4 Apr 2004 22:30:53 -0400

[Source: Dan D'Ambrosio, Associated Press, 4 Apr 2004; PGN-ed]

A computer hardware problem caused more than 800,000 credit and debit card
transactions to be double- or triple-billed last week at Wal-Mart stores
nationwide, according to officials at First Data Corp., which handled the
electronic payments.  The excess Visa and Mastercard charges, which occurred
on 31 Mar 2004 and were posted on 1 Apr 2004, have been reversed, First Data
spokeswoman Staci Busby said Sunday.  [...]
<http://finance.lycos.com/qc/news/story.aspx?story=200404050213_APO_V3173>

First Data says glitch hit card users at Wal-Mart
4 April 2004, 4:57pm ET, Reuters
<http://finance.lycos.com/qc/news/story.aspx?story=200404042057_RTR_N04362746>

Wal-Mart Customers Affected by Computer System Disruption at First
Data; Toll-Free Number Open for Consumer Inquiries
2 April 2004, 10:31pm ET, PR Newswire
<http://finance.lycos.com/qc/news/story.aspx?story=200404030331_PRN__LAF044>


News24's not-very-restrictive access restrictions

<"Cody B." <cody@zone38.net>>
Sun, 04 Apr 2004 19:38:12 -0400

Oh, my. This one ought to win some sort of award for brazen cluelessness
about how the web works...

News24.co.za, a popular news site in South Africa, has begun to limit access
to articles by international users-- in the same vein as the London Times'
Web site, for instance-- allegedly due to "escalating international
bandwidth costs".  Foreign users of the site must pay a monthly registration
fee in order to read the latest news from South Africa.

One minor oversight, though: users are forwarded to the registration form in
question by means of a Javascript redirect.  Thus, foreigners can read all
of News24's articles in full, at absolutely no cost, *simply by turning
Javascript off*.

I don't even think I need to point out the many things that are utterly
wrong with this.

Cody "codeman38" Boisclair  <http://www.zone38.net/>  cody@zone38.net


Time records often altered, job experts say

<Bob Schuchman <schuchmanr@ieee.org>>
Sat, 03 Apr 2004 12:23:07 -0800

Here's another data modification risk: a manager altering computerized
time-card records to "shave time" — reducing the hours worked by employees,
"secretly deleting hours to cut their paychecks and fatten his store's
bottom line."  [Source: *The New York Times* 4 Mar 2004; PGN-ed]
  <http://www.nytimes.com/2004/04/04/national/04WAGE.html?hp>


4.6-million DSL subscribers' data leaked in Japan?

<Chiaki <ishikawa@yk.rim.or.jp>>
Sun, 21 Mar 2004 01:54:11 +0900

By now, the scope of the leak of 4.6 million name has been confirmed.

That is basically Yahoo/BB, the ADSL company operated by SoftBank and the
police sources admitted that the list is part of the genuine current active
users save for the subscribers who have stopped the subscription. SoftBank
kept these names in case some inquiries were made from former subscribers.

Now, regarding the problematic data handling policy, the following is widely
reported in the Japanese press.

Access logs to the data server which held the name of the subscribers were
removed after one week : this makes the tracing of the route via which the
leak was made almost impossible, it seems.  SoftBank claims that it has
lengthened the life of log files now.

There were too many people with authorized access : one account I read in a
magazine stated 135 people could access it inside the company.

Adding insult to the injury, the password and ID pairs for these authorized
personals seemed routinely be handed out whoever "needed" to access the list
at the whim of the moment. That is, only about 40 pairs of account and
password pairs were issued among 135 people.  Now how can anyone reasonably
figure out where the leak was?

Really a good example of what one should NOT do in handling sensitive
information and seeing it at an large ISP is rather disappointing and
disgusting.

Yahoo BB, the ADSL service company decided to send coupon worth 500 YEN
(slight less than 5 dollars) to people whose name was leaked as a
gesture of apology. I have no idea where this 500 YEN figure came from.
It seems to too cheap to me.

One irate customer of Yahoo/BB did quite a striking opinion piece by selling
his "personal information", exactly the info which was believed to be in the
mentioned DVD, on non other than Yahoo auction site.

He started the bid at the same 500 YEN which Yahoo/BB seems to regard it to
be worth, but then after 150 bids, the price went up to more than 1.5
million YEN. I have not followed it and so I don't know if the auction item
was removed from the site since it is "anti-social", etc..

This incidence is a really good example of what we should not do and many
organizations seem to take this example seriously.

In that sense, it is a good thing, but I have no idea what bad things may
happen due to the leaked list.


Pilot study of cybercrime against businesses

<"Michel Kabay" <mkabay@norwich.edu>>
Thu, 1 Apr 2004 21:40:54 -0500

"Cybercrime against Businesses: Pilot Test Results, 2001 Computer Security
Survey" (12 pp.) (NCJ 200639) describes the history, development, and
implementation of the pilot Computer Security Survey conducted during the
last half of 2002.  It provides recommended improvements to be incorporated
in the final questionnaire, which BJS anticipates fielding in FY 2004. (BJS)
[National Criminal Justice Reference Service <http://www.ncjrs.org>, 1 Apr
2004, Vol 10, No 7]  <http://www.ojp.usdoj.gov/bjs/abstract/cb.htm>


Risks of broadband upgrades

<Jeremy Epstein <jeremy.epstein@webmethods.com>>
Fri, 2 Apr 2004 12:40:50 -0500

Cox Communications is currently (8:45am EST 2 Apr 2004) suffering from a
widespread outage among Virginia customers who have Toshiba 1100 series
cable modems.  As best as I've been able to find out from their "support"
people and web page, it was an upgrade gone bad.  The outage at this point
has been 22 hours, and there's no estimate for when it will be fixed.

At this point there are more questions than answers, including:
* Why is this only impacting customers with Toshiba cable modems (which,
  incidentally, is the brand Cox recommends!)
* What specifically did they change that's causing the problem?
* Why is it only impacting Virginia Cox customers?
* Why wasn't there a recovery plan in place before pushing out a change like
  this?

On the positive side, this is an example of where diversity really *does*
make the system more resilient: customers with other brands of cable modems
are (for whatever reason) apparently immune to whatever went wrong.

[For anyone tempted to get useful information from the Cox web page, it
incorrectly claims that the outage started at 7:45pm, when in fact it started
no later than 2pm, and probably earlier than that.]

Update at 12:45amEST: A (purported) Cox representative reported
<http://www.dslreports.com> that "we have an outage on a subset of our
Toshiba cable modems in Northern Virginia. While performing software
upgrades (DOCSIS 1.1) some of our Toshiba PCX1100 modems went off-line and
are not able to come back up. [...] [we have performed this identical
upgrade to many other Toshiba modems in other cities, so we're trying to
determine what was unique in the NOVA case.]"  I haven't gone back and read
the terms of service to see if they have the right to update the software in
a modem that I own....


Too Many Pips!

<"Andrew Watkins" <andrew@newlandsoftware.ltd.uk>>
Thu, 1 Apr 2004 09:51:13 +0100

BBC Radio 4 is the primary news and current-affairs Radio service in the UK.
The Greenwich Time Signal (The Pips) is a sequence of 5 short pips spaced 1
second apart followed by a longer pip, marking the turn of the hour.  This
'official' time check allows people to set their watches accurately.  On
23rd Mar 2004 the pips were heard on air at 12:14:55 and 17:14:55.

According to a source at the BBC, "We generate pips every 15 minutes, and
the Studio Manager has to press a button to select the pips in the 14
minutes before the pips are needed.  In the old Radio 4 studio, once a set
of pips went through, they self-cancelled (unless the SM had put them on a
channel of the desk and faded them up, which they might do for operational
reasons) ... but they don't self-cancel in the new studio.  We seem to have
had two Studio Managers that day who had completely forgotten that they
don't self-cancel.  Sadly, as more and more new systems come on line over
the next year or so, the inability of those designing the systems to
properly evaluate and mitigate the risks and the lack of experience of those
using the systems will inevitably lead to an increase in such errors."

Andrew Watkins, Newland Software ltd. tel: +44 1926 640073 (01926 640073)
<http://www.newlandsoftware.ltd.uk>


Fighting back at spam, viruses, etc.?

<Neil <no.spam.for.n.youngman@ntlworld.com.die.spammers>>
Tue, 30 Mar 2004 17:43:43 +0100

According to esecurityplanet.com, a company called Symbiot is planning to
launch a network security tool offering countermeasures "graduated from
blocking and quarantining to more invasive techniques"

  <http://www.esecurityplanet.com/prodser/article.php/11166_3327391_2>

The article points out may of the risks associated with aggressive
counterattacks.

Also *The Register* claims that a Trojan is being distributed on file
sharing networks, masquerading as pirate software. "The programs have
circulated disguised as activation key generators and cracks for Unreal
Tournament 2004, Pinnacle Studio 9, Norton Antivirus, TurboTax"

  <http://www.theregister.co.uk/content/55/36391.html>

While this Trojan appears not to carry a dangerous payload, there's no doubt
that something like this could be used to carry out some seriously malicious
actions.


Risks of malicious code in MIDI instruments/robots (Re: PGN, R 23 29)

<Kenji Rikitake <kenji.rikitake@acm.org>>
Thu, 1 Apr 2004 20:03:15 +0900

On music-playing robots: the MIDI protocol specification defines System
Exclusives, which allows sending almost any kind of data without any
authentication, directly to the instrument's memory.  Without performing
proper sanitization, any sort of System-Exclusives data can cause unexpected
problems, rhythms, notes, and tunes.  I hope the music-playing robots were
well-protected from such attacks.  [Seems unlikely.  PGN]


Net hoaxes snare fools all year

<Monty Solomon <monty@roscom.com>>
Wed, 31 Mar 2004 23:14:36 -0500

<http://wired.com/news/culture/0,1284,62794,00.html>


Re: Bridge construction mismatch (Knowlton, RISKS-23.29)

<Stephen Poley <sbpoley@xs4all.nl>>
Thu, 01 Apr 2004 15:22:41 +0200

> one half [of the bridge] had been built 54 cm lower than the other

My off-the-cuff reaction to this was to wonder if the problem was caused by
a difference in datum sea-level height between Germany and Switzerland
[calculated at the North Sea and the Mediterranean, respectively] — and to
wonder how civil engineers would fail to think of that.  [See PGN note.]
Well, according to <http://www.kopa.ch/img_upload/az_bruecke.htm>, that was
indeed the cause.  But the difference between Germany and Switzerland is not
54cm, but 27cm!  I don't think I need to spell out the rest to RISKS
readers.

Incidentally the discrepancy is not between the two halves of the bridge,
but between the bridge and the roadway on the German side, so it appears the
bridge itself was (sensibly) all surveyed from the same baseline.

  [Indeed, the engineers had thought of the difference, as it is widely
  known in their community, but unfortunately they corrected it in the
  *wrong* direction, as also noted by Pete Kaiser and Markus Fleck-Graffe.
  PGN]


Re: Bridge construction mismatch (Re: Knowlton, RISKS-23.29)

<"Darryl Smith" <Darryl@radio-active.net.au>>
Thu, 1 Apr 2004 16:33:31 +1000

Unfortunately, this is not as uncommon as it would appear. Here in
Australia, Wallerawang Power Station was built over a period of about 40
years or so using two or three height datums.  They started with the 'A'
station, followed by the 'B' and 'C' stations. Then removed most of the 'A'
and 'B' stations.

The problem was that the original site works were done on the 'A' datum
which was about a meter different from the 'C' datum. This did not matter
until they wanted to build a non-local coal conveyor system to replace
bringing coal in by truck. Some of the design was done for the 'C' datum and
some at the 'A' datum - without the knowledge of the designers.

This was only discovered once construction started, and the resulting
dispute ended up in court.

Darryl Smith, VK2TDS   POBox 169 Ingleburn NSW 2565 Australia
Mobile Number 0412 929 634 [+61 4 12 929 634 International]
www.radio-active.net.au - www.radio-active.net.au\web\tracking


Re: AT&T Alerts Consumers About the Latest Scams (RISKS-23.29)

<"Pekka Pihlajasaari" <pekka@data.co.za>>
Fri, 2 Apr 2004 22:03:14 +0200

This RISK was not at all clear until I recalled that in the United States
many cellular calls are mostly charged to the recipient. In many networks,
GSM included, the caller is charged for the full cost of the call and the
recipients only pay for routing calls while the subscriber is roaming across
networks.

The RISK is assuming that business models and technical constraints are
globally applicable.

Pekka Pihlajasaari, Data Abstraction (Pty) Ltd  pekka@data.co.za


Netsky.P and iframe src=??cid variant

<Rob Slade <rslade@sprint.ca>>
Thu, 25 Mar 2004 12:31:27 -0800

I assume that everyone is, by now, well aware of the Bagle.Q virus that used
an interesting trick to spread a virus via e-mail without an attachment.
Netsky, in its latest incarnation, appears to reverse that in an intriguing
twist.

I have noted, in the past few days, the sudden spurt of Netsky.P messages,
and, simultaneously, queries about messages containing the string "iframe
src=??cid:" in the body.  (In the samples I've got the ?? has been 3D, but I
don't know if this is the same in all cases.)

In the Netsky.P infected messages as they are described in the virus
encyclopedias (I have checked F-Secure and Sophos in detail), the message
carries a standard attachment, in the normal MIME format as:

Content-Type: application/octet-stream;
	name="photo.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="photo.zip"

There are a few twists on this: occasionally the filename has the username
in it, such as document_rslade.zip.  In some cases the filename a multiple
extensions and a large number of spaces, such as:
document.txt                                                                   .exe
which is a fairly obvious attempt to convince people that the attachment is a
harmless text file.  (Netsky, like most other recent e-mail viruses, uses a
wide variety of subject lines and message bodies, and spoofs the "from" line
using addresses harvested from the infected machine.)

From samples I have extracted of the "cid" postings, these messages are a
version of Netsky.P: the executable file is the same size (29,568 bytes) and
a quick look at the internal contents seems to be the same.  F-Prot DOS with
signatures as of 20040321 identifies it as Netsky.P.  The important part of
the internal structure of the message follows the general form:

<BODY bgColor=3D#ffffff>If the message will not displayed automatically,<br>
follow the link to read the delivered message.<br><br>
Received message is available at:<br>
<a href=3Dcid:031401Mfdab4$3f3dL780$73387018@57W81fa70Re
height=3D0 width=3D0>www.sprint.ca/inbox/rslade/read.php?sessionid-1165</a>
<iframe
src=3Dcid:031401Mfdab4$3f3dL780$73387018@57W81fa70Re height=3D0
width=3D0></iframe>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_001B_01C0CA80.6B015D10
Content-Type: audio/x-wav;
	name="message.scr"
Content-Transfer-Encoding: base64
Content-ID:<031401Mfdab4$3f3dL780$73387018@57W81fa70Re>

Note that, in a reverse of the Bagle.Q trick, the URL does not actually
point to an external Web site, but to a subsequent part of the same message.
(In all the samples I have received the filename used is message.scr.)  The
structure of the message appears to use two different known vulnerabilities
in Outlook.  (Given the numbers of Netsky.P that I am receiving, it is
rather depressing to note that vulnerabilities that were known, in general
terms, as far back as 1997, and specifically patched as early as 2001, are
still effective.  People, if you must use MS products, please keep them
patched!)

Because of the use of the iframe vulnerability, users of mailers other than
Outlook may see the message appear in various ways.  In Pegasus (which I
use) the message has no body, but does have a normal attachment.  (In most
viruses that use iframe to directly invoke the attachment, Pegasus doesn't
show any attachment.)

I note that neither the Sophos nor the F-Secure encyclopedias mention this
version of the message.  The Trend advisory does mention the iframe
vulnerability (without giving details) but not the second, and also does not
mention the non-iframe version of the messages.  (Having two radically
different forms of messages appears to be similar to Swen.A and Swen.B, both
of which produce two different types of messages, each of which is somewhat
polymorphic within the version.)

rslade@vcn.bc.ca      slade@victoria.tc.ca      rslade@sun.soci.niu.edu
<http://victoria.tc.ca/techrev>    or    <http://sun.soci.niu.edu/~rslade>


Latest Citibank scam...

<"Cody B." <cody@zone38.net>>
Sat, 27 Mar 2004 13:05:43 -0500

I just received yet another one of those Citibank scams.  Normally my
attitude toward these things is simply one of annoyance, because they use
old tricks that *should* be well-known by now, such as the fact that
anything before an @ sign in the first part of a URL is interpreted as a
username-- but this one was a bit more devious than most of the scams I've
seen so far.

Reminiscent of the PayPal scam reported by Jacob Palme in RISKS 23.13, this
particular scammer eschewed using the username-in-URL trick, and instead
registered a vanity domain name with 'citibank' in it!  Specifically, the
domain was securecitibank.us, which is registered to one Wayne Stanford in
Marina, CA according to a whois lookup.
<http://www.whois.us/whois.cgi?TLD=us&WHOIS_QUERY=securecitibank.us>

Just as in the scam Palme reported, the actual URL used http rather than
https, but gave the appearance of 'security' to the untrained eye because of
the rather deceptive domain name used.

I wasn't fooled, of course, for a number of reasons-- most significant
probably being the fact that I have no Citibank account because they have no
branches in my state-- but I can see how someone who knew a bit less about
the workings of the Internet and who actually had an account with the bank
in question could easily be fooled by such trickery...

Cody "codeman38" Boisclair  cody@zone38.net  <http://www.zone38.net/>


Who's in charge of the e-mail virus war, and are we losing?

<Steve Summit <scs@eskimo.com>>
Thu, 25 Mar 2004 10:54:02 -0500

Three or four big virus outbreaks ago, there was a disturbing
sentence in a Boston Globe article by Hiawatha Bray, along the lines
of, "Clearly, computer experts still don't know how to stop these
outbreaks."  My immediate thought was, "Of course we do!  Don't write
e-mail clients that make it easy to execute untrustworthy, received,
executable content!"  But then I imagined a likely riposte to my
assertion: "Sure, lots of problems can be solved if you're allowed to
go back and rewrite and replace everything, but how can we solve the
problem given the e-mail programs that are out there?"

This imaginary conversation got me to thinking: what is the general
consensus, not just among RISKS readers, but across the computing
industry as a whole, as to the appropriate strategy for dealing with
e-mail viruses?  I'm certainly not alone here in assuming that the best
way, and in fact the only way, of truly eliminating the problem is to
eliminate the e-mail clients — all of them, even if it takes a while --
which do make it easy to execute untrustworthy, received, executable
content.  But lately I'm not so sure that this solution is so self-evident
to the industry at large.

Whenever a new one of these viruses hits, the visible reactions are
always the same: hasty updates to "antivirus" software, new exhortations
to end users not to open suspicious attachments, new ad-hoc rules
implemented in corporate e-mail gateways which block certain potentially-
dangerous filename patterns (also known as "file types") in attachments.
Notice how these responses are all reactive, and dance around the real
problem.

My fear, then, is that the fundamental enabling mechanism for most
of these e-mail viruses — namely, the fact that a user of a popular
graphical e-mail client need only click on an executable attachment to
run it — is being or has already been tacitly reclassified.  I would
have blandly asserted that this aspect of those e-mail clients is and
has always been a bug, but: what if it's now, so help us, an *axiom*?

If the world at large, and those portions of the computer industry that
cater to the world at large, believe that any solution to the virus
problem must be designed around the "fact" that users must be able to
click on executable attachments and have them run, then I'm afraid the
battle is lost.  That assumption concedes a huge and tragically
unnecessary upper hand to the virus writers, an upper hand which is
basically unbeatable.

If this assumption is, in fact, in the process of being ordained,
what can we (who assume otherwise) do about it?

  [If you wish to take Steve's bait and respond, PLEASE send your comments
  directly to him.  He will summarize the responses for RISKS.  TNX.  PGN]


Re: Buffer overflows and Burroughs/Unisys (Hopkins, RISKS-23.24)

<Crispin Cowan <crispin@immunix.com>>
Thu, 04 Mar 2004 17:07:51 -0800

> Heck, software can always make up for hardware deficiencies, right?

That's a perspective, but I disagree. Burroughs was not the only lab to
experiment with language support on chip. Intel also tried this, with the
i432. The result was that the RISC processors produced *crushing*
performance wins over chips with complex semantics, due to the ability to
heavily pipeline and thus ramp up the clock on simple instruction sets.

Thus hardware semantics enforcement ended because the hardware people
discovered that it was easier to do in software.

Continuing this tradition, software semantics enforcement more or less ended
when software people discovered that it was easier to do in marketing :)

[Crispin, in the business of software semantics enforcement]

[To which Bill Hopkins retorted:]
> Hardware semantics enforcement is impossible unless programs have
> enforceable semantics.  C doesn't provide them, so Crispin has a business.

Hey! C provides the semantics of a PDP11 quite well :) C is not a
programming language. C is God's Own Portable Macro Assembler. Never forget
that, and you'll know when it is appropriate to write code in C.

CTO, Immunix <http://immunix.com> <http://immunix.com/~crispin/>

Please report problems with the web pages to the maintainer

x
Top