The RISKS Digest
Volume 20 Issue 21

Friday, 12th February 1999

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…

Contents

Memo on Y2K
via Dave Stringer-Calvert
Y2K "fix" dates traffic offenses to 2097
Christopher Neufeld
Computer fraud as another kind of Y2K risk?
Bruce Martin
Judge moves to ban sale of self-help legal software in Texas
Doneel Edelson
Risks of using power wiring for data traffic
Dan Pritts
Hacking Web/FTP Servers
Ian Cargill
CERT Advisory CA-99.03 - FTP-Buffer-Overflows
CERT
Dangers of being the lowest price
Eytan Adar
"Secure" fax
Steve Bellovin
Our New Time Machine
Michael F. Hogsett
Re: The NT Blue Screen of Death
Michael F. Hogsett
Re: The risks of "standard" software?
Michael F. Hogsett
Re: Programming Errors
Thomas J Gilg
REVIEW: "Fighting Computer Crime", Donn B. Parker
Rob Slade
REVIEW: "Intrusion Detection", Terry Escamilla
Rob Slade
SEPG `99 - 11th Software Engineering Process Group (SEPG) Conference
Carol Biesecker
Info on RISKS (comp.risks)

Memo on Y2K (source unidentified)

Dave Stringer-Calvert <dave_sc@csl.sri.com>
Thu, 11 Feb 1999 11:46:49 -0800
  Dear Boss:

  I hope that I haven't misunderstood your instructions.  Because to be
  honest, none of this Y to K problem makes any sense to me.  At any
  rate I have finished the conversion of all of the months on all the
  company calendars for next year (year 2000).  The calendars have
  returned from the printer and are ready to be distributed with the
  following new months:

      Januark
      Februark
      Mak
      Julk

  I've also changed the following days:

      Mondak
      Tuesdak
      Wednesdak
      Thursdak
      Fridak
      Saturdak
      Sundak

  In general, all references to "Day" were changed to "Dak"
  (e.g. "President's Dak").  And all references to "Birthday" were
  changed to "Birthdak" (e.g. "Washington's Birthdak").

  I had a hard time deciding about "New Year's Day", "Martin Luther King,
  Jr. Day", "Yom Kippur", and "Hanukkah", but I finally changed them to "New
  Kear's Dak", "Martin Luther Ying, Jr. Dak", "Kom Yippur", and "Hanuyyah".

    [1 April is still 1.5 months away, but it is never too early.
    However, I wish I could attribute this to its (unknown) author.
    The pun on common parlance of using "i2j" for naming a transform
    from i to j is really delightful.  PGN]


Y2K "fix" dates traffic offenses to 2097

Christopher Neufeld <neufeld@physics.utoronto.ca>
Fri, 12 Feb 1999 10:09:05 -0500 (EST)
In the Ottawa Citizen daily newspaper for Feb 12, 1999, an article appears
about some Y2K silliness sending out notices of fines for traffic
infractions. Notices of tickets issued in summer of 2097 went out, with
warnings to pay before another date late in the twenty-first century.
Estimates on the number of incorrect notices vary, from 207 across the
province to 300 issued from a single court office.

Ministry of Attorney General spokesman Brendan Crawley is quoted as saying,
"It occurred on a production run while the company was working on making
itself Y2K compatible." Further down in the article he is quoted as saying,
"It was just a matter of transposing every number 19 with the number 20,
even when it wasn't right, and we've solved that problem."

One wonders how many companies are trying this particular windowing fix,
in which no dates prior to Jan 1, 2000 can be represented. Putting the
window in the year 2000 results in a rather severe discontinuity in the
behaviour of the program, as it goes from being unable to represent any
future dates to being unable to represent any past dates.  I'm also led to
wonder how many other companies are making and testing partial fixes on
production equipment.  I am not particularly comforted by the assurance that
the particular problem leading to these erroneous notices has been solved.

 Christopher Neufeld <neufeld@physics.utoronto.ca>
 http://caliban.physics.utoronto.ca/neufeld/Intro.html


Computer fraud as another kind of Y2K risk?

<Bruce_Martin@manulife.com>
Thu, 11 Feb 1999 12:35:44 -0500
Perhaps I've been reading too many Bruce Sterling novels, but it occurs to
me as I listen to various Y2K scenarios that no one has addressed the very
real possibility of computer fraud timed to coincide with the Year 2000.

Consider: The great majority of physical thefts are perpetrated under
circumstances that favour the anonymity of the thief. The morning of 1 Jan
2000 is widely predicted to be chaotic. Random losses of wealth are not only
possible but actually expected by many. (Certainly few insurance companies
would be willing to underwrite such losses.)

Consider also: In preparation for Y2K, virtually all major wealth-bearing
organizations are hiring vast teams of consultants to write and re-write the
billions of lines of code their wealth depends on. Most of these consultants
have never worked for their respective clients before, and many cannot
expect to do so again once the Y2K crisis has passed.

It should not be difficult for a lone, less-than-scrupulous consultant to
salt this sea of new and re-written code with just a few extra lines ...and
as a result redirect a significant fraction of an organization's wealth to a
blind account in the Cayman Islands at the stroke of midnight on 31 Dec
1999.

Who can prevent this? Likely not corporate auditors, too occupied with the
question of their systems' integrity to consider their consultants'
integrity. The possibility of recovering the missing funds will also be
greatly diminished in post-Y2K confusion ("Hey, we were *expecting* losses,
weren't we?"). In any event, the world is full of countries willing to
protect the anonymity of a new multi-millionaire immigrant.

And so we have motive, opportunity and a diminished likelihood of
retribution. It seems to me that the countdown to this sort of crime is
already underway.

Bruce Martin, Toronto


Judge moves to ban sale of self-help legal software in Texas

"Edelson, Doneel" <doneeledelson@aciins.com>
Wed, 3 Feb 1999 17:09:10 -0500
Judge moves to ban sale of self-help legal software in Texas;
Use of software is called unlicensed practice of law [AP item, 2 Feb 1999]

U.S. District Judge Barefoot Sanders is moving to ban the sale of self-help
legal software such as Quicken Family Lawyer.  Ralph Warner of Nolo Press
said he considered this a step 20 years back into the past.  [PGN Very Stark
Abstracting]

  [Judge the Quicken the Dead?  PGN]


Risks of using power wiring for data traffic

Dan Pritts <danno@ans.net>
Thu, 11 Feb 1999 13:57:45 -0500
http://cgi.sjmercury.com/premium/front/docs/devilphone11.htm

Summary: cable TV decoder that calls in every night to record pay-per-view,
combined with "wireless jacks" that send phone traffic across house power
wiring, seem to have given San Jose family a $500 phone bill for calls made
by someone else.

dan pritts, ans systems engineering, ann arbor, MI  uunet worldcom 734-214-7409


Hacking Web/FTP Servers

Ian Cargill <ian@soliton.demon.co.uk>
Fri, 12 Feb 1999 16:45:18 +0000
There have been many press items recently about FTP and Web servers being
hacked.  Indeed, RISKS-20.18 had a couple of submissions about hacked
software with Trojans/Trapdoors being placed on servers.  This is *so* common,
that I find it strange that there doesn't seem to be much demand for what I
would see as a good - though not complete - solution; write-protectable hard
drives.

Surely it would be very easy for HD manufacturers to produce drives with a
*physical* 'off' switch which made it impossible to write to a drive unless
you had physical access to the server.  You would prepare updates
'off-line', switch the server drive to 'writable', update all the necessary
files, then switch the drive back to 'write protected'.  A second, 'normal'
drive could be used to dynamically created pages.

I would have thought this easy, practical and going a long way to solving
the problem.  The seeming absence of any such drives suggests to me that I
must be wrong.  Can anyone explain to me why such a scheme would be
impractical or unworkable?

Ian Cargill  CEng MIEE, Soliton Software Ltd.


CERT Advisory CA-99.03 - FTP-Buffer-Overflows

CERT Advisory <cert-advisory@cert.org>
Thu, 11 Feb 1999 18:11:43 -0500
  [RISKS does not generally include CERT Advisories, because we
  assume those needing to know are already receiving them.  This
  one is excerpted, in light of Steve Bellovin's comments at several
  recent meetings to the effect that 8 out of the 13 CERT Advisories
  issued during 1998 involved security vulnerabilities caused by
  buffer overflows.  That alarming ratio deserves greater attention.
  Here is one for 1999, affecting many different platforms.  PGN]

CERT Advisory CA-99-03-FTP-Buffer-Overflows

   Original issue date: February 11, 1999

   Topic: Remote buffer overflows in various FTP servers leads to
   potential root compromise.
   Source: Netect, Inc.

   To aid in the wide distribution of essential security information, the
   CERT Coordination Center is forwarding the following information from
   Netect, Inc. Netect, Inc. urges you to act on this information as soon
   as possible. See Appendix C for Netect, Inc. contact information.
   Please contact them if you have any questions or need further
   information.  [...   <http://www.netect.com/>]

[The entire advisory is available from:
   http://www.cert.org/advisories/CA-99-03-FTP-Buffer-Overflows.html ]


Dangers of being the lowest price

Eytan Adar <adar@parc.xerox.com>
Mon, 8 Feb 1999 17:31:12 PST
An interesting article appeared today on Wired's on-line site
(http://www.wired.com/news/news/business/story/17803.html).  Apparently,
Buy.com made a mistake in its pricing of a Hitachi monitor and listed it as
$164.50.  This monitor was in fact $588.

So 48 hours later, and with 1600 monitors purchased, Buy.com has a public
relations nightmare on its hands.  The cost of this "typo" will be around
$320,000 if Buy.com actually fulfills the order.

Aside from the obvious questions like, why they didn't notice a sudden blow
up in orders for this monitor?, there is an interesting issue regarding
Buy.com's policy of being the lowest price on the net.

My understanding, and I could be wrong about this, is that Buy.com actually
has (ro)bots (automated agents) roving the net looking for cheaper prices.
If they find a cheaper price the price automatically gets dropped on their
site.  Even if the process isn't driven by a bot but by a human I think the
risk is still valid...

Now I can't say for sure that this is what happened, but you can see the
obvious danger here.  A retailer (that Buy.com competes with) somewhere on
the net may have made its own mistake.  The bot, not knowing any better,
would have carried that price back to Buy.com.  The other alternative, of
course, is that someone could maliciously have set the price low.  Either
way, the "price virus" gets transmitted by an ignorant bot back to parent
site, and we're back to our public relations nightmare.

e-commerce... gotta love it...

Eytan Adar

  [If you are not careful, you just bot the farm.  PGN]


"Secure" fax

Steve Bellovin <smb@research.att.com>
Thu, 11 Feb 1999 12:03:55 -0500
The 15 Feb 1999 issue of *Newsweek* describes an Internet-based fax product.
You sign up with them and get a 10-digit phone number; faxes to that number
are emailed to you.  This is described by *Newsweek* as good for
confidential faxes, since it bypasses the company fax machine.  There's no
mention about the risks of sending confidential information through a third
party.

Trying to learn how this company protects your information is itself a bit
amusing, since *Newsweek* may have gotten the name wrong.  In the on-line
version at least, it's listed as www.e-fax.com, a site that is apparently
under construction.  Did *Newsweek* mean www.efax.com, which offers a similar
service?  Its pages demand a careful read-through on the subject of
security.  Among other things, one learns that faxes are "protected" by a
password — they seem to avoid the word "encrypted", which may be a clue.
And even that level of protection is only available if you use their viewer
on a (of course) Windows platform; users of other systems (whose existence
they at least acknowledge the existence of!) are sent unprotected TIFF
files.  There's noo mention of anything like PGP.

I should note that at least in the press releases accessible via the e-fax
Web site, they make no claims about the superiority of their product for
confidential material.  That seems to be *Newsweek*'s spin.  Efax does
promise to be careful with your data, though.

One more risk — it takes a lot of wading through the fine print of the
privacy policy to realize that you're signing up to receive electronic junk
mail.  This is apparently an advertising-supported service, which is not in
itself wrong or evil — they should just say so in a more upfront fashion.

Steve Bellovin


Our New Time Machine

"Michael F. Hogsett" <hogsett@csl.sri.com>
Thu, 11 Feb 1999 12:26:06 -0800
It appears as though our new switch / router doubles as a time machine.

I was performing a few tests, one of which was a flood ping.  The minimum
round-trip time has been consistently negative...

It is either sending ICMP replies from the future or anticipating them...

  # ping -f 192.168.1.10
  PING 192.168.1.1 (192.168.1.10): 56 data bytes
  ................
  --- 192.168.1.10 ping statistics ---
  2583 packets transmitted, 2568 packets received, 0% packet loss
  round-trip min/avg/max = -8.0/1.9/7.1 ms

(Well, OK, the most likely thing is that there is a bug in the ping program
under Linux... )

Mike

  [Note: The IP address has been altered to protect the innocent.  PGN]


Re: The NT Blue Screen of Death (RISKS-20.20)

"Michael F. Hogsett" <hogsett@csl.sri.com>
Thu, 11 Feb 1999 09:48:27 -0800
> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\CrashControl\AutoReboot to 1.
> Once you've changed this value, NT will reboot after writing the crash log
> file.

Assuming of course that the crash did not corrupt the data structure storing
the 1, replacing it with an invalid value.

Michael Hogsett


Re: The risks of "standard" software? (RISKS-20.20)

"Michael F. Hogsett" <hogsett@csl.sri.com>
Thu, 11 Feb 1999 09:52:15 -0800
> Nobody uses that size anymore, because Word doesn't use it.  Therefore it is
> no longer a standard size, and no longer a standard stock item.

So assume that if Word no longer prints onto 8.5 x 11" paper that the entire
industry will stop producing it.

Michael Hogsett


Re: Programming Errors (Gilham, RISKS-20.18)

"GILG,THOMAS J (HP-Corvallis,ex1)" <Thomas_Gilg@ex.cv.hp.com>
Mon, 8 Feb 1999 13:46:49 -0800
> [...]  In two days he has reports three
> instances of the following common C error:
>   if (x = y)     instead of     if (x == y)

Sorry, but another common C error is to assume the above.  Consider
if the intent of the expression was:

   if ( pChar = pMyString ) {
      // increment pChar through my string looking for tokens
      .....
   }

Granted the more visually obvious coding style would have been:

   if (pMyString) {
      pChar = pMyString
      // increment pChar through the string looking for tokens
      .....
   }

Thomas Gilg <tomg@cv.hp.com>


REVIEW: "Fighting Computer Crime", Donn B. Parker

Rob Slade <rslade@sprint.ca>
Wed, 10 Feb 1999 12:19:41 -0800
BKFICMCR.RVW   981106

"Fighting Computer Crime", Donn B. Parker, 1998, 0-471-16378-3,
U$34.99/C$49.50
%A   Donn B. Parker dparker@sric.sri.com
%C   5353 Dundas Street West, 4th Floor, Etobicoke, ON   M9B 6H8
%D   1998
%G   0-471-16378-3
%I   John Wiley & Sons, Inc.
%O   U$34.99/C$49.50 416-236-4433 fax: 416-236-4448 rlangloi@wiley.com
%P   512 p.
%T   "Fighting Computer Crime: A New Framework for Protecting Information"

Parker feels that too much of the data security field concentrates on
technical answers to the problems of reliability, integrity, and
availability of data, and doesn't pay sufficient attention to those people
who are deliberately out to read, steal, or ruin your information and
systems.  Personally, I find it rather ironic that he defines "crimoids," in
chapter one, as minor events promoted to much higher significance by the
media, and public misperceptions.  In the non-specialist realm, more people
spend more time worrying about "hackers" than ever back up their drives.  (I
am reminded of a friend; an intelligent and educated person who started his
career programming large and sophisticated information systems and who has
now risen to the executive ranks; who has for years refused to get a modem
for his home computer.  In spite of his frequently expressed desire for
access to the Internet, and my repeated assurances that with his current
computer and operating system there is no hidden danger, he remains
convinced that the mere attachment of a modem to his machine will allow
someone to break into his computer and damage it.)

Who, then, is this book written for?  The author does not say, but what he
does say in the preface seems to indicate that he is not writing for those
whose business cards make reference to security.  (I have neither argument
nor inclination to dispute Parker's assertion that security "professionals"
do not really deserve the designation.)  But if this text is aimed at the
general public, chapter one's emphasis on the dangers and lack of protection
would seem more inclined to incite further panic, rather than a realistic
and measured response.

Chapter two is an interesting and useful examination of an often unasked
question in the field: what is the nature of the information we are
supposedly securing?  There are valuable side points, such as both the
danger and the opportunity in the security arena presented by the Year 2000
problem.  At the same time, I have to note that an erroneous description of
the Cascade virus is an example of Parker's asserting points that are just
beyond the available facts, and, for me anyway, has an unfortunate effect on
the trustworthiness of the work as a whole.  The review of cybercrime, in
chapter three, has more reference to journalism and other forms of fiction
than to reality, but I have to agree with everything said there.  Computer
misuse and abuse is discussed in chapter four.  (As if to make up for
chapter two, the section on viruses is very good.)  Network misuse is
covered in chapter five, and although I still have trouble believing in the
reality of salami attacks (Parker's sole example is said to have resulted in
a conviction, but no citation is given) I am a bit more willing to accept
his broader definition.  Chapter six is extremely strong in portraying a
realistic and broadly based analysis of characteristics of computer
criminals.  A similarly informed and balanced approach distinguishes chapter
seven, regarding hacker culture, but there is also a universally
condemnatory tone that is not wholly justified by the facts as presented.
Chapter eight is a very helpful first step for those wanting to deal in the
art of computer security.

Chapter nine reviews the deficiencies in most current security practices,
noting overprotection in some areas while ignoring loopholes in others, and
a flowery jargon that serves mostly to hide the fact that security people
just don't feel very comfortable with what is going on.  However, Parker's
new model of security, in chapter ten, while it is very clear and useful,
does not extend recent work in, say, electronic commerce.  On the one hand,
this congruence does support the model, but on the other, one can't really
say it is too novel.  The popular, but demonstrably incomplete, risk
assessment study is de-emphasized in favour of a more difficult, but more
realistic, baseline security standard in chapter eleven.  Details on how to
conduct such a study are very helpfully given in chapter twelve, although
the benchmark chart is going to be much harder to come by than is made clear
in the text.  Chapter thirteen provides a practical and useful set of
criteria for determining control objectives.  A number of security tactics
are detailed in chapter fourteen.  Chapter fifteen takes the larger
strategic view.  (I was delighted to see the inclusion of a section on
corporate ethics in this chapter.  Recently I contracted to produce a
security document for an educational institution, and was told to take the
section on ethics out.)  Management of security, in chapter sixteen,
includes provisions for training, policy, and other factors.  Chapter
seventeen finishes off with a look to the future.  The material, while
thought- provoking, is possibly more likely to generate arguments than
solutions.

Parker's stance on security in general definitely puts him in the camp of
the professional paranoids.  However, absent the first and last chapters,
there is a lot of good, solid knowledge here to help educate any security
practitioner.  The material in the second half of the book is just as
valuable to the security process as the more technical works such as
"Practical UNIX and Internet Security" (cf.  BKPRUISC.RVW) by Spafford and
Garfinkel, albeit in quite a different way.  An informed security policy is
every bit as important as a good set of "access" controls.

copyright Robert M. Slade, 1998   BKFICMCR.RVW   981106
rslade@vcn.bc.ca  rslade@sprint.ca  robertslade@usa.net  p1@canada.com


REVIEW: "Intrusion Detection", Terry Escamilla

Rob Slade <rslade@sprint.ca>
Fri, 12 Feb 1999 08:33:14 -0800
BKINTRDT.RVW   990108

"Intrusion Detection", Terry Escamilla, 1998, 0-471-29000-9,
U$39.99/C$56.50
%A   Terry Escamilla
%C   5353 Dundas Street West, 4th Floor, Etobicoke, ON   M9B 6H8
%D   1998
%G   0-471-29000-9
%I   John Wiley & Sons, Inc.
%O   U$39.99/C$56.50 416-236-4433 fax: 416-236-4448 rlangloi@wiley.com
%P   348 p.
%T   "Intrusion Detection: Network Security Beyond the Firewall"

Maybe my perception is skewed from having been involved with physical
security as well as the computer kind, but I see intrusion detection
as being part of security.  There is no security system that cannot be
penetrated or bypassed, and so detection is, in my view, simply a fact
of security life.  Isn't that what auditing, one of the main pillars
of data security, all about?  So I find the attempt to sell the idea
of intrusion detection somewhat redundant.  Then there is the emphasis
on reviewing commercial Intrusion Detection Systems (IDS).

Part one looks at what happens before intrusion detection: the
traditional role and model of computer security.  Chapter one provides
a brief, but reasonably sound, overview of this classic paradigm,
concentrating on defining most of the theoretical terms used.  Some
identification and authentication details from both UNIX and Windows
NT start our chapter two, which then meanders through a few examples
of password cracking, and finally ends with a look at ticket granting
systems and other authentication improvements.  A similar look at
access control is provided by chapter three.  Given the complexity of
networking and network security, the number of topics covered in
chapter four is unsurprising.

Part two looks at intrusion detection by extending the traditional
security design.  Chapter five is fairly pivotal, as evidenced by the
title "Intrusion Detection and Why You Need It."  The "why" part comes
first, with a rather weak example showing that security systems can
have loopholes if you don't configure or program everything properly.
Intrusion detection then seems to be defined as the usual game of find
vulnerability-fix-repeat, only in automated form.  A number of
possible attacks are mentioned in chapter six, and then a promotion of
the addition of an IDS layer to a system, without a corresponding
reiteration of the warning, from chapter four, that layers in a system
increase the possibility of loopholes.  I was rather astonished that
SATAN [Security Administrator's Tool for Analyzing Networks] was not
included with the vulnerability scanners mentioned in chapter seven.
Two more sophisticated products are reviewed in chapter eight.
Chapter nine looks at the possibility of catching intruders by traffic
analysis, although "catch" seems to be too strong a term to use here.
Since most of the foregoing deals with UNIX, chapter ten looks at
similar products for NT, although most of the material seems to
concentrate on NT's own audit logs.

Part three looks at dealing with an intrusion once you have detected
it.   Chapter eleven recommends being prepared well, detecting early,
analyzing thoroughly, and deciding judiciously.  In one useful piece
of advice, it recommends against an attack on a system you may think
is hitting on yours.  Chapter twelve is a quick summary of the book.

As the author admits, in the final chapter, that intrusion detection
systems are not the final word in computer security, I am inescapably
reminded of the battles in the antiviral field over the relative
strengths of scanners, activity monitors, and change detection
systems.  What works best?  A combination approach, of course.  The
price of a secure system is more budget for administration time and
tools.  This book does not present any radically new approach or
technique for system security.  In fact, with the emphasis on
proprietary commercial products, the work will date quite quickly.
For those who are looking to add an automated IDS to their current
network, the volume could act as a kind of incomplete buyer's guide.

copyright Robert M. Slade, 1999   BKINTRDT.RVW   990108
rslade@vcn.bc.ca  rslade@sprint.ca  robertslade@usa.net  p1@canada.com


SEPG `99 - 11th Software Engineering Process Group (SEPG) Conference

Carol Biesecker <cb@SEI.CMU.EDU>
10 Feb 1999 20:14:55 GMT
SEPG `99 - The 11th Software Engineering Process Group (SEPG) Conference
Theme: Software Process Improvement (SPI) Investments Today for
       a Changing Tomorrow
March 8-11, 1999
Hyatt Regency Atlanta, Atlanta, Georgia

For complete details, including the preliminary program, and
registration information, visit the SEI Web site at:
  http://www.sei.cmu.edu/products/events/sepg/

Customer Relations
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213-3890
Phone, Voicemail, and On-Demand FAX: 412 / 268-5800
E-mail: customer-relations@sei.cmu.edu
World Wide Web: http://www.sei.cmu.edu/products/events/sepg/

Please report problems with the web pages to the maintainer

x
Top