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 23 Issue 77

Wednesday 2 March 2005

Contents

Wanna be president of Microsoft?
Geoff Kuenning
Viruses being delivered into mailing lists via BCC:
Nick Rothwell
Remote physical device fingerprinting
Tadayoshi Kohno
Re: BofA loses backup tapes in transit ...
Terry Harris
Keith F. Lynch
Chris Kantarjiev
Re: UK gets official virus alert site
David Alexander
Re: Spam-blocker causes missed court date
Keith F. Lynch
Craig A. Finseth
Re: Address coercion
John Harper
Russell C Page
Re: Component Architecture
Martin Ward
Mike Ellims
Components, yes; kitchen sinks, no
Walter Dnes
Info on RISKS (comp.risks)

Wanna be president of Microsoft?

<Geoff Kuenning <geoff@cs.hmc.edu>>
26 Feb 2005 19:21:02 +0100

This is too good to be true, but I'm afraid it is.

I own a tiny (just me) California corporation.  Every year, I have to file a
form listing my address, the names of the top officers, etc.  It turns out
that the form can be filed online (though you have to enable Java to do so).

If you go to https://businessfilings.ss.ca.gov you can type in the name of
any corporation registered in California and be presented with the
corporate-info form.  If you type "Microsoft", you'll get several with MS in
the name, including one that's located at One Microsoft Way, Redmond, WA.

Keep clicking and you can fill out the form with "corrected" information.
It costs a $25 filing fee, which can be paid with a credit card.  They also
collect an e-mail address, though I don't know why.  So if you have a stolen
credit card and a throwaway e-mail address (e.g., at mailinator.com or just
good ol' hotmail), you can change Microsoft's information.

For MS, it would probably get caught fairly quickly.  But you could cause a
lot of trouble for a smaller company.  For example, maybe you could change
their information, then sue them.  Not knowing about the suit, they'd
default.  Then you could change the information back and institute
proceedings to collect the judgment.

Hmmm, I wonder if I could sue Bill for a couple of billion?  -- Geoff
Kuenning geoff@cs.hmc.edu http://www.cs.hmc.edu/~geoff/


Viruses being delivered into mailing lists via BCC:

<Nick Rothwell <nick@cassiel.com>>
27 Feb 2005 18:51:29 -0000

I've just been rather shafted by this one...

I have a publicity mailing list, which I maintain as a local alias in qmail
on my mail box. I send out periodic mailshots, to myself as main recipient,
but BCC:'d to the mailing list, for brevity and privacy.

Well, apparently not. Either the EMACS mail system, or the qmail delivery
system (probably the latter) drops the supposedly private BCC: address into
a Delivered-To: header, visible to all recipients.

And in a bad-goes-to-worse scenario, this alias address has found its way
into an e-mail list currently being used by a virus on a compromised
broadband machine on Bellsouth, so it's managed to send its payload to my
entire mailing list. (And, of course, the virus does indeed come through,
and depart from, my mail machine.)

I've now nuked all my supposedly private mailing list names, and will use
completely transient ones in future, but this is something of a wake-up call
to my assumptions about secret mail headers.

nick rothwell -- composition, systems, performance -- http://www.cassiel.com


Remote physical device fingerprinting

<Tadayoshi Kohno <tkohno@cs.ucsd.edu>>
Tue, 01 Mar 2005 14:13:51 -0800

Together with Andre Broido and kc claffy from CAIDA, I have been working on
methods for remote physical device fingerprinting, or remotely
fingerprinting a physical device without any modification to or known
cooperation from the fingerprintee.  At a high level, our fingerprinting
techniques exploit microscopic deviations in device hardware: clock skews.
At a low level, our preferred technique exploits the fact that most modern
TCP stacks implement the TCP Timestamps Option (RFC 1323).  When this option
is enabled, outgoing TCPs packets leak information about the sender's clock.
This work further supports the following well-known observation: there can
be security relevant information in what one might traditionally consider to
be noise.

Our paper and abstract available here:
  <http://www.cse.ucsd.edu/users/tkohno/papers/PDF/>
  <http://www.caida.org/outreach/papers/2005/fingerprinting/>


Re: BofA loses backup tapes in transit ... (Plum, RISKS-23.76)

<"Harris, Terry" <terry.harris@eds.com>>
Tue, 1 Mar 2005 14:51:02 -0500

From my reading of the story, Mr. Plum seems to have jumped to some
conclusions.  One, I didn't see any mention that the data was not encrypted.
Two, the tapes seem to have been shipped as cargo, not in someone's baggage.
There was a specific statement that the tapes were being shipped to a backup
data center.  Something normal for disaster recovery planning.

Considering that the tapes contained data about government officials and at
least one Congressman the theft may have been part of someone's "Opposition
Research".

  [But if it was encrypted, why the BofA statement that no misuse of the
  data is known to have occurred (yet)?  Why not say that the data was
  encrypted, and therefore this was no big deal?  PGN]


Re: BofA loses backup tapes in transit ... (Plum, RISKS-23.76)

<"Keith F. Lynch" <kfl@KeithLynch.net>>
Mon, 28 Feb 2005 22:50:47 -0500 (EST)

Why not always have TSA inspect the bags in the presence of the owner,
who is then allowed to lock them?

> Failure to encrypt these backups before they went offsite seems
> negligent of BofA to me.

Perhaps.  But this is a minor transgression compared to the ChoicePoint
issue.  ChoicePoint deliberately sold personal information that didn't
belong to them, without the permission of its owners.  The fact that the
buyers weren't who ChoicePoint thought they were is a side issue.

If I somehow learned private information about you, and sold it without your
permission, you ought to be more upset at me than if you had given me
private information, a copy of which was then stolen from me.


<Chris Kantarjiev <cak+news@dimebank.com>>
Mon, 28 Feb 2005 17:31:26 -0800

> The "TSA [master] key" lock idea will just mean the thieving baggage
> handler will acquire one of the master keys beforehand.

Or not even bother. I have already had two TSA master key locks removed
destructively.

I view the TSA master key idea as nothing more than a scam to sell new
locks. It has nothing whatsoever to do with security or fighting terrorism.


Re: UK gets official virus alert site (Skedgell, RISKS-23.76)

<David Alexander <dave_ale@online.rednet.co.uk>>
Tue, 01 Mar 2005 15:01:24 +0000

I would like to comment on the remarks made so far concerning the UK ITsafe
web site. It so happens that I know the guy responsible for planning and
implementing the site on behalf of HM Government and we had a long
conversation about it the week before it went live at the DIPCOG conference
in Leeds.

The first and most important thing to note is that this site is aimed at
people who have absolutely zero knowledge of technology, risks or security.
At the risk of sounding patronizing, those who are complete IT novices
(e.g. someone who may well have just bought their first ever computer and
plugged it into the phone line) are the ones the site is set up to benefit.
It is, IMHO, important to view the message that the site carries and the way
in which it does so from the viewpoint of those people, not the informed
position we have as Infosec/IT/risk management/whatever professionals. Those
with knowledge look at bugtraq, CERT, WARPs, a/v provider alerts, etc, the
general public does not - and most probably wouldn't understand the output
and what to do with it if they had it.

The designer had to balance a whole set of risks - if it's too secure or
complex the target audience either won't be able to access it or won't
understand it and will just go away again. If you know how to use S/MIME or
PGP signatures you are too knowledgeable to benefit from the ITsafe site.

The issue of hacking/spoofing has been considered and they have some plans.
My friend was, quite rightly, somewhat reticent to reveal them...

 >> 1. This would be a great site for the Malware Brigade to spoof. I hope
 >> that it is more secure than most Web Sites.
 >
 >Sadly, no:
 >
 >Signing up for e-mail or SMS alerts does not appear to require any
 >address confirmation, so presumably anyone can sign up anyone else's
 >e-mail address or mobile phone for alerts. Also, no secure (SSL/TLS)
 >form is provided for submission.
 >
 >I am also dubious about the 'ITsafe Word' scheme to protect from spoofing by
 >the 'Malware Brigade' -- http://www.itsafe.gov.uk/glossary/itsafeword.html
 >definition: A security feature used on the ITsafe website to help reduce the
 >risk of someone spoofing our e-mails.
 >
 > When you sign up to our e-mail service you are asked to type in an ITsafe
 > Word (please keep this clean). This is not a password, so if you forget
 > it, it is not the end of the world. You just need to be able to recognise
 > it again in the future.
 >
 > All e-mails we send to you will use this word in the 'subject' line. In
 > e-mail programs this is normally displayed just above the e-mail
 > content. You can quickly check that the e-mail has come from us as someone
 > else would not know your ITsafe Word.
 >
 > Until you forward the e-mail, forgetting to remove it (not that it mentions
 > that people *should* do this on forwarding etc). Or post it to USENET, or...
 >
 > I wonder if they have heard of S/MIME or PGP signatures?
 >
 > The problem here is that quite a lot of people will probably receive this as
 > a forward, all malware would need to do is search mail folders for a
 > legitimate bulletin (identified from mail headers) with the ITsafe Word in
 > the subject line and use this to construct a forgery to attach itself to...
 >
 > ITsafe site URL http://www.itsafe.gov.uk/index.html

David Alexander, Towcester, Northamptonshire, England
http://home.rednet.co.uk/homepages/dave_ale/dave_ale.html


Re: Spam-blocker causes missed court date (Brennan, RISKS-23.76)

<"Keith F. Lynch" <kfl@KeithLynch.net>>
Mon, 28 Feb 2005 23:07:58 -0500 (EST)

> ... I would be very surprised to be held responsible for failing to read a
> message that was properly refused.

Really?  I had thought that bounce messages were pretty much obsolete.  I am
forced to killfile all bounce messages directed at me, since the vast
majority of them report bounces of spams forged to be from me.

Not only has it long been the cast that the vast majority of e-mail directed
at me is spam (or viruses, worms, bogus bounces, and other junk), but it's
also long been the case that the vast majority of e-mail that appears to be
*from* me is spam.  I believe that same is true of most people with
non-secret e-mail addresses.  Spammers harvest addresses for *two* reasons --
to get addresses to spam, and to get addresses to forge.

Over a year ago I gave up on filtering, and started whitelisting.  Everyone
with whom I've exchanged e-mail or newsgroup postings is on my whitelist, as
are all the regular RISKS posters, and about eleven thousand other people.
I also have a disposable e-mail address on my web page which anyone can send
to.  And I've borrowed PGN's trick of accepting anything with "notsp" (or
any of a few hundred other key words and phrases) on the subject line.  This
has reduced the volume of spam to a tolerable level, but it *still* exceeds
all legitimate e-mail.

The real RISK here is assuming that e-mail is reliable.  I never assume
anyone has received my e-mail unless they tell me they have.  Why are courts
relying on it?  I thought they didn't even rely on snail mail, other than
*registered* snail mail.

Also, the lawyer in question should have whitelisted the court, and anyone
else he had business dealings with.  There's plenty of blame to go around.

What next?  Being served papers, not by a process server, but by e-mail?  "If
you do not reply to this e-mail, we will assume you have no objection to the
court awarding the plaintiff everything you own and everything you will ever
earn".  Sigh.


Re: Spam-blocker causes missed court date (Brennan, RISKS-23.76)

<"Craig A. Finseth" <news@finseth.com>>
01 Mar 2005 14:54:14 GMT

>One would conclude from this that the law firm had unmonitored software that
>was throwing away mail willy-nilly.  Or perhaps that the law firm's system
>administrator configured it to do so.  Both are serious charges that are
>likely to cause fear and doubt among users of e-mail systems.  It is unlikely
>that either is true.

On the contrary, both possibilities are quite likely.

>I submit to the court that the most likely facts are that the filter sorted
>the court notice into a possibly-spam folder and that the lawyer failed to
>look at the folder regularly.

This is certainly a possibility.  However, anti-spam software has
improved to the point where there are very few false positives and so
many users don't even bother to review their "possible spam" folders.

>The next most likely case is the one I find the most disturbing: that the
>law firm's system refused the message (smtp 550) or accepted it and mailed a
>bounce notice back.  But if this happened, why would the court issue the
>show-cause order?

In my experience (operating an anti-spam system with over 50,000 users), the
most likely causes are mis-configured sending mail systems and accidental
problems.

Many sending mail systems do not follow modern standards regarding things
like being properly configured in the DNS, having the "From" address match
the sending system, or even following the RFCs that specify how to format
messages.  If I were investigating the problem, I would look closely at how
the court system's mail server was configured.

Accidental problems include things like having a document include innocent
words or abbreviations that trigger spam scores.  For example, reports
including "cumulative grade point averages" which abbreviate words to, say,
their first three letters.  If I were investigating the problem, I would
also look for problems of that sort.

[...] I suggest that you may need to revise your expectations about e-mail.
Roughly 2/3 of all incoming messages to our system are spam or viruses and
neither should receive bounce messages.  In fact, if we were to send bounce
messages about viruses, we would be soundly trounced for the practice.

And, as you should be well aware, sending bounce messages to spammers simply
causes them to send you more spam.

Finally, even if I were to send a bounce message, the court's system would
probably classify _it_ as spam and the judge would never see the bounce.

The only reasonable assumption these days is that the message did _not_ make
it unless you have received confirmation that it did.

>By the laws of wishful thinking I assume that the court does not ignore its
>bounces, and that the law firm's system does not throw away mail without
>notice.  Therefore the court was in error.  Unfortunately the filter
>software is not a person under law and cannot file for damages!

Both laws are indeed wishful thinking.  The court's e-mail system probably
classifies bounces as spam and discards them.  The law firm's system throws
away lots of mail without notice.

The error is the court's in assuming that sending an e-mail message and not
receiving a failure notice means that the message has been delivered.  That
assumption is not a reasonable or valid one in today's world.
Unfortunately.

Craig A. Finseth, Firwood Consulting, Inc., 1343 Lafond, St Paul MN 55104
http://www.firwood.net  +1 651 644 4027


Re: Address coercion (P.D.Smith, RISKS-23.76)

<John Harper <John.Harper@mcs.vuw.ac.nz>>
Wed, 2 Mar 2005 09:56:09 +1300 (NZDT)

Paul Smith reported a US bank refusing to believe an address in Enfield,
UK. I used to have a US bank account; its web page was useless because it
insisted that one give a 5-digit zip code. New Zealand and Australia have
4-digit ones, Canada and UK have 6 or more characters in a mixture of
letters and digits, ...

John Harper, School of Mathematics, Statistics and Computer Science,
Victoria University, PO Box 600, Wellington 6001, New Zealand (+64)(4)463 5341


Re: Address coercion (P.D.Smith, RISKS-23.76)

<Russell_C_Page@national.com.au>
Tue, 1 Mar 2005 16:20:15 +1100

A few years back I tried to buy something from a website in the USA from
New Zealand. New Zealand has a population of 4 million, and is about the
same size as the UK. There are no Post Codes, zip codes, provinces, or
states. Presumably the situation is similar in other small countries.

The website refused to recognize an address without a zip code and state,
although it did allow me to live in another country. I sent an e-mail to the
webmaster and the problem was fixed the next day.

Our nations with their boundaries, laws, and armies are legacies of the
kingdoms of medieval Europe. Credit cards, global corporations, and the
Internet are making them more and more irrelevant. If you want to do
business on the Internet, you have to be able to cater for all your
customers.

Security Services National Australia Bank Limited +61 3 9886 2401


Re: Component Architecture (Taylor, RISKS-23.76)

<Martin Ward <Martin.Ward@durham.ac.uk>>
Tue, 1 Mar 2005 10:42:25 +0000

  [This thread is now running thin, so this issue may end it for now.
  But it is a very important topic, and for that reason I let it run
  a little longer than usual.  PGN]

Steve Taylor <steve.taylor@PETARDSCS.CO.UK> notes the fundamental fallacy in
comparing the "design" of software with the "manufacture" of physical
items. Software "manufacture" is practically cost free, while in physical
engineering cost is dominated by manufacturing.

So the real comparison is between *design* of software and the *design* of
complex physical artifacts: such as a suspension bridge, a CPU or a
kitchen. When I design a kitchen I draw out the room to scale on a piece of
paper, make cardboard cutouts of the various items, and then try out various
arrangements. I abstract away almost everything about a cooker, say, apart
from its (scale) size and power requirements. By using a language at the
appropriate level of abstraction (cardboard cutouts and paper), the design
process is simple and effective.

The CPU designer doesn't personally lay out the location of every gate and
wire: he uses the appropriate high level abstractions and the CAD software
fills in all the details: ensuring that all the constraints on wire
separation and length are preserved automatically.

The suspension bridge designer uses the appropriate mathematics to *prove*
that her bridge will stay up and carry the required load before construction
is started. Jan Vorbrüggen points out that physical systems are dampened, or
can be designed to be dampened, so that a small change in initial state
results in a small change in output: while computer systems are strongly
chaotic. On the other hand, the mathematics required to design physical
systems (differential equations, nonlinear fluid dynamics etc. etc.) is
fairly heavy going, while the mathematics required to *prove* the
correctness of a computer program (basic set theory and logic) is
comparatively straightforward. Proofs of correctness of programs are
possible when the programs are small enough and written at an appropriate
level of abstraction.

The biggest advances in programmer productivity (discounting advances in
hardware due to Moore's Law) came with the switch from machine code to
assembler language and again with the switch from assembler to high level
languages.  The next order of magnitude advance will *not* come from using
component libraries in existing OO languages, such as C++ or Java. Instead,
what is required are languages at a higher level of abstraction, and this
necessarily implies domain-specific languages, which have been designed and
implemented with the appropriate formal methods, with the primary aim of
enabling correctness proofs to be carried out.  Why do we still have buffer
overflows and dangling pointers when languages exist in which it is
impossible to implement a buffer overflow or a dangling pointer?

Unfortunately, there has been very little work over the last 20 years on the
design and implementation of very high level domain specific language based
on formal methods and correctness proofs.

I believe that the way to gain higher productivity and reliability in large
software development projects is to turn the large development project into
two much smaller development projects:

(1) Design and implementation of a domain specific language in which it is
    easy to develop the required system; and
(2) Develop the system in the language designed in step (1).

If the language is released as free software, then the work involved in
project (1) can be shared among all the designers working in a particular
domain: and the cost savings are even greater!

The design and development of the FermaT program transformation system
follows this approach. FermaT is implemented in MetaWSL, a language for
writing program transformations. 54,000 lines of MetaWSL compiles into nealy
200,000 lines of C: but the MetaWSL is easy to understand (for one familiar
with the domain), while the C is impenetrable!

These ideas are explored in more detail in my paper "Language Oriented
Programming", Software---Concepts and Tools Vol 15, pp 147-162, 1994
http://www.dur.ac.uk/martin.ward/martin/papers/middle-out-t.ps.gz

Martin.Ward@durham.ac.uk http://www.cse.dmu.ac.uk/~mward/ Erdos number: 4


Re: Component Architecture

<Mike Ellims <mike.ellims@pitechnology.com>>
Tue, 1 Mar 2005 15:25:22 -0000

The reliability of components has always been somewhat suspect, for example
the Basilica project [1] tested various POSIX compliant O/S and found that
large numbers of the system calls and library routines contained bugs that
would cause core dumps. The faults being mostly connected null pointers
being passed as parameters etc.

Things don't seem to be that much better in the open source world either,
Torkar et al. [2] performed unit testing on a number of open source classes
and found that they could trigger errors with minimal effort.

The situation doesn't seem to be any better with other sources, Kuhn [3]
surveyed results for the number of variables required to trigger a failure
and found that for medical devices approx. 70% of failures involved only one
variable, NASA's Deep Space One craft did little better but the Mozilla and
Apache open source projects came in at 30-40%. Of course that could be
because of inadequate error reporting.

This is of course slightly annoying given that Duran and Ntafos [4] observed
nearly 20 years ago that the bugs they were finding could have been found
with *any* sort of reasonable test process.

Of course the problems is worse that this because the majority of the
studies cited above examined functions more or less in isolation and as
Peter Ladkin is fond of pointing out safety is not composable, and I suspect
neither is the use of components in a software systems. That is, just
because the components all work perfectly on there own I'm note sure that it
is realistic to assume that this will produce a reliable system though I
suspect that it may help.

However it does seem to be possible to build reliable software, as noted by
Ladkin (RISKS-23.37 after [5]) automotive software seems to be highly
reliable a similar conclusions are reached by Littlewood [6] and McDermid
[7] at lower levels using the same data. However it should be noted that the
data is from the 1998-2001 period and the analysis has not yet been repeated
for newer vehicles.

[1] Koopman, DeVale : Comparing the Robustness of POSIX Operating Systems,
    FTCS 1999
[2] Torkar et al. : An exploratory study of component reliability using unit
    testing. Proc. ISSRE'03.
[3] Kuhn et al. : Software fault interactions and implications for software
    testing, IEEE TSE Vol. 30 No. 6, June 2004
[4] Duran, Ntafos : An evaluation of random testing IEEE TSE Vol. 10 No. 4
    July 1986
[5] Ellims : On Wheels, Nuts and Software, 9th Australian Workshop on Safety
    Related Programmable Systems SCS'04
[6] Littlewood, Assessing the dependability of software based systems: the
    important role of confidence, KKIO2004, Gdansk, Poland.
[7] McDermid, Kelly : Software in Safety Critical Systems: Achievement and
    Prediction, Proc. Institution of Nuclear Engineers Conference, 2004 (to
    appear)

Mike Ellims, Chief Engineer, Pi Technology  mike.ellims@pitechnology.com
www.pitechnology.com  +44 (0)1223 441 434


Components, yes; kitchen sinks, no

<"Walter Dnes" <waltdnes@waltdnes.org>>
Tue, 1 Mar 2005 18:21:04 -0500

The theory of component re-use is great.  The implementation often stinks to
the point where roll-your-own is the superior alternative.  My pet peeve is
the combination of...

 a) you can't get individual components, you can only get a huge
    library with zillions of components, even though you need just one or
    two of the routines in the library

 b) There isn't just one humungous library.  Every developer and his
    dog is bringing out their own "superior" library.

perl used to be a "Practical Extraction and Reporting Language".  Now it's
ballooned into something huge, requiring support libraries of its own.
Don't get me wrong, perl is an OK operating system, but it lacks a
lightweight scripting language.

On linux, some programs require perl.  Other programs require python.  Other
programs require PHP.  Some require Gtk 1.x series, while others require Gtk
2.x.  Etc, etc.  So in order to get a full system, you end up loading a ton
of libraries, each of which is huge in its own right.  I started using linux
5 years ago on a beat-up old Pentium Pro with 16 megs of RAM, which had
originally come with Windows95.  Today's full versions of Windows and linux
aren't really comfortable in less than 512 megs, although linux allows one
to drop the GNOME/KDE "Desktop" eye-candy and run with a lightweight window
manager.  How long will it be before we start reminiscing fondly of the days
when "640 megs of RAM was enough for anybody"?

A risk of "component monoculture" is that if a widely used component has a
flaw, everybody's vulnerable, especially if the component handles e-mail for
websites.  This isn't just a Windows problem.  A few years ago it was Matt
Wright's (in)famous formmail perl script that was a spammer's delight.  More
recently, PHP-Nuke has been abused by spammers to flood my inbox.

Walter Dnes <waltdnes@waltdnes.org>

Please report problems with the web pages to the maintainer

Top