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 24 Issue 56

Sunday 4 February 2007

Contents

CastleCops 5-Year Anniversary
Rob Slade
A second site "improves" security
FJ Reinke
Re: There's more to worry about than math libraries
Richard Karpinski
Re: Excel Date Bug
Steve Schafer
R.G. Newbury
Dik Winter
Re: Daylight saving time mess looms
J R Stockton
Re: Super Bowl site hacked
Rob Slade
A.Lizard
Re: The problem of abstractions ...
Jos Buurman
David Cantrell
Tony Finch
Ben Hutchings
Steve Schafer
Ray Blaak
Christopher C. Stacy
Re: Digital cameras converted to weapons
Steve Schafer
Re: Canadian coins containing tiny transmitters
Rob Slade
Re: Windows Vista voice vulnerability
Rob Slade
Info on RISKS (comp.risks)

CastleCops 5-Year Anniversary

<Rob Slade <rMslade@shaw.ca>>
Sat, 03 Feb 2007 14:37:18 -0800

As one involved in malware research, I should note the fifth anniversary of
CastleCops.  (Actually, five years ago it was computercops.biz: it's only
been CastleCops for a couple of years now.)  CastleCops is a company, but
promotes efforts involved in community and communication, primarily aimed at
malware, spam, and phishing.

In regard to phishing, a recent project is Phishing Incident Reporting and
Termination (PIRT, http://wiki.castlecops.com/PIRT).  This project
identifies phishing sites and gets them shut down, as well as providing
information to law enforcement for prosecutions.  It's been running less
than a year, but has already saved an estimated (very conservatively) U$22
million in prevented losses.  (Anybody who wants to can submit phishing
messages that you receive or URLs you identify to the project.)

To find out more about CastleCops you can visit www.CastleCops.com, or
de.CastleCops.com if you Speak German, or wiki.CastleCops.com if you are
into Wikis.

For their fifth anniversary, they are, naturally, having a contest:
http://www.castlecops.com/a6737-100_000_Contest_Celebration.html

(Brian Krebs (*The Washington Post*) blog:
http://blog.washingtonpost.com/securityfix/2007/01/in_praise_of_the_phish_fight
er.html)

rslade@vcn.bc.ca     slade@victoria.tc.ca     rslade@computercrime.org
http://victoria.tc.ca/techrev/rms.htm


A second site "improves" security

<"Reinke's Catch All Email" <reinkefj@yahoo.com>>
Wed, 24 Jan 2007 14:28:34 -0500

A second site, Paytrust, has followed Vanguard, in "improving" security. They
now have one screen for userid and then a second screen for password. The
theory is that if I don't see my selected picture and secret phrase on the
screen then I shouldn't enter my password.

I think this is "security theater" at best?

While it makes phishers work a little harder. They have to be ready to
execute a true man-in-the-middle attack. Not very difficult imho.

I don't understand how this helps ME. I understand that it gives them a more
plausible defense should someone break in. Saying we tried.

It also asks me pre-established "extra" questions should I say I'm using a
public computer. Knowing the answers to questions that can be relatively
easily found out, ain't gonna cut it.  How this stops replay or a keystroke
logger beats me?

This is all kabuki as opposed to real security. If they want a security
model to follow, I like GoToMyPC's one time passwords.

That's protection.

Arghhh!

Ferdinand John Reinke, Kendall Park, NJ 08824
http://www.reinke.cc/  blog: http://www.reinkefaceslife.com/


Re: There's more to worry about than math libraries (Robinson, R 24 54)

<Richard Karpinski <dick@cfcl.com>>
Fri, 19 Jan 2007 21:26:21 -0800

Boy, did you pick the wrong thing to complain about! The floating point
arithmetic including on the X86 machines follows the IEEE 754 standard.
Before 754 was developed, a programmer using floating point had to deal with
many wild problems arising on every machine. Every new computer had a new
floating point arithmetic which would bite you in unexpected ways.

Ordinary problems included cases where X times 1 was not equal to X, or Y
plus 0 was not equal to Y. These particular cases involve having
insufficient extra precision, called guard digits, in the registers to
accommodate fully accurate results, especially when the result required
renormalization. In the bad old days you could thus not even count on add
and multiply giving accurate results. Portable software, accurate to the
bit, was well nigh impossible.

If you research the standard, you will find very well documented reference
code for square root and even large collections of test cases suitable to
guarantee that the results of allegedly conforming implementations really
did meet those demands of the 754 standard.  The current state of affairs is
already far better than what you seem to be seeking. Without actually
attending the working group meetings, you would have no idea how much care
is embodied in that standard.

Richard Karpinski, World Class Nitpicker, 148 Sequoia Circle, Santa Rosa,
CA 95401 dick@cfcl.com Home +1 707-546-6760 Cell +1 707-228-9716


Re: Excel Date Bug (Macintyre, R 24 54)

<Steve Schafer <steve@fenestra.com>>
Sat, 20 Jan 2007 21:46:40 -0500

Al Mac refers to a well-known Excel "bug" involving whether or not 1900 is
considered to have been a leap year. What is apparently not so well known is
the reason behind Excel's behavior: compatibility with Lotus 1-2-3. I did
some research on this a few years ago, and I wasn't able to trace the
behavior further back than the first version of Lotus 1-2-3, so that seems
to be when the actual bug was introduced.

You can read Microsoft's statement on it here:

  http://support.microsoft.com/kb/214326

(Although that article refers specifically to Excel 2000, the issue was
present long before that. I first learned of it in connection with Quattro
Pro, which exhibits the same behavior for the same reasons, in 1992 or
thereabouts.)

Steve Schafer, Fenestra Technologies Corp. http://www.fenestra.com/


Re: Excel Date Bug (Macintyre, RISKS-24.55)

<"R.G. Newbury" <newbury@mandamus.org>>
Sat, 03 Feb 2007 21:50:51 -0500

It gets better: Microsoft is attempting to fast-track its weird, wholly
messed up, snafu'ed, tarfun'ed, version of an OOXML standard as ECMA 376,
and that particular stupidity is BUILT RIGHT IN!...That is, rather than
correct the error, any 'standardized' program must REPLICATE the error. Full
story on groklaw, scroll down. Read the whole thing. BTW, the drop dead date
for objections to the fasttrack process is February 5th. I cannot find
anyone at the Standards Council of Canada who even knows that the proposal
exists and that Microsoft will win approval for the fasttrack process by
default if nothing is done.


Re: Excel Date Bug (Steve Wildstrom)

<Dik.Winter@cwi.nl>
Sun, 4 Feb 2007 02:19:40 +0100 (MET)

It is hard for me to believe that nobody at Microsoft thought about another
solution than they think about (maintaining the epoch and increment the day
numbers for all days from 1 Mar 1900).  The most obvious solution would be
to decrement the day numbers before 1 Mar 1900, effectively setting the
eopch one day later...  The incompatibilities listed would only occur when
dates before 1 Mar 1900 were used.  And as is noted, that is rare.  And
the error noted is corrected.  But perhaps this solution is too rational?

dik t. winter, cwi, kruislaan 413, 1098 sj  amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn  amsterdam, nederland; http://www.cwi.nl/~dik/


Re: Daylight saving time mess looms (RISKS-24.55)

<Dr J R Stockton <reply0705@merlyn.demon.co.uk>>
Sun, 4 Feb 2007 17:46:38 +0000

That is inaccurate.  The change is by four weeks in some years and five
weeks in others.  That shows the dangers of believing the media.
Actually, DST is now always 34 weeks; it used to fluctuate.

The change of DST rules actually occurs on March 1st, according to the Act.
<URL:http://www.merlyn.demon.co.uk/uksumtim.htm#AA> refers.

John Stockton, Surrey, UK  http://www.merlyn.demon.co.uk/

  [Note spelling correction: Daylight saving (singular) time.  PGN]


Re: Super Bowl site hacked (EEkid, RISKS-24.55)

<Rob Slade <rMslade@shaw.ca>>
Sat, 03 Feb 2007 15:11:19 -0800

There were actually a number of these in operation.  The Internet Security
Operations Task Force (ISOTF) had quite a frenzy of activity on Friday, and
most sites were taken down in short order.  The sites attempted to use the
VML vulnerability, so only those who had been unpatched for quite some time
were at risk.


Re: Super Bowl site hacked, seeded with exploits (RISKS-24.45)

<"A.Lizard" <alizard@ecis.com>>
Sat, 03 Feb 2007 16:02:16 -0800

I think the RISK here is running a Windows webserver/OS on a high-traffic
website.

http://www.reptilelabs.com http://www.ecis.com/~alizard http://www.pgpi.org
Disaster prep info: http://www.ecis.com/~alizard/y2k.html


Re: The problem of abstractions ... (Robinson, RISKS-24.54)

<"Jos Buurman" <the_jos@hotmail.com>>
Wed, 24 Jan 2007 18:32:03 +0100

I've read Paul Robinson's topic with great interest.

We (large institutional investor) use a system that's developed in APL by
the supplier.  The product is offered in the kitchen model, you can have the
basic product which functions very well, you can also add numerous modules,
the supplier knows how much time this takes on average.

The fact is that this is indeed a niche market.  Furthermore, it's driven by
external force.  The financial markets determine the products the
application should support.  The market determines how those products are
calculated.

For example, we had a minor valuation issue with some special government
bonds and I could determine the cause by just setting the market's
calculation up in Excel.  It turned out we forgot to set the right rounding
rule .  Those calculations are provided in detail by external parties, in
this case the French Government.

If a supplier would invent it's own standards, this was not possible.

Also, it's a market where little mistakes do have large impact.  The
rounding error was on the 5th decimal, but on our holdings this could be
several thousand Euros or more.

Since there is a large impact on error, companies are willing to pay.  So
that covers the financial aspects of development.

The financial market is also constant developing.  New instruments seem to
appear on daily basis.  That also calls for modular set-up of the
application.

Then this market for systems is small.  There are not that many investment
companies that can afford these kinds of systems.  There are only a few
suppliers.  If a company screws up big time once or twice, it's out of
business.

It's hard to compare this market to other markets.  Most markets don't have
customers with the financial power this market has.  The market is driven by
external forces (the financial markets) and not the developing companies.
The financial products have clear specifications.

You can compare the market for railway systems or air traffic systems to
ours.  Those are markets with the same financial power, customer driven,
clear specifications and high risk for the individual customer.

It's not that there are many huge errors out there.  It's the same as the
rounding 'error' we experienced. For many it's not significant.  Only it
could have an enormous impact in those systems.

Most of the time it's some kind of configuration mistake that leads to
errors.  Those happen in any system, even our modular APL based one.

Jos Buurman, System Administrator Investment Management


Re: The problem of abstractions ... (Robinson, RISKS-24.54)

<David Cantrell <d.cantrell@outcometechnologies.com>>
Mon, 22 Jan 2007 10:21:48 +0000

Paul Robinson wrote:

> There is a guy named Louis Savain who ... wants to create for software
> what the transistor and the printed circuit did for electronics ...

Having rigidly defined interfaces between components doesn't help when you
have large numbers of components.  The interactions between groups of
components can become *very* complex and can lead to bugs.  We can draw an
analogy with the game of Go.  It has very simple rules governing the rigidly
defined interfaces between board, players and pieces, but the interactions
between them lead to complexity such that precisely what will happen during
a game is unpredictable.

This is of course a Good Thing as it means a mediocre player like me can
still beat the computer at *something*.

> An example I gave was on the comparison between buying a kitchen makeover
> and a maintenance change to a software package.

A new kitchen is a fairly small, simple construction project.  Small simple
software projects are likewise frequently delivered on time, on budget, and
working first time.  You just don't hear about them because something that
happens all the time ain't news.  What you do hear about are the failed
software projects of a complexity similar to that of the larger physical
projects such as are par for the course in (for example) the defence
industry.

> In short, we get away with the great kind of racket in our business that no
> one would tolerate from a Taiwanese manufacturer of toasters!

But we accept it from the manufacturers of our fighter aircraft, the
builders of railways, and so on.


Re: The problem of abstractions ... (Robinson, RISKS-24.54)

<Tony Finch <dot@dotat.at>>
Mon, 22 Jan 2007 13:27:02 +0000

I remember looking at Savain's web site http://www.rebelscience.org/ a few
months ago. He isn't completely wrong, but he does set off a lot of my kook
alarms. Your summary of his ideas about programming is a fairly good
description of Erlang, which has proven to reduce error and increase
productivity and reliability, and it has been used on some large and
successful commercial and open source projects. Savain's ideas boil down to
diagrammatic programming and as far as I can tell he doesn't talk about
abstractions larger than a statement or perhaps a procedure, i.e. he doesn't
say how to build software in the large. On the other hand, Erlang does have
a coherent answer to this problem - have a look at the thesis of Joe
Armstrong, one of Erlang's creators.
http://www.sics.se/~joe/thesis/armstrong_thesis_2003.pdf

f.a.n.finch  <dot@dotat.at>  http://dotat.at/


Re: The problem of abstractions ... (Robinson, R 24 54)

<Ben Hutchings <ben@decadent.org.uk>>
Sat, 20 Jan 2007 22:17:34 +0000

> If I understand his proposals, what he wants to do is develop software
> visually in terms of components, and "wire" the components together.
> Hardware has rigidly defined interactions and race conditions can't
> occur because asynchronous operations are not possible.

Please take a look at some device drivers in an open source operating
system.  High-level hardware components such as PCI devices often have very
complex interactions, massive internal parallelism, and timing
characteristics that are hard to predict - and that's even if they don't
have a processor and "firmware" of their own.  It's generally far cheaper to
work around hardware bugs in a device driver, if that's at all possible,
than to re-spin the hardware.  So I don't think computer hardware provides a
particularly good example to us.

> An example I gave was on the comparison between buying a kitchen makeover
> and a maintenance change to a software package. With a kitchen, you can
> generally buy off-the-shelf components and have an almost exact estimate
> of the complexity, the time to finish and the cost. And everything will
> fit together and work right the first time.

Well, it makes a change from the tired old-car analogy.

Yes, you can buy these components off the shelf.  They have fairly simple
interactions with reasonably well standardised utility supplies.  (Yet the
sink does not abstract away the pipes below it; you have to remember not to
put things down the plug hole that might build up in the pipe.)  Your
refrigerator isn't expected to interact with your hob.  (Yet it does in an
unfortunate way if you put them too close together.)  When you cook a meal,
all the burden of coordination is on you, not on the appliances and storage
that are involved.  This is not what people expect from software: they
expect a far higher degree of automation.  A kitchen is not a good example
either.

That's not to say that software can't be modular, with well-defined, tested,
interfaces between modules.  But I'm not sure that that's entirely possible
or desirable for whole applications.  Many of the requirements for an
application will be a good deal "softer".  And if the requirements change,
that may require the interfaces between modules to change.  If you wanted to
do that in your kitchen, you'd be out of luck.  But because you know
software is more flexible, you expect to be able change the definitions of
the components at any level - even if you don't know how long that will
take!

> As it stands now, things are "good enough" to get by and even with all the
> failures we have, there is so much value for such little costs that we keep
> stumbling along.

In general, yes - though there are still seem to be many big projects with
insufficient oversight from the customer that yield far less value than they
cost - or even negative value.  The software industry isn't going to stop
doing this until its customers take charge and insist on ongoing refinement
of requirements, phased delivery of and payment for working features, and
other practices that help to reduce risk and increase value for money.
(They may even encourage greater modularity!)


Re: The problem of abstractions ... (Robinson, R 24 54)

<Steve Schafer <steve@fenestra.com>>
Sat, 20 Jan 2007 21:46:40 -0500

Paul Robinson talks about "software integrated circuits" (pluggable
software components with well-defined interfaces); we've heard it
before. The reason it appears that we don't have such things today is
that the proponents are comparing incomparable levels of abstraction. If
fact, we do have them, in the form of if..then..else expressions,
quicksort routines, TCP/IP stacks, etc. These are what correspond to
off-the-shelf integrated circuits. And most software developers _do_ use
these components off the shelf.

What we don't have are things like pluggable accounting packages. It's
true that software components of this sort, ones that could potentially
be abstractable into generic packages, just aren't available. But
hardware functionality of equivalent specific complexity isn't
available, either. Instead, those who want to implement that kind of
functionality in hardware turn to application-specific integrated
circuits (ASICs), and ASIC development pretty much parallels software
development:

  a) Implement.
  b) Test.
  c) Debug.
  d) Repeat from step (a).

There do exist modern programming languages that provide a much higher
level of abstraction than do mainstream languages like C/C++ and Java,
without the extreme terseness of APL or the verbosity of Cobol. Haskell
and other languages of the ML lineage come to mind. Ironically, one of
the reasons they're not very popular is that they require the programmer
to do more up-front thinking about the problem to be solved; i.e., they
require more mental abstraction....

Steve Schafer, Fenestra Technologies Corp. http://www.fenestra.com/


Re: The problem of abstractions ... (Robinson, RISKS-24.54)

<Ray Blaak <rblaa@telus.net>>
Sun, 21 Jan 2007 21:55:28 -0800

Paul Robinson <paul@paul-robinson.us> writes:
 > Basically he wants to create for software what the transistor and the
 > printed circuit did for electronics ...

People keep coming up with this idea, and it keeps failing. Software
components don't work this way. Things that are so rigidly defined so as to
be perfectly reliable in unknown circumstances tend to be not very
interesting or useful.

Visual programming tends not be expressive enough for the really useful
types of things.

 > Personally I believe he has some wonderful ideas and if he isn't
 > right he's very close. But right now, that's all he has, ideas.

That point is accurate. If he can make a system that proves he is right,
then that would be a great success for everyone, really.

 > Almost two years ago I wrote an article for comp.risks.[...] was wrong.
 > Most of them not only didn't get the analogy, they didn't realize
 > that most of their comments reinforced my points.

You only addressed one of the points. What about the others? In particular,
I had said (in RISKS-23.74):

 >> If you have small components that you know are right, and you then
 >> combine those components to manipulate each other according to their
 >> published interface specifications, the results should be consistently
 >> correct. The results will be predictable, the usage will be consistent
 >> every time.
 > This is false. The results will not necessarily be correct at all.
 > "Know are right" is not possible except in very specific and controlled
 > contexts.  When components are used in new situations, any existing
 > assumptions cannot be relied on at all, without tedious and careful work
 > to reestablish them.
 > Software components are not physical components. They do not scale
 > the same way.
 >
 > That the software industry does not offer the same reliability and
 > quality as physically engineered products is not because software
 > practitioners are pulling at fast one (although they often are, but for
 > different reasons).
 >
 > They don't offer the same guarantees, not because they don't want to, but
 > because they cannot. Getting software right is hard. Very hard. So
 > hard that even really really smart people are not willing to be on the
 > hook for it.
 >
 > Customers have to tolerate software with mistakes, because that is
 > the only way they can get affordable software at all. If they insisted
 > on the same guarantees, they wouldn't be able to pay for it.
 >
 > Yes, we need to make better software. We need to try. Things can be
 > improved. They must be. The current situation is not acceptable.
 >
 > But it is not easy. Humans don't seem to be good at it.

There is clearly a software problem that needs to be improved. How to do it
is another question. Probably a mixed approach of little things will work
over time (some formal methods, some better languages, etc.), but most of
all it will require a greater attention to care and quality and a reduction
of simple laziness.

 > The lessons of history teach us - if they teach us anything - that
 > nobody learns the lessons that history teaches us

True enough.

Ray Blaak rAYblaaK@STRIPCAPStelus.net


Re: The problem of abstractions ... (Robinson, RISKS-24.54 )

<"Christopher C.Stacy" <cstacy@dtpq.com>>
Mon, 22 Jan 2007 10:38:07 -0500

 > ... The "big thing" in APL was to write a "one liner," an attempt to
 > write a complete working application in one line of code.

Writing long complex expressions was not considered a positive aesthetic by
experienced APL programmers when I was at STSC (the major APL timesharing
service bureau) in the heyday of the late 70s.  We preferred (and taught
clients) to write good styled code, particularly avoiding long lines, and of
course to put comments on them.  Of course, one can write poor style code in
APL, as in any language, and perhaps you saw some.

I would take issue with the characterization that APL "failed dismally",
although unfortunately it is not very popular today outside of the actuarial
and other niche markets.  APL was quite popular for while, and represented a
major success story for many organizations.  I don't understand your
statement that during that time it "became difficult to work with", or that
its abstraction capabilities had anything to do with it's lack of
popularity.

It is possible to write bad, incomprehensible, unmaintainable code in any
programming language.  The difference with APL is that you have a language
in which it is possible to express certain things concisely and more
clearly.  (Other languages let you express certain other things very well,
too.  And some other languages seem most conducive to certain loud vocal
expressions.)

I don't understand your comment about "subroutine libraries" at all; it
seems to be a nonsequitur.  The APL language consists of a large number of
primitive operators that correspond to what would have to be subroutines in
other languages.  APL vendors provided systems which additionally included
hundreds of library packages for database, graphics, and many kinds of
sophisticated application libraries.

 > Some people have said similar things about Lisp and the increase in
 > productivity they have seen from that as well.

Well, people say all kinds of things, but that doesn't mean that they know
what they are talking about.

I have used, and continue to use, a lot of programming languages since I
started programming in 1973.  I haven't used APL since the 1970s; I switched
to Lisp for most of my work around 1981, and Lisp is I'm using right now for
most of my projects.  I would heartily agree that Lisp and APL are powerful
tools that allow good programmers to maximize their productivity.

Everyone agrees that appropriate abstractions are essential for good
programs, and that some languages are better at facilitating that.
Unfortunately, most discussion of particular languages consist of repetition
of myths and misunderstandings and misinformation, with religous overtones
and attendant rationalizations.

There are many Risks involved in analyzing the various aspects of
programming languages and their effectiveness.  One of the most common
failures is trying to correlate popularity of a language with vague
assertions or just plain wrong information about its technicalities.

I hope that Risks Digest doesn't engage in such endless religious "language
wars".  It would however be instructive to illustrate both general and
language-specific flaws, traps, and risks by analyzing systems failures that
have actually occurred.


Re: Digital cameras converted to weapons (Markowitz, R 24 54)

<Steve Schafer <steve@fenestra.com>>
Sat, 20 Jan 2007 21:46:40 -0500

Sidney Markowitz writes, "The article on converting a camera to a 'taser'
incorrectly talked about disposable digital cameras, which do not currently
exist."

I happened to see one on the shelf at a CVS Pharmacy today:

  http://www.cvs.com/CVSApp/cvs/gateway/detail?prodid=274180
  &previousURI=/CVSApp/cvs/gateway/search?ActiveCat=499
  ^Query=camera+digital

(URL manually broken across lines.)

Steve Schafer, Fenestra Technologies Corp. http://www.fenestra.com/


Re: Canadian coins containing tiny transmitters (RISKS-24.54)

<Rob Slade <rMslade@shaw.ca>>
Sat, 03 Feb 2007 15:11:19 -0800

Well and thoroughly debunked.  The initial report was from a US intelligence
analysis group, with no details.  When tasked on the matter, they first
asserted it was true, and finally admitted that there was no evidence at all
to support the claim.  The idea of bugging coins was widely seen as a stupid
idea, since most such devices would have ended up in vending machines ...
  [Noted by many of you.  PGN]


Re: Windows Vista voice vulnerability (RISKS-24.55)

<Rob Slade <rMslade@shaw.ca>>
Sat, 03 Feb 2007 15:11:19 -0800

And it would be easy enough to have the voice/video file mail itself out to
email addresses harvested on the machine, turning it viral ...

Please report problems with the web pages to the maintainer

Top