The RISKS Digest
Volume 20 Issue 37

Tuesday, 4th May 1999

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

Revisiting the USS Yorktown dead in the water
Mike Martin
Netfill scams 900,000 credit cards
PGN
Australian Securities & Investment Commission's April Foolery
Pauline van Winsen
Re: Bloatware Debate
RA Downes
Jonathan Goldberg
Henry Baker
RA Downes
Interesting results with MapQuest
Matthew Delaney
New risk of ITAR?
David Lesher
Risks of "Discovery" hounds
Russ Cooper
Outdated address books
Robert David Graham
Israeli scientist reports discovery of advance in code breaking
Edupage
Re: CIH virus
Matthew Todd
Re: MS-Outlook 98 risk of mislaying messages in Outlook today
Jedediah Grant
Smart Card Forum Privacy Symposium, 20 May 1999
Donna Farmer
Info on RISKS (comp.risks)

Revisiting the USS Yorktown dead in the water (PGN, RISKS-19.88 ff.)

"Martin, Mike" <mmartin@sbnsw.com.au>
Tue, 4 May 1999 17:26:00 +1000
The RISKS discussion related to a zero-divide in an NT application on a Navy
ship, that crippled the ship for some time.

Scientific American finally caught up with the topic in November 1998
(www.sciam.com/1998/1198issue/1198techbus2.html), although the report added
little new to what has appeared already in RISKS. Then in the March 1999
issue (which I have just received) there is a letter from Harvey McKelvey,
former director of Navy programs for CAE Electronics, the firm which
apparently built the misbehaving application
(www.sciam.com/1999/0399issue/0399letters.html).

McKelvey writes that the failure, "was not the result of any system software
or design deficiency but rather a decision to allow the ship to manipulate
the software to stimulate [sic] machinery casualties for training purposes
and the 'tuning' of propulsion machinery operating parameters. In the usual
shipboard installation, this capability is not allowed."

McKelvey adds that CAE Electronics expressed "serious concern" when this
test was proposed.

So it seems that as long as there are no "machinery casualties", everything
will be fine. Then again, the incident may have provided useful information
to improve system robustness.

Mike Martin <mmartin@sbnsw.com.au>


Netfill scams 900,000 credit cards

"Peter G. Neumann" <neumann@csl.sri.com>
Tue, 4 May 99 8:39:45 PDT
Netfill, which provides access to pornographic Web sites, has apparently
billed something like 900,000 credit-card numbers for services.  Federal
regulators claim that the owner, Kenneth H. Taves, has been squirreling
millions of dollars in offshore banks.  FTC officials have not yet
determined how the numbers were acquired — perhaps he may have used a
"number generating program"!  [Source: *San Francisco Chronicle*, 4 May
1999, A3]


Australian Securities & Investment Commission's April Foolery

Pauline van Winsen <Pauline.van.Winsen@eserv.com.au>
Tue, 4 May 1999 08:38:02 +1000 (EST)
The Australian Securities & Investment Commission created a hoax Web site:
http://www.smbi.com.au on April 1st this year. The site boasted that punters
would triple their money if they invested their money in Millennium Bug
Insurance.  The site attracted $4 million worth of interest from people who
were fooled by the web site. Only a few alerted ASIC that the company didn't
seem legit.  The site was designed to educate the public about the risks of
investing in Internet ventures.

Full Story at:
http://www.theaustralian.com.au/index.asp?URL=/national/4291177.htm

Pauline van Winsen, Senior Technical Consultant      pauline@eserv.com.au
eServ Pty Ltd                 http://www.eserv.com.au/people/pauline.html

  [Ah, yes, the adage seems to be,
  "If it has to do with the Internet,
  it must be worth investing in."  PGN]


Re: Bloatware Debate (Downes, RISKS-20.35)

RA Downes <main@radsoft.net>
Sun, 02 May 1999 16:12:13 +0000
A certain "Johnny" has written to me from Microsoft because of my posting in
RISKS-20.35 about MS bloat. The tone was a thinly disguised threat. In his
opening, "Johnny" stated that the "bloat" of MS RegClean was due no doubt to
having static links. Discussing the sweeping ramifications of such a
statement is unnecessary here. The mind boggles, it is sufficient to
state. The MSVC runtime is a mere 250,000 bytes and in fact is not
statically linked anyway to MS RegClean, AFAIK [as far as I know]. MS
RegClean is an MFC app and will by default use the dynamically linked MFC
libraries. And even if its static code links were an overhead here they
would add but a small fraction of the total bloat, say 40KB at most.

For whatever reason, I decided to download the latest version of MS RegClean
from BHS again and pluck it apart. This is what I found. I have tried - and
it has been difficult - to keep subjective comments out of this report.

Current Status of RegClean Version 4.1a Build 7364.1
====================================================

Image Size (Unzipped and ready to run): 837,632 bytes (818KB)
=============================================================
(Subjective comment removed.)

Import Tables
=============
The import section in the PE header. This gives an indication of just
how (in)effective the use of Bjarne's C++ has been. In this case, the
verdict is: "pretty horrible". A walloping 7,680 bytes are used for the
names of the relocatable Win32 imports. These are the actual names of
the functions (supposedly) called. MS RegClean does not call most of
these functions - they remain because an MFC template was originally
used, most likely borrowed from another application, and it was never
"cleaned". This is corroborated by what is found among the "Windows
resources": over half a dozen standard menus, assorted graphic images,
print preview resources, etc. that have nothing to do with the
application at hand.

Resources
=========
Please understand that resources not only bloat an executable with their
own size, but with additional reference data, in other words the bloat
factor of an unused or bad resource is always somewhat larger than the
size of the bloating resource itself.

Accelerators
============
Sixteen (16) unused accelerators from an MFC template were found: Copy,
New, Open, Print, Save, Paste, "Old Undo", "Old Cut", Help, Context
Help, "Old Copy", "Old Insert", Cut, Undo, Page Up, Page Down. MS
RegClean uses only one accelerator itself, not listed here.

Bitmaps
=======
This was a particularly sorry lot. The main bloat here was a splash
screen bitmap weighing in (no RLE compression of course) at over 150KB.
Further, Ctl32 static library bitmaps were found, meaning MS RegClean is
still linking with the old Ctl32v2 static library which was obsolete
five years ago and which automatically adds another 41KB to the image
size.

Cursors
=======
Six (6) cursors were found, none of which have anything to do with this
application.

Dialogs
=======
A very messy chapter indeed. MS RegClean walks around with eighteen (18)
hidden dialogs, of which only one or at the most two are ever used. The
others are just - you took the words out of my mouth - junk. The
findings (read it and weep):

*) Eleven (11) empty dialogs with the caption "My Page" and the static
text "Todo", all identical, all empty, and of course all unused. This is
a wonder in and of itself.
*) The main "wizard" dialog actually used by the application is left
with comment fields to help the programmers reference the right controls
in their code (subjective comment removed).
*) A "RegClean Options" dialog which AFAIK is never used.
*) A "New (Resource)" dialog, probably a part of the development
process, just stuffed in the stomach at sew-up time and left there for
posterity.
*) A "Printing in Progress" dialog.
*) A "Print Preview" control bar dialog.

Icons
=====
MS RegClean has three icons, all with images of 48x48 in 256 colors (of
course). The funniest thing here is that the authors of MS RegClean have
extracted the default desktop icon from shell32.dll, which is available
at runtime as a resident resource anyway and at no image bloat overhead
at all, and included it in toto in their executable.

Menus
=====
MS RegClean has eight (8) menus, at least half of these are simply junk
left around by the MFC template. Another menu indicates that the authors
of RegClean have in fact worked from an internal Microsoft Registry tool
- rather bloated in itself it seems.

String Table(s)
===============
Actually it need only be one string table, but Microsoft itself has
never learned this. The findings here were atrocious. And you must
remember that strings stored in a string table are stored in Unicode,
which means that their bloat automatically doubles. Further, MS's way of
indexing strings in a string table means a 512 byte header block must be
created for every string grouping, and strings are grouped according to
the high 12 bits of their numerical identifiers (yes they are 16-bit
WORD identifiers). Meaning indiscriminate or random numbering of string
table entries will make an otherwise innocent application literally
explode.

347 (three hundred forty seven, yep, your video driver is not playing
tricks on you) string table entries were found in MS RegClean, including
16 identical string entries with the MS classic "Open this document" as
well as archaic MFC template toggle keys texts which are not used here
(or almost anywhere else today). Most of these strings have - of course
- nothing to do with the application at hand.

Toolbars
========
Toolbars are a funny MS way of looking at glyph bitmaps for use in
toolbar controls. MS RegClean has two - one which may be used by the
application, and one which was part of the original MFC template and
never removed.

Total Accountable Resource Bloat
================================
The total accountable (i.e. what can be directly calculated at this
stage) resource bloat of MS RegClean 4.1a Build 7364.1 is over 360,000
bytes (350KB).

Total Accountable Code Bloat
============================
Harder to estimate, but considering that most of the code is never used,
only part of an MFC template that the authors of MS RegClean lack the
wherewithal to remove, the original estimate of a total necessary image
size of 45KB for the entire application must still stand.

In Conclusion
=============
Bloat is not a technical issue, but verily a way of thinking, a "state
of mind". Its cure is a simple refusal to accept, and a well directed,
resounding "clean up your act and clean up your code!"

PS. Send feedback on RegClean to regclean@microsoft.com

RA Downes, Radsoft Laboratories  http://www.radsoft.net


Re: The Bloatware Debate

<Jonathan_Goldberg@mastercard.com>
Mon, 3 May 1999 16:47:29 -0500
People seem to be talking about this as the result of mental aberrations
common in Redmond.  I think that this misses the point.  Bloated software is
the predictable result of the incentives operating in the software industry.
In part, this is a perfectly rational use of resources.  Code compactness,
like any other desirable engineering outcome, must be traded off against
things such as cost and time to market.  As hardware gets cheaper relative
to programmer time, it is reasonable to use more hardware and less
programming effort.  Microsoft's monopoly exacerbates this tendency.  As
long as they can annoy people into buying their software because there is no
viable alternative (taking into account factors such as training costs,
interoperability, and the Company approved software list), Microsoft faces
the tradeoff of spending their money on compact code or your money on
hardware.  It's not a hard choice.


Re: The Bloatware Debate (Downes, RISKS-19.35)

Henry Baker <hbaker@netcom.com>
Mon, 03 May 1999 15:24:14 -0700
> One of the chief hallmarks of early UNIX was how simple, compact programs
> worked well together....

To better understand bloatware, we may have to look to evolutionary biology.
For example, peacocks have enormous tails and deer have antlers that
certainly can't be explained by the usual 'survival of the fittest' kinds of
arguments.  The prodigious amount of energy required to grow these
appendages has to reduce the animal's ability to run away from danger or
survive an extended lack of food.  Matt Ridley's 1993 book "The Red Queen"
(ISBN 0-14-016772-2) is an outstanding discussion of the new thinking about
such things in the field of biology.

According to a Red Queen type of argument, bloatware will survive _precisely
because it is bloatware_ — the bloat is a kind of 'display' similar to
peacock tails or antlers used to prove the vigor of its creator, as only a
truly vigorous creator could afford to waste the prodigious sums required to
implement gross and useless appendages like 'Clippy'.


Re: Bloatware Debate

RA Downes <main@radsoft.net>
Mon, 03 May 1999 01:46:36 +0000
Bloatware is something we are very sensitized to here. The way we see it,
there is no excuse, because there is no reason.

I personally accepted Brian W. Kernighan's calculations back in the old days
about a 10% bloat with C versus assembler because the rewards were tangible
and far outweighed the bloat: you got largely (according to Steve Johnson
94%) platform independent code, saving countless man-hours of work.

But ever since the popular inception of MS Windows and furthermore MS's MFC
things have been way out of control. This is partly due to C++ and partly,
if not largely, due to MS and their MFC itself. A typical Win16 application
was 5KB, yet the same skeleton if built with the MFC back then was ten times
that size. And Bjarne's words echoed in your ear: "C++ produces no
noticeable overhead versus C." It simply was not so, and never will be so.

With time the MFC overhead has been reduced somewhat, but programmers of
today, raised on OO and C++ as opposed to what others have gone through,
are simply not taught to be conservative and minimalistic.

I received a letter yesterday from someone who had been reading the Risks
Digest, and reported on a party he had attended some years earlier. The
conversation turned inevitably toward software, and he mentioned that he
often must really tweak code to get it compact and fast. Another person at
the party, from you guessed it Redmond Washington, said that was *not* the
way things were done there; she said that if they ever ran into performance
problems, they just "threw more hardware at it."

So there are several issues involved all at once, and AFAIK the only way to
fight this, for stop it we must, is to expose it and make even ordinary end
users understand what it's all about, and perhaps by a concerted effort we
can turn back the tide.

Rick Downes, Radsoft Laboratories  http://www.radsoft.net


Interesting results with MapQuest

Matthew Delaney <delaney@ucs.net>
Mon, 03 May 1999 01:49:46 -0400
I was recently searching for a road in Albany, NY (USA). I went to MapQuest
(www.mapquest.com) as I often do when searching for an address.  I entered,
in the address field, "Route 85" and then Albany and NY in the city and
state fields. Knowing this is an actual road, and having seen it on MapQuest
Albany maps before, I expected MapQuest to locate it. However, it returned
"Address: 85 Rita Ln Albany NY 12211-2321 US."  I repeated this same request
several times, to the same result. Even more interesting, when I started
clicking around the map or changing my zoom level, the top of the map
displays "Your search origin is: Route 85, Albany, NY, US."

Obviously MapQuest is attempting to make a guess on my request, and in this
case, getting it very wrong. Normally if it can not find the address you
request, it tells you so at the top of the map and then normally displays a
city level map. However, in this case, it made no indication that it was
making a guess.

Just because data is returned, it isn't necessarily what you expect it is.

Matthew Delaney <delaney@ucs.net>


New risk of ITAR?

David Lesher <wb8foz@nrk.com>
Sat, 1 May 1999 22:48:35 -0400 (EDT)
 http://www.washingtonpost.com/wp-srv/WPlate/1999-05/01/169l-050199-idx.html

   Serbs Listening In on Pilots:
   Some Attacks Thwarted Because of Allied Jets' Unsecure Radio Gear
   By Dana Priest, *The Washington Post*, 1 May 1999; Page A01

   Yugoslav forces have apparently thwarted some NATO air attacks because
   at times allied pilots speak to each other and to ground-based air
   controllers over open communications systems, according to NATO
   officials and U.S. intelligence reports ...

OOPS!  It seems as if not all NATO members *have* interoperable
voice-encryption gear in their aircraft...

The RISK? Law of Unintended Consequences, maybe? Sometimes suppressing an
export market for 1979 reasons bites you on the backside in 1999...

Can PGPphone work on a CRM-114, maybe?

wb8foz@nrk.com  [v].(301) 56-LINUX


Risks of "Discovery" hounds

Russ <Russ.Cooper@rc.on.ca>
Mon, 3 May 1999 13:44:09 -0400
May 3rd, numerous sources published a link to what they believed was
Microsoft Windows NT 4.0 Service Pack 5. SP5 represents a return to service
packs every 6 months from Microsoft after SP4 took nearly 18 months to get
released.

Unfortunately, for some, it turned out that the publicly accessible file was
actually a Release Candidate version of SP5, and not the Final RTM
version. Microsoft's web release mechanisms are, well, in flux right now and
often take longer than people expect. As such, various components of such a
release are often put in place before others. In this case, the 32MB
self-extracting zip file of the SP RC was likely placed in a public location
to verify, privately, that beta testers could actually access it correctly
via the public site. For such a test, there's no need to ensure the file is
the final RTM, just use what's at hand.

Despite no public acknowledgement from Microsoft, and despite the Windows NT
Downloads Home Page still featuring SP4 as its "featured download", a few,
probably, well intentioned soles started sending notes to various lists and
posting the link on their home page as "SP5 RTM".

Likely an age old risk, the issue of "official" information. As the
moderator of NTBugtraq, I put out a message today telling everyone that the
link was *NOT* the "official" version of SP5 and that they should avoid
it. Downloading the version that was provided via the link would, at least,
mean two copies of a 32MB file needed to be downloaded, and at worst, could
cause serious problems due to its lack of completeness.

At the time of writing, however, Microsoft had made no "official"
announcements...nor should they. They have *NOT* made an "official"
announcement of it being available, so why make an announcement that says as
much.

Whether people chose to listen to my NTBugtraq "official" message on the
subject or not is a matter of trust, but its no more "official" than those
saying SP5 RTM is available, is it.

FYI, whenever Microsoft makes a large download available from the 'net,
backbones tend to suffer due to the huge volume of downloads that
ensues. False messages about the availability of something like SP5 could
lead to spikes in traffic unnecessarily, and other sundry problems. At
least, it compounds the issues surrounding web distribution of large files.

Russ - NTBugtraq moderator


Outdated address books

"Robert David Graham" <rob@netice.com>
Sat, 1 May 1999 20:21:22 -0700
When registering the domain for the startup I work for, I apparently
re-registered an old domain that somebody else let lapse. As a result, I
occasionally get mail destined for people in that old domain.

The majority of such e-mail are actual correspondences because people
haven't updated their address books. To illustrate the RISK, consider the
following e-mail I received:

> Xxxxx,
>
> I'll be away now for 8 weeks and will be having my mail intercepted by
> our receptionist who is the kind of person who would have me sacked for
> the type of mail that I've been receiving lately, so could you please
> not send me any messages until I return.
>
> Also, when mail is sent to a list of people including myself, the mail
> comes into our server as an inbound message failure, and then gets read
> by the receptionist before forwarding. Unfortunately this is what
> happened to the previous message 'ouch!' - hopefully the attachment
> wasn't opened.
>
> cheers,
> Yyyyy

I enjoy contemplating the forged e-mails I could send him (which will get
intercepted by the secretary). Any ideas?

Robert Graham, CTO, Network ICE


Israeli scientist reports discovery of advance in code breaking

Edupage Editors <edupage@franklin.oit.unc.edu>
Mon, 3 May 1999 11:56:16 -0600
Israeli computer scientist Adi Shamir is expected to present a paper
outlining the design of a yet-to-be-built-machine that could quickly
decipher computer generated codes.  Shamir — who represents the 'S' in RSA
encryption design — will present his paper this week at the International
Association for Cryptographic Research in Prague, which begins Monday.
Shamir's idea would combine existing technology into a special task computer
that would make factoring numbers as long as 150 digits much easier.  As a
result, codes accepted as reasonably secure for financial transactions and
government communications would be much easier to decipher.  Researchers say
the machine could be built at a relatively low cost, and that key systems of
512 bits or less (keys of about 140 digits or less) would be vulnerable.
Longer 1,024-bit keys would still be out of reach for Shamir's new machine.
(*The New York Times*, 2 May 1999; Edupage, 3 May 1999)


Re: CIH virus

"Matthew Todd" <matthew@mail.cmb.ac.lk>
Mon, 3 May 1999 13:49:37 +0600
The [Colombo] Sunday Times

http://www.lacnet.org/suntimes/990502/spec.html
http://www.lacnet.org/suntimes/990502/plusm.html#label0
http://www.lacnet.org/suntimes/990502/plusm.html#1LABEL1
http://www.lacnet.org/suntimes/990502/bus2.html#2LABEL2

and Sunday Observer

http://www.lanka.net/lakehouse/1999/05/02/fea33.html

of 2 May 1999 both carry extensive coverage of the impact of the CIH virus,
both in Sri Lanka and the rest of the world.

Some of those affected here include:

Yes FM, where one presenter reported the loss of five years' worth of data.
John Keells Computer Services, where IT Manager of Software Development
Services, Milinda Gunasena, was unaware of the virus and lost over 200 files
and spent all day cleaning the system.
DHL lost 15 computers, Forbes Tea Department three, and NIIT, an Information
Technology firm lost five machines.

The total damage here appears to be far less than in some other countries,
notably South Korea, but this has clearly been a very serious incident
throughout the region.

Although these articles also contain some technical inaccuracies common in
mass media coverage of events such as this, there are also some interesting
rumours/myths which are also originating: "At least four computer vendors
who did not wish to be identified said they suspected the virus originated
from a particular company" meaning it had been released by an anti-virus
software supplier...

Much of the coverage here has highlighted the fact that this virus seems to
have done most of its damage in Asia, and that this is largely due to the
extensive use of pirated software. This is largely due to inadequate
legislation and enforcement — currently in Sri Lanka, the law does not
specifically protect copyright and intellectual property rights in computer
software, and no doubt this is also true in much of the rest of Asia.
However, the problem is not only inadequate legislation. It is possible to
buy a licensed and up to date version of a program here if you have
sufficient money, however, the cost of much of the "standard" software which
everybody wants is very high — this is largely due to the huge profits
which organisations like Microsoft chooses to make — and the fact that many
hardware vendors install software (illegally?) at the point of sale, means
that many users have no idea of the origin or provenance of the software
they use.

Much has also been made in the press here of the lateness of the warnings
put out by the national IT bodies such as CINTEC. The possibility is even
hinted at, and no doubt will meet with some public approval, that the
lateness of the warnings makes anyone who knew about the virus in advance
responsible.

Results (apart from the damage done):

- sales of anti-virus software have soared. Presumably these are all
original disc rather than pirated, and will come with the appropriate
periodic upgrades.

- CINTEC (national IT council) is to establish some form of early warning
section to keep the user community better informed.

Outstanding issues (inter alia)(many no doubt familiar to RISKS readers):

- Giving appropriate warnings in time — the danger of "crying wolf" needs
to be borne in mind. Also the risk of media caused panic should be borne in
mind by any group set up by CINTEC.

- Establishing appropriate legislation and enforcement regarding software
piracy.

- Better education of IT users, not just to purchase anti-virus products,
but to introduce procedures for ensuring they are used and kept up to date.


Re: MS-Outlook 98 risk of mislaying messages in Outlook today

GRANT Jedediah <jgrant@namsa.nato.int>
Mon, 3 May 1999 07:18:25 +0100
    I've also encountered subject item noted in RISKS.  However, it is
possible using the Advanced Find for a user to see the messages dropped on
Outlook Today.  A simple advanced find with no parameters other than to look
for all messages in the users mailbox will reveal the hidden items in
Outlook Today as located in the "Top of Information Store" folder.

J. Grant (jgrant@namsa.nato.int)


Smart Card Forum Privacy Symposium, 20 May 1999

"Donna Farmer" <dfarmer@smartcardforum.org>
Mon, 3 May 1999 14:16:30 -0400
'Enabling Privacy in a Virtual World' 20 May 1999
See http://www.smartcardforum.org or by call (202) 530-5306.

For information about The Smart Card Forum:
Patrick Corman, Corman Communications, (650) 326-9648  patrick@cormancom.com
Nancy MacGregor <nancy@cormancom.com> (415) 643-0766

Please report problems with the web pages to the maintainer

x
Top