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 22 Issue 48

Thursday 9 January 2003

Contents

'DVD Jon' acquitted by Norwegian court
NewsScan
Supreme Court backs off on DVD descrambling code
NewsScan
Edge conditions and date-rollover bugs
identity withheld by request
Turing Tests for spam
Chris Leeson
S*X.COM ruling could open floodgates on registry lawsuits
NewsScan
Lost header in text of RISKS-22.47
PGN
Re: Man allegedly stalks ex-girlfriend with help of GPS
Alpha Lau
Wrong CLID woes
Richard Snider
Re: /Trivial/ Risks of Technical Arrogance
Bill Bumgarner
Re: O Big Brother, where are thou?
David Martin
Edward Nilges
TIA: Groove is simply a collaboration tool
Stever Robbins
Re: TIA, surveillance, and Tolkien
Noah Shachtman via Monty Solomon
REVIEW: "Building Linux Virtual Private Networks", Kolesnikov/Hatch
Rob Slade
REVIEW: "Know Your Enemy", Honeynet Project
Rob Slade
Info on RISKS (comp.risks)

'DVD Jon' acquitted by Norwegian court

<"NewsScan" <newsscan@newsscan.com>>
Tue, 07 Jan 2003 08:58:28 -0700

Jon Lech Johansen (also known as DVD Jon), who was accused of illegally
developing and distributing the DeCSS program for breaking the digital
copy-protection mechanism on DVDs, has been acquitted in a Norwegian court.
The rationale for the judge's decision was that the software could be used
for legal purposes as well as illegal ones. "If a person's motive is to
solely encourage or solicit illegal actions, then it would be illegal to
distribute it" -- but the court made the judgment that Johansen was not
motivated in that way.  [*PC World*, 7 Jan 2003, NewsScan Daily, 7 Jan 2003]
  http://www.pcworld.com/news/article/0,aid,108462,00.asp


Supreme Court backs off on DVD descrambling code

<"NewsScan" <newsscan@newsscan.com>>
Mon, 06 Jan 2003 09:21:41 -0700

The U.S. Supreme Court has rescinded an emergency stay barring defendant
Matthew Pavlovich from distributing DeCSS, a software utility that
descrambles the digital lock on most DVDs to prevent copying them.
Pavlovich is now free to distribute the code, but could be sued again if he
decides to do so. "The entertainment companies need to stop pretending that
DeCSS is a secret," says Cindy Cohn, legal director for the Electronic
Frontier Foundation, which is assisting Pavlovich. "Justice O'Connor
correctly saw that there was no need for emergency relief to keep DeCSS a
secret. It doesn't pass the giggle test." The rescission is just the latest
twist in a case that has been winding its way through the courts since 1999,
when the DVD Copy Control Association -- a coalition of movie studios and
consumer electronics makers -- filed a lawsuit against scores of people,
alleging violations of California's trade secret laws.
[CNet News.com, 3 Jan 2003; NewsScan Daily, 6 Jan 2003]
   http://news.com.com/2100-1023-979197.html?tag=fd_top


Edge conditions and date-rollover bugs

<[identity withheld by request]>
Mon, 06 Jan 2003 11:49:16 -0500

An acquaintance found himself puttering around late New Year's Eve with an
allegedly general-purpose and high-quality date/time library he'd written.
He was using it to count down the seconds until midnight, as programmers are
wont to do.  The witching hour, however, provided a rather dramatically
convincing demonstration that the code in question is *not* quite perfect
yet.  The countdown showed:

  2002-12-31 23:59:56.61
  2002-12-31 23:59:57.52
  2002-12-31 23:59:58.45
  dateexpr: newtime.c:618: normalize:
     Assertion `t2.subsec >= 0 && t2.subsec < 1000000' failed.
  Aborted (core dumped)
  2003-01-01 00:00:00.26
  2003-01-01 00:00:01.17
  2003-01-01 00:00:02.08

(There's some comfort, I suppose, in the fact that the core dump resulted
from an assertion failure, as opposed to a wholly unexpected bug...)


Turing Tests for spam

<Chris Leeson <CHRIS.LEESON@london.sema.slb.com>>
Thu, 09 Jan 2003 10:34:36 +0000

In an attempt to prevent spammers from using "robots" to sign up for
multiple free email accounts, companies using Web-based email systems are
using "Captchas" (Completely Automated Public Turing tests to tell Computers
and Humans Apart).

Roughly translated, a pass phrase is generated as an image, and then noise
is added to the image. The user is then required to type the pass phrase
in. The idea is that a human will be able to do this, but a "robot" will
not.

The method is not foolproof - some programs can read the pass phrase
(admittedly slowly) and some spammers simply redirect the pass phrase to a
human.

The problem for legitimate users is that the image may be difficult to read
if the user has impaired vision (or worse, is completely blind). Quoting
from the article:

  "If this new way of presenting password information prevents visually
  impaired people from using a service then we have a serious problem on our
  hands," said Julie Howell, campaigns officer at the Royal National
  Institute for the Blind in the UK.  She said legislation in the Britain
  and US demands that companies make Web sites accessible to people with
  disabilities.  "Security and accessibility must co-exist, not conflict,"
  she said.

The article notes that work is now taking place on sound-based
"Captchas". Sadly, this will only shift the problem to people with hearing
difficulties.

[Source: BBC News Web site]
   http://news.bbc.co.uk/1/hi/technology/2635855.stm


S*X.COM ruling could open floodgates on registry lawsuits

<"NewsScan" <newsscan@newsscan.com>>
Mon, 06 Jan 2003 09:21:41 -0700

A federal appeals court has asked California's Supreme Court to rule on
whether Network Solutions Inc., the largest U.S. domain registry, must face
a multimillion-dollar damage claim from the rightful owner of the s*x.com
domain name. The ruling could lead to a flood of lawsuits against domain
registries, particularly NSI, from hundreds of people who claim their domain
names were also stolen. The current case stems from a lawsuit filed in 1998
by Gary Kremen who registered the s*x.com name with NSI in 1994. In October
1995, NSI received a letter purportedly from Kremen asking that the name be
reregistered to a company headed by Stephen Cohen. NSI complied without
attempting to verify the validity of the request, and then refused to undo
the transfer when alerted to the fraud. Meanwhile Cohen, who was using the
domain name for a lucrative porn business, fled the country before Kremen's
lawsuit against him went to trial in 2001. Kremen, who is now using s*x.com
for his own porn business, was awarded $65 million in damages from Cohen for
fraud (which he'll probably never collect) and is now requesting an
additional $30 million from NSI for allowing the fraudulent transfer.  [*San
Francisco Chronicle*, 4 Jan 2003; NewsScan Daily, 6 Jan 2003]
  http://shorl.com/bigrifretomebro


Lost header in text of RISKS-22.47

<"Peter G. Neumann" <neumann@csl.sri.com>>
Tue, 7 Jan 2003 9:20:11 PST

My apologies for the error in RISKS-22.47 that seemed to run two unrelated
contributions together.  The header for Danny Burstein's contribution noted
in the CONTENTS of the issue and in the second item by Jerry Leichter was
inadvertently omitted.  It has been corrected in the official archives,
ftp.sri.com at SRI, and risks.org -- which indirects to Lindsay Marshall's
catless site at Newcastle.  PGN


Re: Man allegedly stalks ex-girlfriend with help of GPS

<Alpha Lau <avlxyz@yahoo.com>>
Sun, 5 Jan 2003 21:34:20 -0800 (PST)

I am a bit curious as to how the GPS SmartTrack unti could get line-of-sight
to the GPS satellites while under the metallic hood of the car, which
should, unless I am mistaken, block GPS transmissions?

Is it possible that the SmartTrack unit used cellular networking instead? It
should be possible if you know the locations of all the cellular network
base stations.  You could determine the strength of each signal and thus
triangulate the position. Cell phones do this all the time as it tries to to
hand-off to a neighboring cell.

  [Perhaps an oversimplification in the reporting. PGN]


Wrong CLID woes

<Richard Snider <risks@sounds.com>>
Tue, 7 Jan 2003 13:32:20 -0500

A few years ago my family moved to a new home and with the new home we were
assigned a new phone number.  After a few months, we began to get messages
on our answering machine of the type:
  "...why did you call me and hang up"
  "...who is this"
  "...please stop calling us"
and other more strongly worded versions. Since we were never home at the
time these came in, I assumed that some neighbor with a similar cordless
phone to ours was "borrowing" our line. This proved to be not the case and I
wondered what might be happening until finally a person called to complain
and was actually able to talk to me.

They called and asked for Mr. Med-Deea, I advised them that there was no-one
present with that name.  They told me that someone just called from my
number so they must be present.  I asked them to spell the name...M-E-D-I-A,
you know Mr. Med-Deea.

Now we were getting somewhere.  This was sounding like some fax-spam type
company that either intentionally or by mistake programmed their equipment
incorrectly.  I attempted to pacify the ever-more-irritated lady by offering
the above technical explanation.  No, she said its my number showing on her
box, so it must have been someone at my house that phoned her.  Then I told
her I would prove it to her.  I will phone her myself and so I did.  She
instantly claimed I was wrong because the same number was showing on her
phone.  I asked her to look at the name....Oh..it was different. She was
happier and I was happier.

I tracked down the previous owner of the phone number, and despite being
quite wary of me, seemed to know nothing about telcom, fax marketing, or
phones in general, so I ruled out that someone had left the number in some
peice of hardware and forgot to change it.

Ultimately, there was not much I could do, although I did not try I assumed
that the phone company would not be particularly helpful in this regard.  If
the calls were originating Intra-Lata, there might be some accounting
records for them, but I doubt that anyone could have been convinced to check
it out.

Eventually, the calls stopped and we have not had one for over a year now.
Either the marketer went bust, or fixed their hardware.

There are many RISKS here, the most important one is that people who do not
understand the technology will tend to not accept explanations that differ
from their own.


Re: /Trivial/ Risks of Technical Arrogance (RISKS-22.46)

<Bill Bumgarner <bbum@codefab.com>>
Sat, 4 Jan 2003 15:24:00 -0500

While this is certainly unacceptable behavior on the part of the application
in question and such behavior-- failing gracelessly at the merest hint of
something erroneous-- is common to both $10 kiddie games and $5,500 studio
tools (and everything in between), blaming it on the programmers-- on
technical arrogance on their part-- is both misguided and counterproductive.

The real problem lies in how the average software package, Web site, custom
development solution, or embedded system is developed.

Typically, the client / product manager / producer / art department /
creative crew create a set of story boards / screens / photoshop images /
line art on napkins / diagrams that represent the user experience with a
hint of what the logic behind it may be required.  It is rare that these
"blueprints" include anything more than a hint as to what to do when
something goes wrong.

As such, handling exceptional situations is largely an afterthought.  The
developers may slap something in, but it isn't on their schedule and it is
typically done at the last minute under a serious time crunch.

It isn't up to the developer to specify the requirements of a system.  As
you indicate, their system is not the average and it is extremely unlikely
that the average developer will be familiar with what an average system in
the target market may be equipped with.

The product manager / client / producer / marketing should have determined
the minimum requirements and specified that to the developer.  Furthermore,
the 'blue prints' should have contained information as to how to handle
exceptional situations-- how to fail gracefully.

Most importantly, both time and budget should have been allocated to develop
the error handling features properly and to test the software in conditions
where it would fail.

In other words: Don't blame the messenger....  and don't blame the soldiers
for failing to take a hill when the generals send them into battle with
incomplete information.


Re: O Big Brother, where are thou? (RISKS-22.44-47)

<"David Martin" <dm@cs.uml.edu>>
Wed, 8 Jan 2003 17:37:31 -0500

Conspicuously overlooked in the discussion about Total Information Awareness
is the lack of any means for the US government to *obtain* the terabytes or
whatever it's supposed to sift through.  When I asked the deputy director of
TIA about this last year, he acknowledged that they would be relying on
publicly available and voluntarily supplied data for TIA -- as is typically
the case in the construction of prototypes.  The story routinely presented
in the media is that the government is just doing this to us, and the only
hurdles to widespread deployment are purely technical ones.  But it seems
clear to me that Congress and the courts would have something to say about
compelling private businesses to routinely submit their transactional data
for government inspection.

David Martin, Computer Science, UMass Lowell  http://www.cs.uml.edu/~dm


Re: O Big Brother, where are thou? (Leichter, RISKS-22.47)

<Edward Nilges <spinoza1111@yahoo.com>>
Tue, 7 Jan 2003 14:55:47 -0800 (PST)

Turing limits, like it or not, play a part in the actual application of
software; the field would not exist without these limits, since absent the
Halting problem automatic methods would have been used, long ago, to debug
software.  They apply a fortiori to man/machine systems insofar as the human
members follow procedures.

>... Does Mr. Nilges seriously believe that Groove, whatever it might do,
> comes out of the box configured to search for terrorist activity?  ...

By announcing the use of Groove, the administration has done the bad guy's
work for them.  In terms of your example, we have sent them a letter saying
"perg is grep."  This indicates a fundamental lack of seriousness, and that
the real purpose of the TIA program is a pork barrel for Bush's friends in
the depressed data base industry.  It's as if the British could buy the
Enigma in Sweden, rather than capturing it!

>Now, no one would propose using grep, or any such simple-minded search, for
>this kind of thing today [...]

This view is based on a mistake about language, in which the bad guys agree
to follow syntactical and semantical rules known to both parties.  Of
course, hackerz and others generate the rules embedded in the usage as part
of the usage and this means that no automated system can keep up.  "Hackerz"
is the simplest example because in terms of sound, z is a neighbor of s, due
to the topology of our sound production equipment.  You can tell the
automated system what rules to follow but there is of necessity a boundary
which moves but does not disappear.

This presents you with a Hobson's choice.  Either you take the time to
figure out the rules completely or you use probabilistic models.  The first
alternative means your results are generally too late for the SAME reason
large scale projects are so often late.  The problem with the second
alternative is that the probabilistic model is just as rigid as a
deterministic and formal model for the SAME reason that, as von Neumann
said, a computer cannot generate a truly random number.  It is a form of
"night vision" which has the probability that the gear will conceal just
what you need to know.

It gets worse, because you've told the bad guy that you are using Enigma or
Groove.  All he needs to do is buy, steal or reverse engineer your model!

> [...]

Cops keep crime scene details secret.  But they do not set up a data system
to do so because this presents the possibility that the details can be
known.  Cops are aware, unlike data systems people, that they are in a
"dialogue" with "terrorists" in the sense of a probability that any one of
their actions may be known as part of its being recorded.

Ordinary computer users are told on day one that anything they write in
e-mail must be treated as if it would appear in the local newspaper.  The
TIA seems to ignore this simple rule insofar as it encapsulates intelligence
procedures in a form that is easy to copy.

Note that its chief Poindexter was unaware in 1987 that his e-mail on the
White House PROFS system was not completely erased when he erased his copy,
and Congress as a result was able to use his e-mail in their investigation of
his felonious conduct in Irangate.

Poindexter may now realize that there are limits to file deletion, and since
1987 there have been a number of papers on "levels" of file delete.

But more broadly, there is in Poindexter and the Administration a naivete
(which is evident in the announcement of the purchase of Groove) about
Turing limitations as well as the tendency of large networks to join as the
result of one key gateway: a government Internet would become part of the
World Wide Web on the day ANY hacker created a simple gateway in a literal
sense.

  [I generally remove most of the interstitiated lines to which such
  point-by-point responses allude.  If you find this item curious, please
  refer back to the earlier message from Jerrold.  PGN]


TIA: Groove is simply a collaboration tool

<Stever Robbins <stever@VentureCoach.com>>
Tue, 07 Jan 2003 08:56:21 -0500

I think we're seeing a meta-Risk: the risk of evaluating risks without
enough understanding of the tools being discussed. In this case, Groove.

I've been puzzled by the discussion of Groove in TIA. Groove is simply a
piece of collaboration software. It lets you create a shared "workspace"
that can contain a threaded discussions, a shared calendar, instant
messaging, and shared files. You can also share a plug-in to share other
types of documents (for example, I use Groove with the Mindjet "Mind
Manager" plug-in, which lets me share mind maps with my colleagues).

It may have been chosen for TIA because Groove is a peer-to-peer
collaboration tool, a la the Napsters of the world, rather than hosting a
shared space on a central server. So there's no obvious place for terrorists
to eavesdrop if they wants to sabotage a Groove workspace; the space is
distributed among its members' PCs.

Groove does no detection or analysis of any sort. It's just a framework for
sharing information.

Check it out. You can download and use it for free from
<http://www.groove.net>. I tried it a few months ago and like it so much
I've been using it for a few projects I have going.

One side note: if TIA will depend on Groove, then perhaps those of us in
fear for our civil liberties needn't fear. Only about 60% of the people I've
had download it seem to be able to install it and get it working. (I think
it's written in Java, which apparently isn't as portable as one might wish.)


Re: TIA, surveillance, and Tolkien

<Monty Solomon <monty@roscom.com>>
Sat, 4 Jan 2003 13:57:23 -0500

Bush's Year of U.S. Surveillance, Noah Shachtman, wired.com, 2 Jan 2003

It may seem unreasonable, unfair and downright mean-spirited to
compare the Bush administration to the minions of Sauron, the
granddaddy of evil in The Lord of the Rings trilogy.  But here goes.

The executive branch's attempts in 2002 to peer into the lives of Americans
were more than a little similar to the exploits of Middle Earth's would-be
rulers.  Take, for example, the Bush team's most notorious proposal of the
year: the Total Information Awareness system.  TIA is an "ultra-large,
all-source information repository" meant to track citizens' every move, from
Web surfing to doctor visits, travel plans to university grades, passport
applications to ATM withdrawals.

For J.R.R. Tolkien fans, the scheme sounds eerily familiar.  ...

http://www.wired.com/news/privacy/0,1848,57005,00.html


REVIEW: "Building Linux Virtual Private Networks",

<Rob Slade <rslade@sprint.ca>>
Tue, 7 Jan 2003 08:22:49 -0800
  Oleg Kolesnikov/Brian Hatch

BKBLVPNS.RVW   20020916

"Building Linux Virtual Private Networks (VPNs)", Oleg
Kolesnikov/Brian Hatch, 2002, 1-57870-266-6, U$44.99/C$69.99/UK#34.99
%A   Oleg Kolesnikov oleg@buildinglinuxvpns.net ok@cc.gatech.edu
%A   Brian Hatch bri@buildinglinuxvpns.net brian@onsight.com
%C   201 W. 103rd Street, Indianapolis, IN   46290
%D   2002
%G   1-57870-266-6
%I   Macmillan Computer Publishing (MCP)/New Riders
%O   U$44.99/C$69.99/UK#34.99 800-858-7674 317-581-3743 info@mcp.com
%O  http://www.amazon.com/exec/obidos/ASIN/1578702666/robsladesinterne
%P   385 p.
%T   "Building Linux Virtual Private Networks (VPNs)"

Like "Practical UNIX and Internet Security" (cf. BKPRUISC.RVW) this book so
thoroughly covers its general field, in this case virtual private networks
(VPNs), that it is useful to security people regardless of whether or not
they use Linux.  There are abundant practical considerations in this work
that other volumes ignore.

Part one deals with the basics of VPNs.  Chapter one is a good, readable,
realistic introduction (and we will accept the mention of 40 bit DES in
IPSec as a typo: it is listed as such in the errata at the associated Web
site, http://www.buildinglinuxvpns.net).  The title of chapter two, VPN
fundamentals, is oddly both true and not: the items mentioned are not
factors of VPNs as such, but aspects and considerations of VPNs that
influence network choices, and network configurations that impel VPN
architecture.

Part two covers implementing standard VPN protocols.  Chapter three provides
a detailed and clear explanation of PPP (Point-to-Point Protocol) over SSH
(Secure Shell).  PPP over SSL (Secure Sockets Layer)/TLS (Transport Layer
Security), in chapter three, outlines the basics, increased security, and
scripts for troubleshooting.  Excellent coverage of IPSec in general, plus
some implementation details in Linux, is in chapter five.  Chapter six
explains FreeS/WAN from philosophy to source to configuration.  There is
good analysis of the design and weaknesses of PPTP (Point-to-Point
Tunnelling Protocol) and how to run it on Linux, in chapter seven.

Part three examines the implementation of nonstandard VPN protocols.
Chapter eight looks at the design, options, and setup of VTun.  The
lightweight cIPe is covered in chapter nine.  Designed for user level rather
than kernel operation, as well as more modern and robust cryptography, tinc
is explained in chapter ten.

I have not found, to date, a book that does a better job of explaining the
concepts and operations of virtual private networks.  This should become the
classic text.

copyright Robert M. Slade, 2002   BKBLVPNS.RVW   20020916
rslade@vcn.bc.ca  rslade@sprint.ca  slade@victoria.tc.ca p1@canada.com
http://victoria.tc.ca/techrev    or    http://sun.soci.niu.edu/~rslade


REVIEW: "Know Your Enemy", Honeynet Project

<Rob Slade <rslade@sprint.ca>>
Mon, 30 Dec 2002 08:05:18 -0800

BKKNYREN.RVW   20020916

"Know Your Enemy", Honeynet Project, 2002, 0-201-74613-1,
U$39.99/C$59.95
%A   Honeynet Project
%C   P.O. Box 520, 26 Prince Andrew Place, Don Mills, Ontario  M3C 2T8
%D   2002
%G   0-201-74613-1
%I   Addison-Wesley Publishing Co.
%O   U$39.99/C$59.95 416-447-5101 fax: 416-443-0948
%O  http://www.amazon.com/exec/obidos/ASIN/0201746131/robsladesinterne
%P   328 p. + CD-ROM
%T   "Know Your Enemy: Revealing the Security Tools, Tactics, and
      Motives of the Blackhat Community"

I have frequently said that any book with "hack," or any variant thereof, in
the title is automatically suspect.  This work helps prove my point, first,
because the Honeynet Project members have *not* used the term (they refer to
attackers as blackhats), and the text also notes the problems with "exploit"
type books: they list old and known attacks, most of which are protected
against, and say nothing about the attackers and how they work.  Chapter one
points out the value of "knowing the enemy" and the beginnings of the
Honeynet Project.

Part one describes the honeynet.  Chapter two explains what a honeynet is,
and the difference between one and the traditional honeypots.  Details on
how a honeynet works, in terms of architecture, policies, and the risks and
responsibilities of operating one, are presented in chapter three.  Building
a honeynet, in chapter four, presents specific details, although a number
have already been given.

Part two concerns the analysis of data collected from the Honeynet.  Chapter
five, on data analysis, points out the sources of data for logging, much of
which has already been discussed.  There is some more information on what we
can find, but limited explanation of how to interpret it.  The discussion of
analyzing a compromised system, in chapter six, is more detailed and does a
better job of explaining the logs, but relies on a blackhat document, which,
while better than most such, still has the holes and gaps that characterize
the genre.  Additional details are provided in advanced data analysis, plus
some material on data that is (and some that is not) useful in packets, plus
forensic (data recovery) considerations, in chapter seven.  (Interestingly,
the Honeynet Project does not seem to be concerned with wiping a drive in
order to deny information to blackhats.)  Chapter eight examines data
recovery tools and some results.

Part three explains what the project has determined about "the enemy" by the
types of attacks that have been launched and detected.  Chapter nine is a
general review of the random nature of attacks, the tools seen, motives
theorized, and trends in attacks.  The activities and signatures of the
Bymer worm are described in chapter ten.  An IRC conversation between a
group of blackhats is provided in chapter eleven.  While there is some
interest in the account, the transcript occupies almost 100 pages (and
almost a third of the total length of the book).  Chapter twelve suggests
the future activities of the Honeynet Project.

Much of the material in the book is repeated, sometimes in a number of
places.  The text would definitely benefit from a tightening up of the
material.  In addition, the early examples are not thoroughly explained,
making the reader initially feel that only a firewall audit log specialist
would be able to understand what is being said.  However, most of the book
is written clearly and well, and it is definitely worth reading.

copyright Robert M. Slade, 2002   BKKNYREN.RVW   20020916
rslade@vcn.bc.ca  rslade@sprint.ca  slade@victoria.tc.ca p1@canada.com
http://victoria.tc.ca/techrev    or    http://sun.soci.niu.edu/~rslade

Please report problems with the web pages to the maintainer

Top