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 91

Weds 13 February 2002

Contents

Microsoft C++ feature against buffer overflows itself vulnerable
Gary McGraw
Hole found in Net security program
Bill Hopkins
Security flaw in Sony Vaio computers
Monty Solomon via Dave Farber
Computer controller crane goes wrong
Jeff Jonas
Election risks from lack of randomization
Keith Price
Search engines may give you the wrong e-mail address
Robert Marshall
Hotel Internet access
Christian Holz
"Secure" credit-card transactions with new Amstrad e-mailerplus
Merlyn Kline
Officer calls for refund of 'speeding' fines
Monty Solomon
Risks of the rise of PowerPoint
Andrew Main
Microsoft and English
Toby Gottfried
Re: Bulgarian parliament against weight loss
Valentin Razmov
Bill payer system silently changes payments
Phil Weiss
Social Security Numbers printed on tax envelopes
Steve Klein
Virus writers aren't playing fair
William Colburn
Re: Homograph risks
Merlyn Kline
Survey finds security lax at nonprofits
Audrie Krause
REVIEW: "Zimmerman's Algorithm", S. Andrew Swann
Rob Slade
Info on RISKS (comp.risks)

Microsoft C++ feature against buffer overflows itself vulnerable

<"Gary McGraw" <gem@cigital.com>>
Wed, 13 Feb 2002 12:57:03 -0500

Microsoft added a new security feature to their latest C++ compiler, called
both Visual C++.Net and Visual C++ version 7, that was released 13 Feb 2002.
This security feature is meant to protect potentially vulnerable source code
automatically from some forms of buffer overflow attack.  The protection
afforded by the new feature allows developers to continue to use vulnerable
string functions such as strcpy() as usual and still be "protected" against
some forms of stack smashing.  The new feature is closely based on an
invention of Crispin Cowan's StackGuard and is meant to be used when
creating standard native code (not the new .NET intermediate language,
referred to as "managed code").

Note that the new feature is meant to protect any program compiled with the
"protected" compiler feature.  In other words, the idea is that using this
feature should help developers build more secure software.  However, in its
current form, the Microsoft feature leads to a false sense of security
because it is easily defeated.  An ironic RISK, to be sure.

Microsoft's feature includes the ability to set a "security error handler"
function to be called when a potential attack is underway.  Because of the
way this was implemented, the Microsoft security feature is itself
vulnerable to attack.  An attacker can craft a special-purpose attack
against a "protected" program, defeating the protection mechanism in a
straightforward way.

There are several well known approaches not based on StackGuard that a
compiler-producer might use to defeat buffer overflow attacks.  Microsoft
chose to adopt a weak solution rather than a more robust solution.  This is
a design-level flaw leading to a very serious set of potential attacks
against code compiled with the new compiler.  The Microsoft compiler is thus
in some sense a "vulnerability seeder".

More technical information about the flaw can be found at
http://www.cigital.com/news/mscompiler-tech.html

The flaw was discovered by Chris Ren, a Cigital Labs researcher.  Microsoft
has been alerted to the flaw and plans to address it in future VC releases.

Gary McGraw, Ph.D., CTO, Cigital


Hole found in Net security program

<"Bill Hopkins" <whopkins@wmi.com>>
Fri, 8 Feb 2002 19:18:39 -0500

In case you haven't seen it...  I'm sure you'll hear from others who are
likely more familiar with the product.

 http://www.nytimes.com/aponline/technology/AP-Computer-Security.html

Quick summary: BlackICE Defender and BlackICE Agent have a security hole
involving, yes, buffer overflow.  Once through the firewall, guess who's in
charge?

A download fixes it.


Security flaw in Sony Vaio computers (from Monty Solomon)

<David Farber <dave@farber.net>>
Sat, 26 Jan 2002 17:51:43 -0500

TOKYO: Japan's Sony issued a warning on Thursday after finding a software
problem in a popular range of computers that could expose around 900,000
customers to attacks from hackers.  [...]
  http://www.timesofindia.com/articleshow.asp?art_id=473172674


Computer controller crane goes wrong

<"Jeff Jonas" <jeffj@panix.com>>
Sun, 10 Feb 2002 04:01:49 -0500 (EST)

Jersey City NJ, 16 Jan 2002: A computer controlled/assisted crane got into
an unstable position, requiring the evacuation of nearby apartments for 2
days now.

RISKS follows when airplanes and trains surrender control from people to
computers.  Now add construction cranes.


Election risks from lack of randomization

<Keith Price <price@usc.edu>>
Tue, 12 Feb 2002 11:34:39 -0800 (PST)

At first I did not think it was a computer risk.  I'm still not sure if it
is, but the random order list is computerized.

The Mayoral election (Nov 2001) in Compton, CA was overturned (8 Feb 2002)
because of the random ordering of names on the final ballot.  The local
clerk had not requested a new randomized order from Sacramento, and had used
the same order as in the earlier primary election. The Judge decided that
the 300-vote margin was less than the advantage due to being listed first
rather than second and reversed the counted results.  So, in California they
will count your vote, but your vote may not count.


Search engines may give you the wrong e-mail address

<"Robert Marshall" <robert@chezmarshall.freeserve.co.uk>>
Tue, 12 Feb 2002 13:33:31 +0000

I was searching for the work e-mail address for a friend using google.
Let's say the name was Paul Consultant. Google gave me a hit with the
correct company and the web page was such that his e-mail appeared in
the google summary. So I cut and pasted it directly without having to
visit the company web site. It appeared as PR.Consultant@relations.com.

When the e-mail bounced I investigated and the company web page has the
mail as P.R.Consultant@relations.com, as does google's cache. It looks as if
google is trying to cut down on the synposis by removing redundant '.'s

Unfortunately they aren't always redundant.  Fortunately my e-mail bounced
rather than going to an unrelated recipient.


Hotel Internet access

<Christian Holz <chrish@thewizardry.com>>
Mon, 11 Feb 2002 01:30:18 +0100

I have just found out about an interesting feature of STSN Internet Access,
common at hotels in the New England area. They have little boxes connected
in each room which provide either full-fledged Ethernet access, USB or Modem
connections.

To make it especially easy for users, they re-route packets based on the
service used(!). When I tried to connect to my SMTP server (which uses
SMTP-AUTH to protect against Spamming), I got a message informing me that
the used SMTP server does not provide SMTP-AUTH. After a short heart-attack
that my server has been hacked, I telnetted to my SMTP-Server and I was
connected to STSN's.

The risk: Obvious, if they can re-direct based on the service used, they
could possibly see a lot of passwords by providing proxy-services for common
services. In addition with the hotel-guest information, this could give an
interesting profile of hotel guests. I wonder what information they can get
their hands on if they have this services in Capitol-Hill hotels...

I am using SSH-tunnels from this day onwards...


"Secure" credit-card transactions with new Amstrad e-mailerplus

<"Merlyn Kline" <merlyn@zyweb.com>>
Fri, 8 Feb 2002 15:53:01 -0000

Amstrad (http://www.amstrad.com/) in the UK have announced their new
Internet appliance, the e-mailerplus. Among other features, this includes a
"built in a SMARTCARD reader to enable Secure Credit Card Transactions in
the future". Given that there is no extant standard for this sort of thing,
I wondered how this would work. The answer is quickly found on their web
site:

"The e-mailerplus has all the necessary hardware required to enable this
additional level of security ALREADY BUILT-IN and it is only a matter of
delivering the software code to the machine remotely, which we will do, as
and when it is developed."

"We will be developing software in conjunction with this secure payment
system which will be downloaded automatically to the entire population of
this machine at NO cost to the user."

RISKs readers will no doubt wonder what other code might be downloaded, by
whom, and for what nefarious purposes.


Officer calls for refund of 'speeding' fines

<Monty Solomon <monty@roscom.com>>
Sun, 10 Feb 2002 23:56:39 -0500

HARTFORD - A hearing officer for the state Department of Consumer Protection
recommended yesterday that a New Haven rental car company be ordered to
refund the ''speeding'' fines it levied after tracking customers with
satellites.  Hearing officer Robert H. Brinton Jr. also recommended that
Acme Rent-a-Car be prohibited from fining customers in the future. The
company had used global positioning system satellites to track its cars and
had fined renters $150 each time a car exceeded 79 mph for more than two
minutes.  ...  [Source: Associated Press, 8 Feb 2002]
http://www.boston.com/dailyglobe2/039/metro/Officer_calls_for_refund_of_speeding_fines+.shtml


Risks of the rise of PowerPoint

<zefram@fysh.org (Andrew Main)>
Sun, 10 Feb 2002 23:09:54 +0000

There was an interesting radio program today discussing the influence of the
PowerPoint program on business ("In Business", BBC Radio 4, 2002-02-10
21:30).  One of the presenter's main points was that the use of PowerPoint
has affected the way businesses operate: not only are slides now used so
much that each presentation revolves around its slides, rather than vice
versa, but also apparently PowerPoint now has a Content Wizard, that
provides templates for certain types of presentation.

There were reports of PowerPoint users sticking religiously to the format of
the template, as the canonical way to organise a presentation.  The
PowerPoint developer who was interviewed sounded somewhat embarrassed by the
phenomenon: she said "~we expected people to modify those presentations a
great deal~" (approximate quote).  The main risk here is familiar: users
blindly accepting whatever default the computer provides, without
considering whether it's appropriate (RISKS-7.57, et al.).  In this context,
rather than doing anything sufficiently incorrect to make things obviously
fail, the inappropriate defaults are having a subtle influence on
businessmen's thinking (slides titled "our vision for the future" and so
on).

Really the risk is a more general informational one -- people misunderstanding
the purpose and intent of a piece of information, or often misunderstanding
which source of information is authoritative.  We have the same class of
problem when humans talk to humans -- how many people will call their bank
and ask "please change my address" rather than "please note my change of
address"?  The obvious solutions are also human/informational ones: clearer
thinking about these issues on the part of the receivers of information,
and on the other side clearer labelling of the intent of information.

Andrew Main <zefram@fysh.org>


Microsoft and English

<"Toby Gottfried" <toby6700@earthlink.net>>
Sun, 10 Feb 2002 11:57:39 -0800

In RISKS-21.90, Bear Giles writes about Microsoft "appropriating" the word
"begin" in e-mail messages to denote UUENCODEd text.

  "Microsoft's justification for suggesting a significant change to the
  English language instead of fixing their bug is given as:"

Riding roughshod over some little used trifle like the English language is
not a big deal to an important technology innovator like Microsoft.  They
did just that by naming a major project dot-Net (".Net").  Before that, a
period followed by a capital letter was used to mark a sentence boundary.
Experienced readers of English will note a brief interruption in their
parsing whenever .Net is encountered mid-sentence.  And they will be annoyed
about it.


Re: Bulgarian parliament against weight loss (Larmour, RISKS-21.88)

<Valentin Razmov <valentin@cs.washington.edu>>
Tue, 22 Jan 2002 21:19:22 -0800 (PST)

> weighing scales set into the seat

While the proposed improvement does have its downsides, the alternative
suggestion for using personalized cards would *not* work as it misses the
main point the system is trying to solve (and the biggest problem of the
previous system) - preventing collusion.

(MPs have been known to give their cards to colleagues while absent from the
plenary hall, which creates the danger of passing laws without even having
quorum among voting MPs.)

Cards (whether personalized or not) are capabilities, possibly with some
form of authentication "attached" to defeat theft, but certainly not to
defeat collusion - if I want to give you my card, I could just as well tell
you my secret code for "activating" it.

Hence biometrics come to mind as a form of authentication that prevents
collusion in our case without the need for a designated parliament secretary
looking over MPs' shoulders.

Weighing scales offer a degree of protection at a very low cost. The system
does allow both false positives (non-malicious MPs unable to vote because of
a sudden difference with their established weight) and false negatives
(dishonest MPs casting a vote not only for themselves), and while this does
not guarantee that glitches won't happen, it also makes premeditated malice
somewhat harder to carry out.

Alternative schemes would have their own tradeoffs and it is not immediately
clear if any of them would be any more cost-effective.  (The low-tech
version of MPs standing in line to cast physical ballots every time they
need to vote is about as fool-proof as can get, but not very efficient.)

Valentin

Full disclosure: I am Bulgarian, but I did not know about the new system
until reading the news.


Bill payer system silently changes payments

<Phil Weiss <philsjunkmail@yahoo.com>>
Tue, 22 Jan 2002 21:01:43 -0800 (PST)

I use First Tech Credit Union's (http://www.1sttech.com/) online bill payer
system.  As is typical for many financial institutions, the processor is not
First Tech itself, but instead a company called Princeton ECom
(http://www.princetonecom.com/).

The system works by having the user select a payee, then having the user
enter in the due date for the bill along with the amount.  If the processor
can pay the bill using electronic funds transfer (EFT), the system subtracts
3 days from the date entered and uses that for the day money will be
withdrawn from your account and the payment sent.  If the processor cannot
pay using EFT, it subtracts 8 days from the due date and uses that instead.
It then presents a confirmation page.

I found out recently a couple of risks (in addition to some known ones with
their system).  When my December payment was late, I looked at the status of
the payment and was surprised to see that it had silently been changed to
"check" from "electronic."  Since it had been scheduled 3 days before the
due date but was now sent by check, it arrived several days late.

When I inquired to the credit union they gave me several explanations.  The
processor recently began requiring the account number that is entered for my
mortgage company to be a 10 digit number (0001234567 instead of 1234567).
At the same time the mortgage company changed it's "make checks payable to"
name from Mortage Service Center back to PHH Mortgage Services (they've
switched this several times on me over the years).

They will make that change silently without warning the user if you change
anything about the payee to break the match of your payee info to their list
of EFT payess.  And if they make a change to the payee due to a change in
policy, it will change your payment methods without notifying customers that
they need to update their pending payments.  It isn't really a ris, it's a
certainty of errors.

The risk on my part was assuming the system would work.  Being a software
developer by trade, it's something I shouldn't have assumed.  I've since
changed all the important payments so that the due dates are at least a half a
month ahead of their due date.  If I don't see the money deducted from my
account, I can take substitute action.  (For things like my newspaper
subscription, I don't really care.)


Social Security Numbers printed on tax envelopes

<Steve Klein <steveklein@mac.com>>
Tue, 29 Jan 2002 08:47:37 -0500

The city of Detroit, Michigan has sent out 400,000 income tax forms with
taxpayers' social security numbers printed on the outside of the envelopes.

City officials were unable to explain why the numbers were included on the
forms or how the printer got them.

Ralph Kinney, deputy chief of the Wayne County Sheriff's Department's
High-Tech Crime Unit, said names, addresses and Social Security numbers are
the main targets of identity thieves.

"Social Security is really the key to unlocking a person's credit identity,"
Kinney said. "If that key falls into the wrong person's hand, it makes it a
lot easier for someone to become that person."

Identity theft, a felony in Michigan, is one of the fastest-growing
white-collar crimes, Kinney said.

Dennis Ertzbischoff, a local citizen who was one of those affected said,
"This is the kind of mistake a first-year programming student would make.
This was sheer stupidity. Nobody reviewed the work, and nobody caught it."

(Excerpted and paraphrased from the Detroit Free Press, 2002-01-29.)

Steve Klein, Your Mac Expert, Phone (248) YOUR-MAC-EXPERT (or 248-968-7622)


Virus writers aren't playing fair

<"Schlake ( William Colburn )" <schlake@nmt.edu>>
Mon, 28 Jan 2002 15:53:36 -0700

Today I got a weird e-mail with some inline uuencoded data that had a
filename of www dot myparty dot yahoo dot com.  My Mcafee didn't detect
it as a virus, but it uudecoded into a DOS executable so I was
suspicious.  I sent it off to Mcafee, and they sent me back an EXTRA.DAT
for it.  Then came the real trouble.

I use a milter I wrote (http://www.nmt.edu/~wcolburn/antivirus/) to detect
viruses.  Up until today, it had used error codes to know if a file needed
scanning.  The mail file would be "ripmime"ed, and if the error code was 0
(no error) then it meant that some files were successfully extracted.  If
files were extracted then they needed to be scanned.

This new virus, W32/Myparty (ED), defeated me on several levels.  The virus
wasn't MIME encoded, so ripmime didn't find it.  I added a blind uudecode to
my milter, but it was defeated as well.  The uuencoded virus is "corrupt"
(but it creates some output which runs), so the return code from the
uudecode command indicates (is indistinguishable from) nothing decoded.

In the end, I decided that the best thing to do is to blindly uudecode AND
ripmime AND scan every single message.  As you can imagine, this is a
terrible solution.  The core of the problem stems from the fact that MS
products seem to "be generous in what they accept" (the way all good
software should be written?), and so they don't care that the mail wasn't
MIME encoded, nor that it contained a corrupt file.

The risk is that systems are so complex it is getting increasingly hard to
protect them.  That virus shouldn't propagate because it isn't MIME encoded,
but it does.  That virus shouldn't propagate because it uses a corrupt file
transfer, but it does.  If both things were done on purpose, then the writer
was clever.  I can image that more software writers than myself considered
"garbage" or "corrupt" data as "safe".


Re: Homograph risks (RISKS-21.89)

<"Merlyn Kline" <merlyn@zyweb.com>>
Wed, 30 Jan 2002 09:47:31 -0000

> For example, a Russian "o" and an English "o" look alike ...

The default font chosen by Microsoft for some of their desktops (e.g.,
Windows NT) contains homographs for lowercase L and uppercase i.  I've
suffered from minor problems arising from this and I can imagine bigger
risks.

Worse, the default font used by many of their code editors used to contain
homographs for lowercase L and the number 1. I learnt this the hard way,
staring at broken code that was *obviously* correct! I've long since
acquired the habit of using a non-standard font for code editing so I can't
say whether the latest versions of their fonts still have this problem
(which is presumably inherited from the historical use of lowercase L as the
number 1 on many typewriters).

  [Backwards compatibility is either a pun or an oxymoron.  PGN]


Survey finds security lax at nonprofits

<Audrie Krause <audrie@netaction.org>>
Wed, 30 Jan 2002 11:26:45 -0800

We've just released the results of NetAction's survey of security practices
in nonprofit organizations. I thought it might be of interest to RISKS readers.

Despite the growing importance of computers to nearly every aspect of
nonprofit operations, an online survey of security practices in nonprofit
organizations found substantial room for improvement, especially in
maintaining the security of confidential and/or sensitive files, user work
habits, and disaster planning.

"Nonprofit organizations are just as vulnerable to cyber attacks as
businesses and government agencies," said NetAction executive director
Audrie Krause. "This should be a wake up call to the nonprofit sector:
security needs to be improved."

NetAction's report on the survey results, "Computer Practices in Nonprofit
Organizations," is available at: http://netaction.org/security/.

Many of the respondents acknowledged the need to improve their security
practices. When asked to identify specific security issues their
organization needs to address, about two-thirds of the survey respondents
listed user work habits and disaster planning, about half listed data
backups and encryption, and about one third listed virus protection and
firewalls.

The need to improve the security of confidential and/or sensitive files
(such as personnel records or financial documents) was especially
evident. Only 4% of nonprofit organizations encrypt all sensitive files. Yet
nearly two thirds of the organizations surveyed store sensitive files on
computers connected to a local network, and nearly half store them on
computers connected to the Internet.

Moreover, computer users in nearly one fourth of the organizations that
NetAction surveyed do not routinely lock or shut down their computers when
they are away from their desks, and 80% of the nonprofits indicated that
volunteers, interns, outside consultants and/or temporary staff have access
to office computers.

"Some risks aren't as obvious as others," said Krause. "Most organizations
are aware that they could lose important data if they don't do regular
backups. But they may not realize that when users forget to logoff, a
disgruntled employee could steal confidential information, or a nosy
volunteer could access an organization's personnel records."

NetAction's survey also found that only slightly more than half of the
nonprofit organizations back up their data every day, and only about one
third have a data recovery plan in the event of catastrophic data loss.

The organizations did a somewhat better job of protecting their computers
from viruses. About two-thirds of the organizations updated their anti-virus
software one or more times per month. However, the survey also found that
about two-thirds of the nonprofits use Microsoft's Outlook or Outlook
Express to send and receive e-mail despite the higher risk of an attack by
viruses or worms than with other e-mail clients.

The online survey was conducted between December 19, 2001 and January 20,
2001. Although the results cannot be generalized to the larger nonprofit
community because random sampling techniques were not used, Krause said
nonprofit organizations should find the report useful in assessing their own
computer security practices and identifying practices that need improvement.
[...]

She added, "Security experts were concerned about the vulnerability of
computer systems to cyber attacks long before the horrendous events of
September 11, 2001; the level of concern has only increased since the
terrorist attacks on New York City and the Pentagon.  [...]

NetAction, Audrie Krause, Exec.Dir., 601 Van Ness Ave., No. 631, San Francisco
CA 94102  1-415-775-8674  http://www.netaction.org  audrie@netaction.org


REVIEW: "Zimmerman's Algorithm", S. Andrew Swann

<Rob Slade <rslade@sprint.ca>>
Tue, 12 Feb 2002 07:56:32 -0800

BKZIMALG.RVW   20011126

"Zimmerman's Algorithm", S. Andrew Swann, 2000, 0-88677-865-4
%A   S. Andrew Swann (Steven Swiniarski)
%C   375 Hudson Street, New York, NY   10014
%D   2000
%G   0-88677-865-4
%I   DAW Books Inc.
%P   387 p.
%T   "Zimmerman's Algorithm"

A thriller should have a convoluted plot, but this one has slightly too many
twists and turns for comfort.  It's very difficult to keep track of at least
three sets of bad guys, and by the time the penultimate plot is exposed I
had a hard time caring who was responsible.  Still the action is brisk, and
the writing is lively and interesting.

So is the fact that so much technology in the story is basically correct.
The outcomes are sometimes questionable, such as a computer made with
superconducting materials that physically (and not just electrically)
degrade at room temperature.  But the fact that researchers developing
artificial materials are steadily working towards room temperature
superconductors is true.

The math isn't that bad, either.  There is a slight overemphasis on the need
for primes in encryption systems, but it is interesting to see a recognition
of the controversy over enormous computer generated proofs.

The computer work is a bit weaker.  Genetic algorithms are not terribly well
explained in the computer world in general, so it isn't surprising that the
detail in the book is a bit fuzzy.  The discussion of computer viruses as a
form of artificial life is interesting, as is the view of benignity as a
survival factor, although the idea of masses of undetected viruses hiding
out on the Internet is a bit much.  (I must say, though, that, if you are
going to propose the usual undetectable virus, one that can write operating
systems is a good candidate.)

I would like to know whether the choice of name for the eponymous
mathematician was influenced by PGP.

copyright Robert M. Slade, 2001   BKZIMALG.RVW   20011126
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