The RISKS Digest
Volume 20 Issue 64

Thursday, 4th November 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

Yet another cracked stooopid crypto scheme...
Frank Stevenson via Lenny Foner
A Risk of disk caching
Erling Kristiansen
Single-Sourcing at the FAA
Eriks A Ziemelis
Re: Aircraft computer redundancy, airline safety
Paul Wallich
Re: Y2K creates "horseless carriages"
Ted Doty
Cornell University Revisits Spring 1900
James Byers
Bush campaign site hacked
Avi Rubin
IP blocking
Lindsay Marshall
INS Irony Explained
Paul Robinson
Fibers Cut in Massachusetts
Rich
Typing fast, and a fast computer are not necessarily good!
Vicky Larmour
Printers are too smart to handle "dumb" jobs
Leonard Erickson
Complexity in operating systems and programming languages
Diomidis Spinellis
Re: DC Metro Relays
David Lesher
BlackICE Defender Security woes
tlb
10-day deactivation warning from Network Solutions takes 13 days
Stuart Woodward
40 vs. 128 bit browsers
Jeremy Epstein
New Australian RISKS Archive
WestyX
Call for papers, Malicious Information Technology
Jeffrey Voas
Info on RISKS (comp.risks)

Yet another cracked stooopid crypto scheme...

Lenny Foner <foner@media.mit.edu>
Wed, 27 Oct 1999 12:00:52 -0400 (EDT)
...and yet another example of why security through obscurity, not to
mention non-peer-reviewed design of cryptosystems, is just dumb.  Not,
I imagine, that anyone but the vendors is going to complain.

This means that DVD encryption can be cracked is something like a tenth of a
second.  And the next message in the thread points out that the known
plaintext part is easy, too.

[Note: if you follow the URL, it appears that the message got automatically
mangled by the software that threads messages into web pages; the .Z has
many mailto:'s that shouldn't be there...]

- - - Begin forwarded message - - -

Date: Wed, 27 Oct 1999 14:54:17 +0200 (CEST)
>From: Frank Andrew Stevenson <frank@funcom.com>
To: cryptography@c2.net
Subject: CSS broken

Monday sourcecode for the CSS algorithm was released through an anonymous
remailer. CSS is the encryption algorithm used on DVD movies, and it was
suspected that it was weak beyond just having a 40 bit key. Yesterday I
found it to be vulnerable to a trivial 2^16 attack with as little as 6 bytes
of known plaintext.

I posted the details on:
http://livid.on.openprojects.net/pipermail/livid-dev/1999-October/000589.html

  frank


A Risk of disk caching

Erling Kristiansen <ekristia@xs4all.nl>
Fri, 22 Oct 1999 20:01:52 +0200
I do most of my typing in Frame Maker on a UNIX system. When I send
documents, I print to a pdf file and attach it to an Email.

My company uses Lotus Notes as our standard mail platform. For most
users, including myself, Notes runs on a Win95 platform. My PC mounts
the disk of the UNIX system as a network drive, so I can include the pdf
attachment directly from the UNIX disk into Notes.

Today, I did just that.

The recipient called me with a few modifications to the document I had
just sent him.

I did the modifications, and repeated the process of generating pdf and
attaching to an email. Note that, in this process, the new pdf file
replaced the old one. The old file therefore no longer existed
explicitly anywhere.

The recipient called me and said: You sent me the old version of the
document. Can I please have the updated one.

I investigated a bit, and discovered that, consistently, once a file
with a given name has been included as a Lotus Notes attachment, this
version of the file will be attached to subsequent mails that call for
this attachment, even if the contents of the original file has changed!

Though I have not attempted to understand the deeper logic of this, it
looks like a disk caching that is unaware that somebody else may have
changed a file on a networked drive, so it gives you the cached version
whenever this file is called for.

In this case, no harm was done, but I can imagine quite a few "nice"
scenarios resulting from obsolete files being distributed instead of current
versions.


Single-Sourcing at the FAA

Eriks A Ziemelis <eazy@ecae.stortek.com>
Thu, 21 Oct 1999 08:58:17 -0600
From "The Chicago Tribune", 10/21/1999:
http://chicagotribune.com/news/metro/chicago/article/0,2669,ART-36492,FF.html

Thomas A. Varlotta stands accused of destroying the lone copy of source code
for a system to transfer flight control data between the control tower at
O'Hare airport and a control center in Elgin, IL.  Luckily, in a raid on
Varlotta's home, authorities recovered an encrypted copy of the source code
and managed to decrypt it in six months. Otherwise, 3-5 more years to
rewrite the software.

Quote the FAA: "It's an efficiency issue, not a safety issue."

Paraphrasing the Department of Transportation investigator: Why did only one
person have the source code?  "I'm just a layman," Harper said. But "that
doesn't sound like a good business practice," he said.

Comment #1: Not a safety issue? The old method of transferring data,
according to the article, was via telephone. Someone mishears and/or
transcribes the data incorrectly, anything in place to catch problems when a
controller call out the wrong plane, a dangerous course correction/altitude
change? Maybe not a safety issue, but, not comforting.

Comment #2: Noone heard of backups at the FAA? Varlotta was not working
alone on the project: noone else had a copy? FAA is not backing up their
software? We backup our software here every night and I still make a backup
of my own every other day, just to be analy-safe.


Re: Aircraft computer redundancy, airline safety (Olson, RISKS-20.63)

Paul Wallich <pw@panix.com>
Sun, 17 Oct 1999 10:21:04 -0400
There are a lot of redundant items in your typical aircraft cockpit so that
the plane doesn't fall out of the sky if one of them fails. If memory
serves, the A320 has three flight computers, any one of which can handle the
aircraft. Flying with two out of three would not then be a problem, even if
you would prefer all of them functioning for maximum reliability. (And one
would expect that the confused box would be swapped out or otherwise fixed
overnight, without as much inconvenience to passengers.)

What would be a problem would be flying with one of your flight computers in
operation but malfunctioning so that there would be arguments among them
about what the plane was doing.

Paul Wallich                        pw@panix.com


Re: Y2K creates "horseless carriages" (Griffith, RISKS-20.63)

"Doty, Ted (ISSAtlanta)" <TDoty@iss.net>
Thu, 21 Oct 1999 18:48:36 -0400
>AP reports that a Y2K glitch has caused 2000 new vehicle registrations in
>the state of Maine to bear the classification "horseless carriage".
>Apparently, the DMV software misread the 2000 model year as 1900, and it is
>hardwired to classify any vehicle with a model year before 1916 as a
>horseless carriage.

This smells like an urban legend.  Can you imagine a programmer at the DMV
titling a category as "horseless carriage", or even a faceless bureaucrat
specifying that name?  It's unlikely that the DMV was computerized earlier
than the 1960s, and that term just doesn't sound likely.

>http://www.mercurynews.com/breaking/docs/024281.htm"

---This link is dead, adding to the suspicion.  I think someone was pulling
their legs (successfully), and they got caught.

- Ted

Ted Doty, Internet Security Systems          | Phone: +1 678 443-6000
6600 Peachtree Dunwoody Road, 300 Embassy Row  | Fax:   +1 678 443-6479
Atlanta, GA 30328  USA                       | Web: http://www.iss.net


Cornell University Revisits Spring 1900

James Byers <jwb19@cornell.edu>
Tue, 19 Oct 1999 14:47:05 +0000
On 16 Oct 1999, Cornell University seniors registering for classes via the
online CoursEnroll system were greeted by the following splash screen text:
"Use this service to enter your pre-enrollment requests for the Spring 1900
semester."  Following this screen, the main application window proclaimed in
a large font: "CoursEnroll for Spring 1900."  The glitch was quickly
corrected.

The relevant Cornell Y2K status page
(http://www.cit.cornell.edu/y2k/services.html) states the service (Just the
Facts) will be compliant sometime in October 1999.  Enumerating the usual
set of Y2K jitters is an exercise left to RISKS readers.

On the bright side, perhaps Cornell will finally offer those long-awaited
classes in horseless carriage design come spring...

James Byers (jwb19@cornell.edu)


Bush campaign site hacked

Avi Rubin <rubin@research.att.com>
Wed, 20 Oct 1999 11:56:51 GMT
>From the AP news wire:

The day after presidential candidate George W. Bush redesigned his
campaign's Web site, hackers vandalized it by replacing his photo with a
hammer and sickle and calling for "a new October revolution."

Avi Rubin


IP blocking

<Lindsay.Marshall@newcastle.ac.uk>
Mon, 18 Oct 1999 13:08:04 +0100 (BST)
This was brought to the attention of readers cam-list recently:

<http://www.zdnet.com/zdnn/stories/news/0,4586,2352917,00.html>

"For a month or so earlier this year, DoubleClick Inc., an Internet
advertising firm based in New York, furtively put up three different
editions of its home page. Most visitors saw one version, highlighting the
firm's accomplishments. Employees of a rival firm could see only another
version, with a special press release touting DoubleClick's capture of one
of the rival's customers. Clients being wooed saw only a third version."


INS Irony Explained

<Rfc1394a@aol.com>
Mon, 18 Oct 1999 06:31:21 EDT
Someone wrote to ask me about the article I posted to Risks.  Since the irony
was not evident to someone it might not be evident to others so I thought I'd
explain for the benefit of those who might not get it

I wrote,
<> The following item was reported in the UK's Silicon.Com weekly round-up:
<>
<> The US government admitted this week that it had accidentally issued
<> more visas for foreign high-tech workers than it had intended - 20,000
<> to be precise. Why? Because of a computer glitch. Irony once again
<> rears its ugly head and slaps the authorities around the face with a wet
fish.

To which a reader replied:
>  Apart from the irony, I wonder why this is a problem? World-wide there
>  are not enough high-tech workers, so getting an extra 20,000 sounds
>  to me like a bonus not a problem.

The irony being that too many trained technical people, such as
computer programmers, were admitted than were allowed by law,
yet it implies that INS apparently does not have enough trained
computer programmers to keep this sort of mistake from happening!

Paul Robinson <rfc1394a@aol.com>


Fibers Cut in Massachusetts

<rich@wisdom.wsc.ma.edu>
Mon, 18 Oct 1999 10:30:36 -0400
> From our ISP:

> At about 2:30am Saturday morning (10/16) a catastrophic fiber cut occurred
> on the Mass Turnpike.  Literally, the classic backhoe scenario.  AT&T (288
> strands), MCI Worldcomm (12 strands) and the MTA (Mass Turnpike Authority,
> don't know how many strands but MITI's are among them) had their fiber
> severed.  This is an outage affecting people all up and down the east
> coast.  Don't be surprised if your bank machine won't dispense you cash
> today.


Typing fast, and a fast computer are not necessarily good!

Vicky Larmour <vicky.larmour@camcon.co.uk>
Wed, 20 Oct 1999 14:23:05 +0100
I often wish I could type faster, and that I had a faster computer, but
yesterday I wished my typing was slower and I had a slower computer!

I was inputting some text (ironically, software test details!) into an
Excel 97 spreadsheet by typing the contents of one cell, pressing return,
typing the contents of the next cell down, etc.

All was going well until suddenly, seeingly without warning, my Excel
window simply disappeared and I was left wondering what on earth was going
on. I re-started Excel and discovered I had lost an hour's rather tedious
work, so I set about trying to work out why. After a little probing, it
dawned on me. At the time Excel disappeared, I had been entering the text
// cannot be tested in test harness
in a cell.

This is what happened as I typed that text:
- Evidently, Excel 97 treats a forward slash as an ALT press (highlighting
the File menu button), if a cell is selected but not being edited.
- the second forward slash was ignored
- the space key caused the application window menu to drop down.
- the "c" selected the "close" option from that menu, which brought up a
dialog box saying "Do you want to save? Yes / No / Cancel".
- the "a" was ignored
- the "n" activated the "No" option on the dialog box.
- poof! Excel closed without saving.

All this happened in the blink of an eye, as I typed, so I didn't even get
to see the dialog box that might have stopped me in my tracks. It was only
by careful reconstruction of exactly what I had been doing that I worked
out what had happened.

The RISKS? Undocumented and inconsistent keyboard shortcuts - why should
forward slash be treated as an ALT press, but not if I am already editing
text in a cell? Why isn't this listed in the keyboard shortcuts in the
Excel help?

[Extra RISK: My work hadn't been auto-saved because in Excel 97, you have
to install the AutoSave Add-in if you want auto-save, which isn't something
I had explicitly thought to do (but now have!). If Auto-save had been an
item on the tools menu from the start, I might well have noticed it and
switched it on!]

Vicky


Printers are too smart to handle "dumb" jobs

Leonard Erickson <shadow@krypton.rain.com>
Sat, 16 Oct 1999 23:39:19 PST
There's been an interesting discussion going on on Fidonet's TECHNICAL echo
recently. It started when an echo participant asked if anyone knew of *new*
printer models that could merely be hooked up to a standard printer port and
used to dump text data to.

Why was he asking? Because he'd just had the customer service departments of
*every* printer company he called, said that their current model printers
*will not* print except under Windows, with appropriate drivers loaded!

Since he works for the miltary, and was trying to come up with a printer his
section could recommend for dumping logging data from some embedded (and
very much *non* Windows) equipment, this was somewhat less than useful.

Further checking has come up with *one* printer line, and that one is
expensive industrial grade equipment intended for very heavy use.

However, tests by some readers have shown that *some* "current model"
printers *will* print plain text just fine. But others that are ostensibly
the "same model" won't.

The risk? Windows has become so common that an important piece piece of
hardware is in danger of becoming unusable *without* it. At least unless you
can guarantee a *huge* market or afford custom orders.

Or, more likely, Windows has become so prominent that it's impossible to get
a *non*-Windows answer from customer support.

Either way, this is going to become a real problem as more older printers go
out of service.

I *was* thinking about throwing out some old Epson printers. Now I think
I'll hold onto them.

Leonard Erickson (aka Shadow)  shadow@krypton.rain.com


Complexity in operating systems and programming languages

Diomidis Spinellis <dds@sena.gr>
Mon, 18 Oct 1999 12:02:11 +0300
A number of contributors to previous digests have stressed the risks
associated with increasingly bloated software applications.  Unfortunately
the same issues permeate a number of facets of the software industry.
Consider operating systems and programming languages which are becoming
increasingly complicated and their implementations less trustworthy.  The
following table [1] contains the number of documented system calls for some
popular Un*x system versions:

Operating System    Year    Number of
                        system calls
First Edition Unix  1971     33
Seventh Edition Unix    1979     47
SunOS 4.1       1989    171
4.3 BSD Net 2       1991    136
HP-UX 9.05      1992    219
SunOS 5.4       1994    163
Linux 1.2       1996    211
SunOS 5.6       1997    190
Linux 2.0       1998    229

The Windows platform with 3433 API calls (up to NT4 SP3) belongs to a
different league; the associated problems are documented elsewhere [2].
A system call defines an interface to the operating system; more system
calls increase the complexity of the operating system needed to support
them, provide additional opportunities for unwanted interactions between
them, and increase the chances of overlooked security loopholes.

This increasing complexity has important implications for the reliability of
software developed for a specific platform. Complicated interfaces are
difficult to learn and use effectively. As a result of their size and
complexity, modern operating systems exhibit an increasing number of bugs;
demonstrated by the numerous "fixes" distributed by their vendors.
Developers of robust applications have to take this into account coding
around them, or insist on the installation of all relevant fixes.  Some
fixes may introduce new errors or render other system components
inoperative. The bottom-line of this situation is, that the application
developer is practically rarely singly responsible for the reliability of an
application.

Similarly to operating systems, programming languages also have a tendency
to grow in size and complexity as they mature. Taking as a rough measure the
page number of the language's canonical description the following table
provides an illustration of the evolution of the C and C++ programming
languages:

Book Title                      Year    Pages
The C Programming Language (Kernighan and Ritchie)  1978    228
The C Programming Language; second edition      1988    272
The C++ Programming Language (Stroustrup)       1986    328
The C++ Programming Language; second edition        1991    669
The C++ Programming Language; third edition         1997    910

This trend has important implications for the developers of high-reliability
systems. Large languages are difficult to learn and use [3]. It is nowadays
not uncommon for programming teams to lack people who understand the whole
language at a level sufficient to advise other members on issues regarding
the interrelationship between language elements. Subtle bugs arising from
the misunderstanding of language features can thus survive code
walkthroughs. In addition, language complexity and advanced optimisation
techniques combined with processor complexity results in an increased number
of bugs in modern compilers.  This is clearly an additional risk factor for
high-reliability designs.

[1] Diomidis Spinellis. Software reliability: Modern challenges. In G.
I. Schueller and P. Kafka, editors, Proceedings ESREL '99 - The Tenth
European Conference on Safety and Reliability, pages 589-592,
Munich-Garching, Germany, September 1999. ESRA, VDI, TUM, A. A. Balkema.
http://kerkis.math.aegean.gr/~dspin/pubs/conf/1999-ESREL-SoftRel/html/chal.html
[2] Diomidis Spinellis. A critique of the Windows application
programming interface. Computer Standards & Interfaces, 20:1-8, November
1998.
http://kerkis.math.aegean.gr/~dspin/pubs/jrnl/1997-CSI-WinApi/html/win.html
[3] C. A. R. Hoare. Hints on programming language design. In Ellis
Horowitz, editor, Programming Languages: A Grand Tour, pages 31-40.
Computer Science Press, 1983. Reprinted from Sigact/Sigplan Symposium on
Principles of Programming Languages, October 1973.

Diomidis Spinellis, University of the Aegean


Re: DC Metro Relays (RISKS-20.63)

David Lesher <wb8foz@nrk.com>
Thu, 21 Oct 1999 11:15:01 -0400 (EDT)
> The Washington DC Metro has had rampant failures among its electronic
> relays, and as a result has been running the entire system manually ...

Note these appear (from past press photos & descriptions) to be
time-proven, dirt-ordinary, railroad-standard relays, such as have
been used since oh, the era of Tom Thumb and/or the Golden Spike.

Everyone talking has been head-scratching; metallurgists and other
specialists consulted to no avail.

We spend a lot of time in RISKS discussing new, unproven, technologies & the
dangers lurking within same. But this appears to be an old old one that
suddenly has fallen into the gutter for reasons unknown. I find this very
disturbing.


BlackICE Defender Security woes

"tlb" <tomeuchre@yahoo.com>
17 Oct 1999 03:48:31 GMT
I just recently purchased the BlackICE defender program to protect my
computer against internet hackers and other co-workers. While scanning the
unprotected, unencrypted raw logs of the program, what do you think I found?
The SMTP dialog between my mail program and my Mail server, complete with
the account and password right out there in the open.  Quite ironic that a
company selling a product to ensure security and system integrity actually
created a gaping hole.  braz@mnw.net (a 2-day user of BlackICE Defender --
the product won't see 3 days on my machine).


10-day deactivation warning from Network Solutions takes 13 days

Stuart Woodward <stuart@gol.com>
Sat, 30 Oct 1999 13:55:29 +0900
Due to an oversight on my behalf, payment to Network Solutions for the
renewal fee for one of my domains was overlooked and in time I received a
reminder that it needed to be paid. The reminder comes via an ordinary
postal letter. So as soon as I got the reminder, I logged on and paid the
fee at the Network Solutions website.

Since the postal letter took some time to arrive, a Deactivation Notice from
Network Solutions had already been dispatched. When it arrived today it gave
me a fright because the letter, giving me a final 10 days to pay, was dated
17th October 1999 and it only arrived here in Japan via Amsterdam(!) on the
30th of October.

To me this poses two questions: Why doesn't Network Solutions send an e-mail
reminder to the Billing Contact when they send out the postal mail and why
do they use such a slow postal delivery service for such time sensitive
information?


40 vs. 128 bit browsers

Epstein Family <jepstein@mail.mnsinc.com>
Mon, 18 Oct 1999 20:35:53 -0400
Wells Fargo administers the 401(k) for a previous employer, where I still
have an account.  Today I received a letter which reads in part:

"We have, from our initial introduction of Internet access to retirement
account information nearly two years ago, recognized the value of requiring
users to utilize browsers that support the strong, 128-bit encryption
available in the United States and Canada.  Following recent testing of an
upgrade to our Internet server, we discovered that the site had been put
into general use allowing access with standard 40-bit encryption.  We fixed
the problem as soon as it was discovered, and now, access is again only
available using 128-bit encryption.  ...  We have carefully checked our
Internet server and computer files and determined that at no time was the
site accessed without proper authorization while we were using the standard
encryption program.  ... We have adjusted our server monitoring to test for
lower encryption on an hourly basis to ensure the server is maintained at
the highest encryption level for your protection."

I found this to be both reassuring (that they admitted the error) and
frightening (that they state so confidently that the site was never
accessed improperly, which seems a trifle strong assertion).  I was also
pleased to see that they're now testing for recurrences of this
configuration error on a regular basis.

The letter then goes on to explain that there's no indication to IE users
to indicate whether they're using 40-bit or 128-bit encryption, but
Netscape 4.0 & later users can click on an icon to see the type of crypto.

While there's no explanation of how this configuration error occurred, it
shows the risk of systems that *appear* secure (i.e., using 128 bit
encryption), when they're really not (i.e., using 40 bit encryption).  Even
a reasonable effort to look at the output of the system would appear
encrypted in either case; it's only if someone took a closer look at the
traffic that the discrepancy would occur.  Compounding this is the fact
that it's not obvious (or even available) to users whether they're using a
strong or weak system, and an error will go undetected a long time.

Moral of the story: if it's easy to misconfigure a system so it's insecure,
that's exactly what will happen.

--Jeremy Epstein


New Australian RISKS Archive

Ochran Industries <n2585464@sparrow.qut.edu.au>
Mon, 18 Oct 1999 20:08:27 +1000 (EST)
There is now an Australian mirror of risks at

http://mirror.aarnet.edu.au/risks/

This is a html page of the ftp files, and contains all risks issues up
to risks-20.61 (02-Oct-1999).

westyX     -    n2585464@sparrow.qut.edu.au


Call for papers, Malicious Information Technology

"Jeffrey M. Voas" <jmvoas@rstcorp.com>
Fri, 22 Oct 1999 15:51:57 -0400
Co-Authored:

Software Assessment: Reliability, Safety, and Testability (Wiley, 1995)
http://www.rstcorp.com/books/sa

Software Fault Injection: Inoculating Programs Against Errors
(Wiley, 1998)  http://www.rstcorp.com/books/sfi

Videos:

Developing Software for Safety Critical Systems
(IEEE, 1998) http://www.rstcorp.com/videos/safety_critical.html

Software Testing: Building Infrastructure, Due Dilligence, and OO
Software
(IEEE, 1999) http://www.rstcorp.com/videos/software_testing.html

IEEE Software
Call for Articles & Reviewers
Malicious Information Technology: The Software vs. The People
Publication: Sept./Oct. 2000

Software was intended to improve the quality of human life by doing
tasks more quickly, reliably, and efficiently. But today, a "software
vs. people" showdown appears eminent.  Software is increasingly
becoming a threat to people, organizations, and nations.  For example,
the spread of the Melissa virus illustrates the ease with which
systems can be penetrated and the ubiquity of the consequences; the
Melissa virus caused many companies to shut down their EMail systems
for days or even weeks.  The origin of these threats stems from a
variety of problems.  One problem is negligent development practices
that lead to defective software.  Security vulnerabilities that occur
as a result of negligent development practices (e.g., commercial Web
browsers allowing unauthorized individuals to access confidential
data) are likely to be discovered by rogue individuals with malicious
intentions.  Other security vulnerabilities are deliberately
programmed into software (e.g., logic bombs, Trojan Horses, and Easter
eggs).  Regardless of the reason why information systems are
vulnerable, the end result can be disastrous and widespread.

Because of the increased danger that malicious software now poses, we
seek original articles on the following specific issues:

  + Intrusion detection
  + Information survivability
  + Federal critical infrastructure protection plans
  + Federal laws prohibiting encryption exports vs. US corporations
  + State-of-the-practice in security testing
  + The Internet's "hacker underground"
  + Corporate information insurance
  + Penalties for those convicted of creating viruses
  + Case studies in information security and survivability

Submissions due: 1 April 2000

Guest Editors:

Nancy Mead              Jeffrey Voas
Carnie Mellon University        Reliable Software Technologies
nrm@sei.cmu.edu             jmvoas@rstcorp.com

Authors: Submit one electronic copy in RTF interchange or MS-Word
format and one PostScript or PDF version to the magazine assistant at
software@computer.org.  Articles must not exceed 5,400 words including
tables and figures, which count for 200 words each.  For detailed
author guidelines, see www.computer.org/software/edguide.htm.
Reviewers: Please e-mail your contact information and areas of
interest to a guest editor.

Jeffrey M. Voas, Co-Founder, Reliable Software Technologies, Suite 400,
21351 Ridgetop Circle, Dulles, VA  20166 USA, jmvoas@rstcorp.com,
Phone: 703.404.9293, Fax: 703.404.9295

Please report problems with the web pages to the maintainer

x
Top