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 19 Issue 06

Thursday 10 April 1997

Contents

o NY City electronic voting machines: $20 million wasted
Ed Ravin
o YAAXF: Yet Another ActiveX Flaw
David Kennedy
o RISKS of Mail Merge for Ontario Tories
Mich Kabay
o RISK of power of two: 25.6 mm per inch!
Richard Black
o BMW fixes transmission via dialup to car
Nick Zervas
o Re: Generating randomness
Paul C. Kocher
o Programs broken by daylight savings time switch?
Earl Truss
o Re: DECnet time-change
Larry Kilgallen
Jerry Leichter
o Re: Greenwich Mean Time just changed by 1 hour
Jeff Uphoff
o Re: Y2K: revenge of originality
Charlie Shub
o Blue Cross automated SSN update system
Jeremy Epstein
o SSA Web/PEBES and Cross-Matching
John M. Willis
o Re: Social Insecurity
Richard Hollands
o PEBES "security" even weaker than described
D.V. Henkel-Wallace
o Re: Meta-risks of browser flaws
Rob Bailey
o Re: Not a forgery! spamming
Vivek Sadananda Pai
Simson L. Garfinkel
o Info on RISKS (comp.risks)

NY City electronic voting machines: $20 million wasted

Ed Ravin <eravin@panix.com>
Tue, 8 Apr 1997 12:33:44 -0400 (EDT)
The *New York Post* reports on Sunday, April 6, that $20 million has been
spent by New York City on an effort to convert to electronic voting
machines, but the city has received only one prototype voting machine.
Notably missing is the software system (expected to cost another $1 million)
to process the election returns.  The project is now mired in lawsuits
between the city, the primary contractor (Sequoia Pacific Systems), and a
subcontractor (Deloitte & Touche).

The article, by William Sherman, covers quite a bit of ground, including the
history of the voting machine contract and the various milestones of
progress (or, more often, no progress) along the way.  Some of the salient
points are:

* Much of the technology is now outdated, because the project was started
back in 1984, with the specifications developed in 1987.

* The new system will be vulnerable to vote tampering by "computer hackers".
[RISKS readers familiar with this issue of course know that the real source
of vote tampering is not "hackers" but the politicians, poll workers, and
other parties who have access to the voting machines.]

* The hardware (i.e., the voting machine) met only 63 percent of the
"technological and security criteria" set by SRI, the city's consultant for
the specifications of the voting machine and for evaluating the bidders.

* The city rejected Deloitte & Touche's proposal for the voting system
software "citing Deloitte's inability to explain how it works".

* According to the article, each voting machine would use a "digital vote
recorder" and removable cartridges.  The cartridges would be removed from
the voting machines, brought to a district center for uploading (via
fiber-optic lines) to a central computer, then returned to the voting
machines for more voting.  This process would be repeated throughout the
day.

* Although the vendor says that they have 10,000 machines of this type
deployed around the nation, a city official says those systems do not work
when there are more than 1500 voting machines on the same network (as there
would have to be in NY City, with 1250 polling sites and multiple machines
at each site).

My take on the subject is that it is nice to see that there's an evaluation
process going on regarding the software system that all democracy in NY City
may one day depend on.  I prefer my tax money going to waste rather than
buying an unsecure electronic voting system.

This isn't the first time I've heard of this project: I've read complaints
from "good government" groups that the city's planned system did not have
any way to confirm "the computer's" vote totals.  Their concern was that any
well-placed technically-aware politician, Board of Elections employee, or
other rascal could steal the vote, and no one would be the wiser.  It
appears that their concerns have not yet been addressed.  If the new voting
machines really need to have their "cartridges" ferried to and from the
polling site while voting is in progress, that alone raises all sorts of
questions in my mind as to how they can be kept secure.

Ed Ravin  eravin@panix.com


YAAXF: Yet Another ActiveX Flaw

David Kennedy <76702.3557@compuserve.com>
Tue, 8 Apr 1997 18:46:22 -0400
Microsoft's ActiveX has security flaw, Sun says
  Reuters Financial Report  3 Apr 1997
  Courtesy of Reuters News via CompuServe's Executive News Service

> SAN FRANCISCO, Calif., April 3 (Reuter) - Sun Microsystems Inc on Thursday
> demonstrated what it said was a security loophole in Microsoft Corp's
> ActiveX technology, which it said could enable a malicious hacker to break
> into a computer user's private financial files.  Sun showed how when a
> specially written program containing ActiveX was downloaded by a remote
> user, the program then took over the user's computer and rifled its files
> for personal financial information.  [...]

> The demonstration was made during a keynote speech by Sun CEO Scott
> McNealy at the company's JavaOne conference.  [...]  Sun executives said
> they see security as a major issue differentiating Java, which has been
> designed to enable programs to run in a protective "sandbox," and ActiveX,
> for which security has recently become a looming issue.

The demonstration ActiveX control *had* been signed.

Dave Kennedy [CISSP] Research Team Chief, National Computer Security Assoc.


RISKS of Mail Merge for Ontario Tories

"Mich Kabay [NCSA]" <Mich_Kabay@compuserve.com>
Tue, 8 Apr 1997 16:42:02 -0400
The _Globe and Mail_ for 8 Apr 1997 (p. A21) has an article by Robert
Sheppard ("Talk around the clock") that brings out an unexpected consequence
of the availability of mail-merge programs for the legislative process.

Background: the Conservative government of Ontario has been using its strong
majority to pass laws in spite of public opposition to specific bills.  The
latest example is the amalgamation of several established cities in the
metropolitan Toronto area into one giant "megacity" (trivial by US and world
standards but big by Canadian standards).  In the process, about a half
dozen municipal governments are to be abolished.  In a region-wide
referendum on the question of amalgamation, 75% of the voters opposed the
plan.  The Tories flatly stated that they would pass the law anyway.

The opposition parties have hit upon a novel form of filibuster: they are
proposing about 12,000 amendments -- one for every single named street in
metro Toronto -- demanding that any law affecting the residents of that
particular street be subject to local review by those citizens.

The Ontario legislature is procedurally obliged to vote on every single
amendment.  Since it take at least a few minutes to read the amendment, vote
on it, and read the results, the chambre is managing to work through about 4
amendments an hour in 24-hour sittings.  It is estimated that it will take
several weeks to clear the amendments.

So where are the computers in all this?

They are churning out the amendments!  The combination of mail-merge
programs, word-processing packages, and an electronic list of all the
streets in the area has made is physically possible to produce this tidal
wave of amendments.  Were the older methods to have been in use, it would
have been impossible to generate the sheer volume of writ in time to clog
the system.

It's a curious way to run a province.

M.E. Kabay, PhD, CISSP (Kirkland, QC), Director of Education
National Computer Security Association (Carlisle, PA) http://www.ncsa.com

  [It's like a Perl script to annoyster.  PGN]


RISK of power of two: 25.6 mm per inch!

Richard Black <Richard.Black@cl.cam.ac.uk>
Thu, 10 Apr 1997 14:50:52 +0100
We've been printing some labels for CD cases where the label has to fold on
the inside of the case outside of the carrier.  We had observed that the
label always seemed a fraction too small even though we were sure we'd
measured an original correctly. I've just tracked this down to a bug in the
PostScript back end of Tgif (Version 3.0 (patchlevel 12)) where it converts
from internal units (5 per mm) to postscript points (72 per inch).  The code
went:

  72 128 div 100.000 mul 100 div dup neg scale

making 25.6 mm per inch! Sure enough changing the output to

  72 127 div 100.000 mul 100 div dup neg scale

makes things appear the correct size. I guess the RISK is having programmers
who are too used to typing powers of two.

Richard


BMW fixes transmission via dialup to car

Nick Zervas <nickz@radionics.com>
Thu, 10 Apr 1997 14:01:52 -0400
My dad's new Beamer [1996 540i], ya' know, the ultimate driving machine,
turned itself in to the ultimate PITA [pain...], as relayed by my dad: The
automatic tranny locked up in OD after he nailed it, doing the ol' power
downshift that automatics can do.  This left him quite overgeared and
useless from a full stop.  The instrument panel read 'program missing ' or
some such fibbishness. Back at Beamer local, the center-of-gravity guys
found that he had a corrupted or missing tranny 'program'.  The Beamer
system is designed to sense driving habits and adjust shifting patterns
accordingly, storing the 'changes' in firmware.  Apparently, the nailing was
outside dad's established params so the 'program' balked.  They had to
connect the car to Beamer central in Munchen via dialup to download a fresh
program.

NickZ

  [Evidently the extreme parameters resulted in either
  a Variant Beamer or a Bavariant Creamer.  PGN]


Re: Generating randomness (re: Wolff, RISKS-18.94)

Paul C. Kocher <pck@netcom.com>
Thu, 10 Apr 1997 02:12:51 -0700
> Suppose I have a PRNG seeded with a nice and dandy (VERY random) 128
> bit seed.  [...]
> Information theory states that if I know any 128 bits of this stream, I
> theoretically know the whole stream.  In practise you need a few more bits
> to be sure. In practise you can only recover the whole stream if the
> entropy in the original is small enough.

You're right that the amount of real entropy is less than the message size.
In practice this doesn't matter, since strong crypto functions are
available.

The information theoretic argument is more interesting and isn't as
cut-and-dry as they might seem.  I made the (admittedly broad) assumption
that the crypto is strong, leaving brute force as the only way to find the
inital state.

Although some information theory purists might claim that the existence of a
brute force attack makes inversion possible, I don't necessarily agree.  For
example, if the initial state is 1024 bits, the amount of energy required to
perform 2^1024/2 state transitions should exceed the amount available in the
known universe.

Thus, although the attacker may know that the solution is out there, it's
stuck in a cryptographic black hole.

-- Paul

P.S. Please note that I'm slightly playing devil's advocate with the claim
that sufficiently hard problems are impossible :-).  One particularly
interesting challenge to this assertion comes from quantum computing, since
a quantum device might not require a separate state transition for each key
tested.  Anyone care to comment?

Paul Kocher (pck@netcom.com) Crypto consultant  http://www.cryptography.com
Voicemail: +1-(415)-354-8004  FAX: +1-(415)-321-1483


Programs broken by daylight savings time switch?

Earl Truss <etruss@visi.com>
Tue, 08 Apr 1997 07:23:36 -0600
I work in an MIS department.  Yesterday morning, there was a call from a
user about a program not working that she had used on Friday with no
problem.  I ran the program and it told me there was a corrupt file and that
I should make a copy of the original file from the last disk of the
distribution set.  Before doing this, I compared the two files to try to
figure out what might have happened so I could check for any other problems
in other files.  The files were identical.  I then looked at the size and
time stamp of the files.  The only observable difference was that the time
stamp on the file on the hard disk was exactly one hour later than the time
stamp on the file on the diskette.  Being a long-time reader of RISKS, my
suspicions were immediately raised since it was the day after the switch to
daylight savings time.  I ran the two other programs we purchased from the
same software company.  One reported the same type of "corrupt file" error
message with a different file and the the other claimed we were no longer
licensed to run the program from a network server.  I examined the files and
found the same time stamp differences.  I copied the first file off the
diskette as directed and the program again worked.  I then merely changed
the time stamp on the other two affected files and the respective programs
also began working.  The affected files were all on the diskettes which are
different depending on what type of license for the software you have - an
unlimited, network license in our case.  It was obvious to me that their
licensing checks are somehow related to the time stamp on the file.  I
called the company to report my findings.  The person I talked to claimed
that the real problem was that my workstation had a different time from the
server.  I checked and this was not the case as far as I could tell.  I
reported this and the person appeared to be quite miffed that I was
questioning his word.  Since it didn't really matter to me if he didn't want
to know the solution to what was going to be a busy day on the phone for
him, I did not pursue this further with him.  However, I am wondering what
will happen in the fall when we change our clocks again ...


Re: DECnet time-change (Brogden, RISKS-19.05)

"Larry Kilgallen, LJK Software" <KILGALLEN@Eisner.DECUS.Org>
Tue, 08 Apr 1997 08:57:23 -0400 (EDT)
The problem Ian Brogden described was so widely known that some freeware
distributed by Jamie Hanrahan through DECUS (user group) channels was used
at many sites throughout the world (by altering clock frequency rather than
changing the clock all at once).

There is a RISK that such helpful add-on software relieves the pressure on
the original software vendor so as to delay inclusion of a general fix in
the product.  That leaves those who don't hear about the unofficial
workaround out in the cold.

The upside is that the design of the workaround was so widely discussed that
many people outside the original software vendor learned the details of the
problem and how to ensure that their own software would not make the same
mistake which had been in the affected version of DECnet.  (Essentially
there are two ways call for time delays in VMS, one of which would be
affected by a time change.)

The VMS world is currently going through a similar learning experience
regarding those who have imported software from Unix and used certain VMS
date routines without reading their specification.  There will never again
after this year be an opportunity to reach day 10000 after the base-date of
Unix, but there will be many future opportunities to read routine
specifications before using them.

Larry Kilgallen


Re: DECnet time-change (Brogden, RISKS-19.05)

Jerry Leichter <leichter@lrw.com>
Mon, 7 Apr 97 23:15:14 EDT
Ian Brogden reports on a problem which causes DECnet to stall for an hour
when the time back (so this is really a Fall RISK, not a Spring RISK).

This is an old (at least 5-6 years?), known bug, long ago fixed.

To help make sense of some of what Mr. Brogden says, a bit more explanation
of how VMS deals with times may be worthwhile.  The VMS standard time format
is a 64-bit signed integer representing 100 nanosecond "ticks".  A
non-negative value represents an absolute time (since a base date in 1858).
A negative value represents a "delta" time.  The VMS calls that do things
like request a signal when a particular time arrives take a standard time as
an argument.  On the surface, there is no difference between specifying the
absolute time for an hour from now, or specifying a delta time of one hour;
the timer queue stores only absolute times.  However, the kind of time used
in the request is recorded in the timer queue elements.  When the clock time
is reset, the timer queue is traversed.  All queue elements that specified
absolute times are ignored; but all queue elements that specified delta
times are adjusted by the same amount as the system clock is being adjusted.
Hence, the request that specified an alarm an hour from now (at, say, 3:00PM
on a given date) will arrive when the system time is 3:00PM on that date.
On the other hand, the timer request that specified an alarm an hour from
now will arrive when an hour of time has elapsed, whatever the clock then
says.

Finally, VMS records the *local* time of day, daylight or standard; so it
has to be adjusted (these days, automatically and gradually) twice a year.

The bug was the result of mistakenly using an absolute time in a DECnet
timer routine, rather than a delta time.  The fix was, needless to say,
straightforward.

I'm not sure what the RISK really is here, beyond the observation that we've
all made that bugs *will* emerge, even in heavily used and apparently very
reliable code.  (The code, and bug, had been around for years, but was never
noticed - if no one is logged in when the time change occurs, it's unlikely
that there will be any easily identifiable effects to notice the next
morning - well, the next *Monday* morning.  Network protocols, after all,
are designed to be resilient, and to expect errors to occur here and there.
By the way, there was, of course, an corresponding bug that showed up with
the clocks were set forward.  In that case, timers would expire early.  In
practice, this is even *less* noticeable; all you get is an apparent burst
of lost packets, which is no big deal to network software.)

Jerry


Re: Greenwich Mean Time just changed by 1 hour (Wilcoxon, RISKS-18.96)

Jeff Uphoff <juphoff@tarsier.cv.nrao.edu>
08 Apr 1997 16:08:50 -0400
[... Identical situation on my home PC.]

And, true to form, this last weekend (the DST change-over weekend in those
parts of the US that honor it) my dual-boot Linux/Win95 system, running with
the hardware clock set to UT, decided, when I booted Win95 (also configured
to use GMT), that the clock should be bumped up an hour.  I too had left the
"Adjust for DST" box checked thinking "well, GMT doesn't adjust, so it
doesn't matter."

How long have computers been dealing with time zones?  And Microsoft still
hasn't figured out exactly what GMT--the easiest of the lot to deal
with--is?

Jeff Uphoff - Scientific Programming Analyst, National Radio Astronomy
Observatory, Charlottesville, VA, USA   juphoff@nrao.edu juphoff@bofh.org.uk


Re: Y2K: revenge of originality (Rosenthal, RISKS-18.95)

Charlie Shub <cdash@ludell.uccs.edu>
Thu, 10 Apr 1997 08:59:36 -0600
Marvelous, simply marvelous.  Reminds me of the student who, many years ago
in response to a complaint by me about not using meaningful variable names
came up with

A000001                   A0000O3
A000002                   A000O03
A000003  intermixed with  A000OO3
A000004                   A00O003
A000005                   A00O0O3

and this was in the days of IBM 1401 chain printers when it was harder to
differentiate between the letter and digit.

charlie shub   University of Colorado at Colorado Springs cdash@cs.uccs.edu
cdash@cs.colorado.edu  (719) 262-3492  http://www.cs.uccs.edu/~cdash


Blue Cross automated SSN update system

JEREMY EPSTEIN <JEPSTEIN@cordant.com>
Thu, 10 Apr 1997 10:31:25 -0500
Blue Cross has set up an automated system to have subscribers update the
Social Security Numbers (SSNs) of all dependents.  They say this is to meet
the Medicare requirements.  To use the system, the subscriber enters his/her
SSN on a touch-tone phone, followed by the last two digits of the birth year
as a "password".  It then steps through asking for the SSN of each
additional person listed on the account.

Risk #1: Using a birth-year as a password hardly provides any security.
Anyone who has access to my SSN (which is to say, approximately half of the
world ;-) can also get (or guess) my birth-year.  I have no idea how many
tries it allows before locking out.  I haven't experimented to find out how
much harm I can do (i.e., cancel insurance), as I don't want to mess myself
up!

Risk #2: Before this "new & improved" system, I'd get mailed a form every
year to fill out (took about a minute to do).  The new system takes about 10
times as long to use as the old form, although it does reduce Blue Cross'
expenses in processing the data.  That's in part because it spells out each
person's name and slowly reads each SSN to make sure it's correct.  The risk
is that as we automate systems, we sometimes forget that automation does not
automatically equal efficiency.


SSA Web/PEBES and Cross-Matching (Re: Social Insecurity, RISKS-19.05)

"John M. Willis" <jwillis2@mindspring.com>
Thu, 10 Apr 1997 06:17:47 -0500
I understand the difference between how earnings requests were handled
without the Web interface.  With e-mail requests at least there was a
physical address available for law enforcement agents to help find
perpetrators of crimes.  With written requests, maybe they were retained and
forged signatures could be used as evidence.

According to *USA Today* (AP 8 Apr 1997) Paul Gambino, a spokesman for the
SSA stated that "auditors can trace the origin of a request back to the
exact personal computer used to make it."

My questions are:

How many information brokers have run a cross-match between marriage
license, birth and credit databases to get the information required by the
PEBES Web form?

How many people downloaded all that information because it was all based on
"public information"?

How many thieves or foreign powers spoofed their IP address or DNS when they
downloaded this information?  Router intercept and impersonation?

How does Mr. Gambino propose to identify these individuals?  Can I demand to
know every IP address that requested my earnings statement?  And how does
DHCP and other dynamic forms of IP addressing affect investigations?  Oh,
and what is the physical address of the requestor?

There are conflicting reports about volume of requests.  Some sources same
volume increased 28 times (CNN), some say it went up from 3000 to 8500
requests per day (AP). Another says it went up from 3000 to 85000 requests
per day (REUTERS).  One SSA district manager reported that his office could
not access their internal PEBES system due to the volume.  Looks like 28
times is close.

How much of this volume was automated cross-matching?  85000 requests per day?

  [Late breaking news: In response to cries of alarm, the Social Security
  Administration has apparently withdrawn PEBES at http://www.ssa.gov
  from public view, at least for the time being.  It's hard to tell,
  because with the flood of traffic generated by the various postings and
  news articles, no one seems to have been getting through anyway.  PGN]


Re: Social Insecurity (Garfinkel, RISKS-19.05)

Richard Hollands <Richard.Hollands@mgre.com>
Tue, 08 Apr 1997 15:30:43 +0100
There's a certain enthusiasm among genealogy buffs for putting their family
trees on their websites.  Presumably this constitutes a security exposure
that such people should be aware of?

Richard Hollands  Richard.Hollands@mgre.com

  [As noted previously in RISKS, your mother's maiden name is on
  your birth certificate, which is also public record information.  PGN]


PEBES "security" even weaker than described (Re: RISKS-19.05)

D.V. Henkel-Wallace <gumby@cygnus.com>
Tue, 8 Apr 1997 10:48:12 -0700
USA Social Security numbers encode the state the US-citizen recipient was
living in at the time the number was issued (aliens get a special code).
Thus the "state of birth" is likely actually the encoded issuing state.

  [This has been true in the past.  But numbers have been reused for some
  years now.  Who knows whether the state code is still consistent?  PGN]


Re: Meta-risks of browser flaws (Healy, RISKS-19.02)

Rob Bailey <wm8s@pobox.com>
Thu, 10 Apr 1997 16:34:34 -0400
It seems LYCOS has found their own way to alleviate people's fears about Web
security: their Web page at http://www.lycos.com/software.html seems to me
at least to border on lying about what "certificates" really are.  Instead
of telling users that they're a security tool used to weed out completely
un-sponsored code, Lycos implies nothing of the sort, saying only:

    The Microsoft browser supports certificates which add features
                                                ^^^^^^^^^^^^^^^^^^
    to your browser. Lycos has prepared a certificate which will allow
    ^^^^^^^^^^^^^^^
    you to search the Internet using Lycos from the address box of the
    browser (where you normally type URLs). To customize your MSIE browser
    now, download the certificate.

Doesn't this seems intentionally misleading? At best, it grossly
over-simplifies what certificates really are, which may lead people to fail
to fully understand the risks of accepting future certificates.

Rob Bailey, wm8s@pobox.com


Re: Not a forgery! spamming (Pai, RISKS-19.05)

Vivek Sadananda Pai <vivek@cs.rice.edu>
Thu, 10 Apr 1997 13:43:40 -0500 (CDT)
Thanks to everyone who made suggestions on how to handle the spammer problem
I was having. For the time being, it seems to have stopped, and I hope it
stays that way. I'd like to summarize some of the suggestions that were made
so that others may benefit from this:

a) use procmail and return every post - I was doing this for a while,
   before the spammer switched domains. That's when I decided to
   contact the postmaster again.

b) use procmail, and return every post to the personal account of the
   postmaster - devious, but likely to get noticed.

c) complain in writing to the University, and ask about their
   guidelines on commercial use of their systems - had the postmaster
   remained uncooperative, this would have been one of the few
   (non-technical) avenues left. Complaining in writing was suggested
   specifically to try to rule out any "filtering" in case the
   postmaster was involved with this spamming.

In any case, it looks like the user was asked to move to a commercial
Internet provider, so this might start up again. I'm still annoyed at the
lack of answers from the postmaster involved, and I'm really surprised that
there seems to have been no disciplinary action involved.

Although the sky does look a little clearer for the time being, there are
dark clouds on the horizon, so to speak - I was cleaning out my mailbox, and
I noticed an old spam message that came through one of the mail-by-Web
sites. It was for an event this same guy's company was promoting, and the
userid was based on the name of the event. If they start using "disposable"
accounts to do their spamming, that will make most of the methods mentioned
above a lot less effective.

However, they are dumb enough to include an 800 number for one of the groups
involved in throwing the party, and judging from the one time I did get a
response at that number, it seems to go to someone's house.  He didn't seem
very pleased about my 3 A.M. call asking him why I was being spammed. ;-)

Vivek


Re: Not a forgery! spamming (Pai, RISKS-19.05)

"Simson L. Garfinkel" <simsong@vineyard.net>
Mon, 7 Apr 1997 22:52:18 -0700
I was really confused to read of Vivek Sadananda Pai's incident with the
postmaster at an university in New York. I have found that sending numerous
e-mail missives to the postmaster alias almost never works. What works is
calling up the school's police department or the president's office.

Food for thought. When being harassed, always use out-of-band channels.

http://www.packet.com/garfinkel

Please report problems with the web pages to the maintainer

Top