The RISKS Digest
Volume 22 Issue 66

Tuesday, 1st April 2003

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…


The Security Flag in the IPv4 Header
Steve Bellovin
The Angelic Bit vs the Evil Bit
Drew Dean
Alternative electronic recycling
'Reverse production' system recycles all
Use a Firewall, Go to Jail
Ed Felten via Monty Solomon
Re: Use a Firewall, Go to Jail
Steven M. Bellovin
State Super-DMCA too true
William Allen Simpson
Voting machine article in *The Washington Post* by Dan Keating
James Paul
Internet vs. the recording industry
To unlock safe... please endanger your financial future
Jack Burke
Re: Friendly fire
Hugo Tyson
Aircraft software maintenance
Martyn Thomas
Risks in reading RISKS links
Doug Sibley
Re: Beware the spelling checker
Bodo Moeller
Info on RISKS (comp.risks)

The Security Flag in the IPv4 Header

<Peter Neumann <>>
1 April 2003

Steve Bellovin's RFC 3514 (released today) assigns a meaning to the IPv4
packet header's last currently unused bit, which can be thought of as a
Security Flag.  Benign packets have this bit set to 0; those that are used
for an attack will have the bit set to 1.  Correct functioning of security
mechanisms depends critically on the bit being set properly.  If faulty
components do not set the bit to 1 when appropriate, firewalls will not be
able to do their jobs properly.  Similarly, if the bit is set to 1 when it
shouldn't be, a denial of service condition may occur.

Following is a summary of the assigned values in the RFC:

   0x0  If the bit is set to 0, the packet has no evil intent.  Hosts,
        network elements, etc., SHOULD assume that the packet is
        harmless, and SHOULD NOT take any defensive measures.  (We note
        that this part of the spec is already implemented by many common
        desktop operating systems.)

   0x1  If the bit is set to 1, the packet has evil intent.  Secure
        systems SHOULD try to defend themselves against such packets.
        Insecure systems MAY chose to crash, be penetrated, etc.

It is well worth your reading the full RFC, which is now available:

  [See the IETF Web site for the full set of RFCs, for those of you not used
  to reading them.  It is an extraordinary view of the history of the
  ARPAnet and Internet:

The Angelic Bit vs the Evil Bit

<Drew Dean <>>
Tue, 1 Apr 2003 10:00:01 +1000

Steve Bellovin's proposed RFC 3514 finds a very constructive use for the
last unused bit in the IPv4 header.  In his proposal, the unused bit is
sometimes affectionately referred to as the "evil" bit, although that naming
convention reflects a fundamentally *pessimistic* world view.  We prefer an
*optimistic* world view, and therefore propose that this last bit should be
used for the "angelic" bit.  Our proposed semantics for the angelic bit are
as follows:

  0x1  The angelic bit is set.  All routers, firewalls, switches, and any
       other network devices MUST forward this packet to its indicated
       destination.  This packet MUST NOT have any undesirable effect on any
       network device.  Anyone who improperly sets the angelic bit on any
       packet SHALL be subject to divine retribution.  Civil authorities MAY
       subject the perpetrator to any punishment provided for in applicable

  0x0  The angelic bit is reset.  All routers, firewalls, switches, and other
       network devices MAY filter this packet according to any policy they
       deem fit.  This packet MAY have undesirable effects if forwarded.
       The sender of the packet SHALL NOT be subject to divine retribution
       in case of undesirable effects.  Civil authorities MAY subject the
       perpetrator to punishment provided for in applicable law.

NB: The angelic bit may have miraculous properties in face of network links
severed by backhoes; however, this SHALL NOT relieve the router of its

Yours for a more genteel Internet, Drew Dean

  [Note added 1 Oct 2003 by PGN in RISKS archive copy:

    From Peter Gutmann's "X.509 Style Guide"

    One might as well add a "crimeFree" (CF) bit with usage
    specified as 'The crimeFree bit is asserted when subject
    public key is used to verify digital signatures for
    transactions that are not a perpetration of fraud or other
    illegal activities'
                       — Tony Bartoletti on ietf-pkix

  My apologies to Tony for not giving him proper attribution....  Drew]

Alternative electronic recycling (Re: Reverse production, R-22.66)

<Peter Neumann <>>
1 April 2003

Perhaps inspired by the Georgia Tech 'reverse production' recycling scheme
for computer hardware [see the FOLLOWING item], computer scientists have
discovered a way to recycle previously used computer cycles and previously
generated data.  The trick is first to compress newly written programs using
an approach similar to Kolomogorov Complexity analysis, and then map the
results into callable elements of old programs that can directly give the
desired results in return.  Research is underway that would even enable the
used cycles of old programs written in archaic languages such as COBOL and
FORTRAN to be recycled in this way.  Optimizing compilers are already being
developed to make this practical, incorporating formal methods (e.g.,
theorem proving and model checking) to ensure that only provably correct
program elements are allowed.  In addition, some artificial intelligence
groups reportedly believe that automatic program synthesis techniques could
be used to avoid writing the new programs altogether, thus surmounting the
existing limitations of bad software engineering while still obtaining
highly efficient programs.

It is estimated that this approach could substantially reduce the burgeoning
need for more cycles and new storage capacity.  When applied to Windows
operating systems, initial experiments show that this could result in at
least a 70% reduction in program size and execution time.  Purveyors of
electronic voting machines are intrigued by the possibility of reusing the
results of previous elections, with suitable parametric transformations.
However, several computer vendors are objecting on the grounds that
widespread use of this technique could detrimentally result in a
"compression depression" trickle-down effect of decreased revenue that could
more than completely negate the beneficial hardware demands that result from
steadily increasing bloatware and the constant need for upgrades.  In
addition, programmers' unions are contemplating strikes if this technique
becomes widely adopted.

The word 'reverse' also brings to mind some research results on programs
that can be run backwards (for example, implementing information lossless
algorithms that work forwards and backwards, and also environments in which
'undo' operations can be successfully executed).  Use of such programs
could result in saving a further factor of two.

A previously proposed alternative approach of creating a very large number
of randomly generated compressed programs and then finding the one that
works best for the given application has unfortunately been temporarily
abandoned as unworkable, pending further research.  That approach had been
conceived in response to the somewhat obscure but truly classical 1961
paper, subsequently reprinted as ``The Chaostron: An Important Advance in
Learning Machines'', J.B. Cadwallader-Cohen, W.W. Zysiczk, and
R.B. Donnelly, *Communications of the ACM*, April 1984, pages 356--357).

'Reverse production' system recycles all

<"NewsScan" <>>
Wed, 05 Mar 2003 09:25:28 -0700

A study underway at Georgia Tech could offer a model for responsible
recycling of electronic waste.  Researchers have developed a "reverse
production" system that enables every raw material contained in e-waste --
metals such as lead, copper, aluminum and gold, as well as plastics, glass
and wire — to be recovered and reused.  Scientists say such "closed loop"
manufacturing offers a win-win situation for manufacturers and consumers,
and the project is generating buzz abroad, with officials in Taiwan and
Belgium expressing interest in the system.  Key to the process is chemical
engineer Matthew Realff's design for a means to separate metals, as well as
different qualities of plastics from crushed, ground-up components.  From
this work, new industries could be created to recover value not only from
e-waste, but also from automobiles and other durable goods, says Realff.
(*Science Daily*, 4 Mar 2003; NewsScan Daily, 5 March 2003)

Use a Firewall, Go to Jail

<Monty Solomon <>>
Fri, 28 Mar 2003 15:36:25 -0500

March 26, 2003
Ed Felten, Use a Firewall, Go to Jail

The states of Massachusetts and Texas are preparing to consider bills that
apparently are intended to extend the national Digital Millennium Copyright
Act. (TX bill; MA bill) The bills are obviously related to each other
somehow, since they are textually similar.

Here is one example of the far-reaching harmful effects of these bills. Both
bills would flatly ban the possession, sale, or use of technologies that
"conceal from a communication service provider ...  the existence or place
of origin or destination of any communication".  Your ISP is a communication
service provider, so anything that concealed the origin or destination of
any communication from your ISP would be illegal — with no exceptions.

If you send or receive your e-mail via an encrypted connection, you're in
violation, because the "To" and "From" lines of the e-mails are concealed
from your ISP by encryption. (The encryption conceals the destinations of
outgoing messages, and the sources of incoming messages.)

Worse yet, Network Address Translation (NAT), a technology widely used for
enterprise security, operates by translating the "from" and "to" fields of
Internet packets, thereby concealing the source or destination of each
packet, and hence violating these bills. Most security "firewalls" use NAT,
so if you use a firewall, you're in violation.

If you have a home DSL router, or if you use the "Internet Connection
Sharing" feature of your favorite operating system product, you're in
violation because these connection sharing technologies use NAT. Most
operating system products (including every version of Windows introduced in
the last five years, and virtually all versions of Linux) would also
apparently be banned, because they support connection sharing via NAT.

And this is just one example of the problems with these bills. Yikes.

UPDATE (6:35 PM): It's worse than I thought. Similar bills are on the table
in South Carolina, Florida, Georgia, Alaska, Tennessee, and Colorado.

UPDATE (March 28, 9:00 AM): Clarified the paragraph above about encrypted
e-mail, to eliminate an ambiguity.

Posted by Edward W. Felten

  [Moderator's note:  This item is NO JOKE, despite the date of this issue.
  Check out the thread that is occurring subsequent to Ed Felten's message:
  as well as the next two messages in this issue, from Steve Bellovin and
  William Allen Simpson.  PGN]

Re: Use a Firewall, Go to Jail

<"Steven M. Bellovin" <>>
Fri, 28 Mar 2003 19:08:42 -0500

After reading the full text of the Texas bill
I think it may be even worse than Felten portrays it.

First, a number of people have claimed that the bill isn't a problem,
since it only applies if you intend to harm or defraud an ISP.  I don't
think that that's the case.

Section 2 of the billl, which does contain the phrase "with the intent to
harm or defraud a communication service", bars theft of service.  (I'm
speaking loosely here; read it for yourself.)

Section 4 also contains that phrase; it bars possession of devices for
defrauding providers.  (The language is very broad, and seems to bar
possession even a computer or modem if you have evil intent.)

The ban on concealing origin or destination is in Section 6.
That section does *not* have the "intent to harm" phrase.  Given that
the bill is amending three consecutive sections of the state penal code
(31.12, 31.13, and 31.14), and given that the first two sections have
that language but the third doesn't, it's hard for me to conclude that evil
intent is required by the proposed statute.

But it's worse than that:  the bill bars concealment of "existence or
place of origin or destination of any communication" from "any lawful
authority".  In other words, it would appear to outlaw many forms of
cryptography or steganography, or anonymous remailers.  (As an aside, I
would note that the constitutional justification for easy law
enforcement access to source and destination address information via the
pen register statute is flimsy at best — see my analysis at

Even Web proxy servers and the Ethernet connectivity from many hotels
would be covered by this bill — they obscure the origin, too.

What's unclear to me is who is behind this.  Felten implies it's content
providers trying for a state-level DMCA; I think it's broadband ISPs who are
afraid of 802.11 hotspots.  In fact, if the "intent to cause harm" phrase
were added to that section, it would clearly criminalize behavior that some
ISPs are trying to ban today via their terms of service.

Steve Bellovin,

State Super-DMCA too true (from NANOG)

<William Allen Simpson <>>
Sat, 29 Mar 2003 15:53:32 -0500

  [Courtesy of Steve Bellovin.  PGN]

Declan McCullagh sent out an e-mail this morning,
referencing his full report at:

I was shocked to see that Michigan has *already* passed such a law!
(Also Virginia, Delaware, and Illinois.)

I've found the new law(s), and they basically outlaw my living in
Michigan starting March 31st (this Monday, two days from now):

The Bill analysis basically quotes the MPAA website!

It outlaws all encryption, and all remailers.

It outlaws connecting any device "without the express authority of the
telecommunications service provider".  No NATs.  No wireless.

(Some DSL/cable companies try to charge per machine, and record the machine
address of the devices connected.)

It outlaws configuring your ISDN to be a voice device, and then sending data
over the device.

(Most folks around here are willing to settle for 56Kbps + 56Kbps — fixed
fee — instead of 64Kbps + 64Kbps — per minute.)

It outlaws configuring a wire pair purchased as a burglar alarm circuit, and
then using it as DSL.

It outlaws using Linux/*BSD for reading DVDs and a host of other things.

Also, "reprogramming" a device (and software and computer chips are
explicitly included) "that is capable of facilitating the interception,
transmission, retransmission, decryption, acquisition, or reception of any
telecommunications, transmissions, signals, or services" would seem to
prohibit mod'ing of M$ Xboxen.

Heck, it is possible to read this Act to prohibit changing your
operating system from M$ to Linux.

This was passed in a lame duck session (December 11, 2002) as part of a big
omnibus crime act that covered everything from "adulteration of butter and
cream", to "trick or acrobatic flying" to "false weights and measures",
mostly increasing fines and/or jail for existing offenses.  Michigan is a
leader in overcrowding its prisons.

There was other lame duck legislation passed, before a new Governor took
office, almost all of it bad for civil liberties!

William Allen Simpson

Voting machine article in *The Washington Post* by Dan Keating

Fri, 28 Mar 2003 01:27:21 -0500 (EST)

As election officials rush to spend billions to update the country's voting
machines with electronic systems, computer scientists are mounting a
challenge to the new devices, saying they are less reliable and less secure
from fraud than the equipment they are replacing.  Prompted by the demands
of state and federal election reforms, officials in Maryland, Georgia,
Florida and Texas installed the high-tech voting systems last
fall. Officials in those states, and other proponents of electronic voting,
said the computer scientists' concerns are far-fetched.   [...]

David Dill, the Stanford University professor of computer science who
launched the petition drive, said, "What people have learned repeatedly, the
hard way, is that the prudent practice — if you want to escape with your
data intact — is what other people would perceive as paranoia."  Other
computer scientists, including Rebecca Mercuri of Bryn Mawr College, say
that problems are so likely that they are virtually guaranteed to occur --
and already have.

  [Source: Dan Keating: New Voting Systems Assailed, *The Washington Post*,
  27 Mar 2003; PGN-ed]
  See David Dill's petition at

Internet vs. the recording industry

<"NewsScan" <>>
Fri, 28 Mar 2003 10:47:35 -0700

Media analyst Eric Garland of Big Champagne has told California lawmakers
that the growth of music file-sharing on the Internet is "fundamentally
unstoppable," because 61 million Americans and millions more worldwide are
already downloading music and only 9% of them think they're doing something
wrong. "We see only one trend. More people are downloading more copyrighted
material." Garland's advice for the recording industry is to embrace digital
distribution rather than institute lawsuits or education campaigns, but such
advice is not well-received by industry executives, who are routinely urged
by Internet enthusiasts to accommodate to technological realities. Phil
Corwin, a lobbyist for Internet music service Kazaa, told the same group of
state legislators: "The record business, in the digital revolution, has been
a day late and a dollar short." [A dollar may not be the final figure.] The
fight goes on.  [AP/*San Jose Mercury News*, 28 Mar 2003; NewsScan Daily, 28
March 2003]

To unlock safe... please endanger your financial future

<Jack Burke <>>
Fri, 28 Mar 2003 16:41:25 -0500

A local (Atlanta, Georgia) radio station is running a contest (what else is
new?) for callers to enter.  (I won't mention B98.5's call letters to save
them the embarrassment.)  It's the same standard formula:  when you hear a
particular song, be the 42,828,210,193 listener to call in for "your chance
to win."  The grand prize is $2 million.

The "gimmick" in this one is that the money is in a safe.  To unlock the
safe, a potential vict^H^H^H^Hwinner must give the DJ the 5 one-digit
numbers in the combination--but not just _any_ 5 numbers will do.  Callers
are asked for the last 5 digits of their social security
number.  (Presumably the station will require verification before actually
paying out the "winnings.")

Did I mention that this was all done on the air?  Can anyone guess how many
people I've heard willingly gush out five-ninths of their SS number and
first and last name on the air?

In 3 seconds or less, how many different things can you think of for which
all or part of a social security number is used?

- Social security "benefits"
- credit applications
- credit reports
- PINs for telephone access to account information (banks, etc.)

Can anyone say: "shortcut to identity theft"?  (Not as far-fetched as you
might think.  The first three digits are based on the state in which you
apply for the number in the first place, which stands a reasonable chance of
being where you were born.  That's an easy topic for a conversation with
someone who you "accidentally" meet.)

Re: Friendly fire (was: Patriot software again a concern?)

<Hugo Tyson <>>
Fri, 28 Mar 2003 18:31:08 GMT

In Risks Digest 22.65 PGN wrote:
>     [Incidentally, NBC on 24 Mar 2003 had an item on self-inflicted
>     damage, noting that in the Vietnam War, 24% of U.S. fatalities were
>     due to friendly fire.  I have heard reports that it was even higher
>     in the first Gulf War.  That is truly astounding!  PGN]

Not sure whether it's a computer risk, but this is a social risk in terms of
expectations about such things, due to the high-tech weapons now available
to *some* armed forces: when one side has far better offensive weapons and
far better defensive weapons than the other, a consequence is that
friendly-fire incidents will dominate the casualty list for the better-armed
side, simply because the less-well-armed side won't be able to harm the
better as much as FF can.  The same applies to night-vision gear,
intelligence, surveillance and all that.

For example:

Offensively, if only one side can see clearly at night, only that side will
be able to hit things *at all** - even if they're not sure whose things.

Defensively, the flip-side: if only an Abrams round can kill an Abrams
tank, then 100% of Abrams destroyed will be FF.

Not suggesting this is so across all encounters in the current war by any
means, but in tank vs. tank, aircraft vs. ground vehicle, and aircraft
vs. anti-aircraft/anti-missile I think it has the ring of truth.

Aircraft software maintenance (Re: Ladkin, RISKS-22.65)

<"Martyn Thomas" <>>
Fri, 28 Mar 2003 18:18:24 -0000

In a recent posting on an A320 Airbus software fault that contributed to a
loss of braking, Peter Ladkin wrote: "BCSU software Release 7 was on board;
Release 8 provides a fix for the sensing discrepancy condition involved in
this incident; Release 9 was released after in-service experience with
Release 8."

Does this mean that a fault was introduced in Release 8 that was not found
in testing/recertification but that showed up fairly quickly in operational
use? If so, does this suggest that the process for introducing maintenance
changes needs improvement?

I have never understood how changes to safety-related software can be
introduced rapidly without the formal specifications and formally defined
languages that might allow the maintenance group to be completely confident
about the scope of the necessary reverification/revalidation. Can anyone
explain? Or is there a process weakness here that will one day contribute to
an accident?

Risks in reading RISKS links

<Doug Sibley <>>
Fri, 28 Mar 2003 16:14:26 -0500 (EST)

With a referral from RISKS, an article by Dan Farmer, and the MIT name, I
expected the link in RISKS 22.65
to be viewable without any significant risks (sorry for saying the word
"risk" so many times).

Unfortunately, there were many. It requires registration (so I need to link
my e-mail address to the viewing of this article — privacy invasion but
whatever (it gives me the idea for a server where people could create
temporary/throwaway receive-only e-mail accounts where messages would only
be stored for a few hours for the only purpose of signing up at places like
this — although I can imagine it would violate the DMCA in some way).

Getting back to the risks: the form has one starred field for passwords
instead of the usual two. I entered a username and then entered a password
twice (as is normally required) and clicked submit. So I entered my password
as my first name. Since the form required a postal code, etc.  I had to
re-fill-out the form. Given that they starred the password, one would expect
that (a) the password would not be stored, and (b) that it would not be
displayed. When you submit though, your password is e-mailed to you.

I would expect large institutions like MIT to have figured out passwords by
now but my cellular provider also does not. Bell Mobility stores passwords
online and there are two account preferences-type views, one has the
password starred and the other unstarred (of course the password is kept in
all-caps to make password guessing easier). In fact, when I was having
problems a Bell Mobility representative e-mailed asking for my password
(which I reported but never got back from). American Express limits
passwords to 8 character alpha-numeric.

How long will it take for companies with reputation and value at stake to
properly manage risks? Why is password security so poorly done in practice
when it is such a well-studied problem?

Re: Beware the spelling checker (Cowan, RISKS-22.65)

<Bodo Moeller <>>
Mon, 31 Mar 2003 18:02:37 +0200 (MEST)

The interesting aspect about spilling chicken software is that it helps you
make sure you keep only those errors that actually distort the meaning.
Automatic correction is even more interesting in this respect.

True story: a German collection of law texts (from by a private publisher)
consistently uses the word "Regenschutz" when it should say "Regelsatz".
The latter roughly translates to "standard rate" (this is in regulations
concerning public-welfare aid); the former means "rain protection".

It was not problem to figure out what the text should have said.  The
problem was just that you are not supposed to laugh loudly in public

TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
Tel. +49-6151-16-6628, Fax +49-6151-16-6036

  [Better known perhaps is the word "Regenschirm" — an umbrella, or
  literally, a screen against the rain — which of course was what was
  needed for protection during the Reagan administration.  Danke!  PGN]

Please report problems with the web pages to the maintainer