Subject: RISKS DIGEST 16.84

Subject: RISKS DIGEST 16.84
REPLY-TO: [email protected]

RISKS-LIST: RISKS-FORUM Digest Fri 24 February 1995 Volume 16 : Issue 84

FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks)
ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

***** See last item for further information, disclaimers, etc. *****

Contents:
Old manuals, new features = security holes (Christopher Klaus)
Software Firm is Victim of Virus (Timothy Hunt)
National Cryptography Policy: Call for Input and Public Meeting (Herb Lin)
CapAccess compromised (Mich Kabay)
Major file corruptions (Charles M. Preston)
Compact fluorescent lights (Edward S Suffern)
EU office distributes Galicia virus (Klaus Brunnstein)
Call for Papers, Risks in End-User Computing, HICSS '86 (Ray Panko)
Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc.

----------------------------------------------------------------------

Date: Wed, 22 Feb 1995 17:03:38 +1494730 (PST)
From: Christopher Klaus <[email protected]>
Subject: Old manuals, new features = security holes

Many vendors' man pages, books, and magazine articles dealing with setting
up an anonymous FTP server recommend something that is a possible security
vulnerability. The security flaw is a result of old manual pages and new
features being added to ftpd. They recommend the following:

~ftp)
Make the home directory owned by ``ftp'' and unwritable
by anyone.

A new feature added to many ftpd servers is "SITE CHMOD" -- which allows you
to change the permissions on a directory. If the main directory is owned by
ftp, then an anonymous ftp user can SITE CHMOD the main directory from
unwriteable to writeable. Once this has happened, they can add certian
files to the main directory that would allow them shell access to the ftp
account, thus to further compromise the system.

Many sites keep their incoming directory un-readable so that the
administrator has a chance to verify files before allowing others to grab
them. An intruder could undo all these permissions and even trojan existing
ftp files.

To fix these problems, make sure the home directory is owned by root and
that all files and directories are not owned by ftp. Unless you want
anonymous ftp to be able to modify what is on your ftp server.

For other security concerns, I have written a Anonymous Security FTP FAQ
(Frequently Asked Questions) that is available by sending mail to
[email protected] with "send Index" in the subject or body of the message.

Internet Security Systems, Inc. Computer Security Consulting
2000 Miller Court West, Norcross, GA 30071

------------------------------

Date: Thu, 23 Feb 95 09:41:20 +0000
From: "Timothy Hunt [Assistant Unix Systems Manager]" <[email protected]>
Subject: Software Firm is Victim of Virus

[seen in The Guardian, 23rd February 1995, p9]

More than 200 software developers may have had their computers infected by a
virus after Microsoft, the world's leading software developer, gave them
infected disks at a seminar in London. Microsoft said yesterday the company
that copied the disks for it had also been responsible for carrying out
virus checks, and had been sacked because it had ``cut corners.'' A
spokeswoman said a developer spotted the virus after the seminar. ``We
immediately telephoned all the developers who attended and warned them,''
she said. Microsoft had also written to them all and apologised. It is
believed only a few disks contained the virus.

Timothy J. Hunt, The Institute of Cancer Research, Royal Marsden NHS Trust,
Downs Road, Sutton, Surrey, England SM2 5PT +44 (0)181 642 6011 x3312

------------------------------

Date: Thu, 23 Feb 95 13:16:00 EST
From: "CRYPTO" <[email protected]>
Subject: National Cryptography Policy: Call for Input and Public Meeting

[This is a follow-up from Herb Lin on his message in RISKS-16.63. PGN]

National Policy and Cryptography:
A Call for Input and Public Meeting

Over the past few years, few topics have provoked as much debate
as the appropriate role of government as it relates to cryptography.
What is clear is that cryptography is critical to a wide range of
important civilian and military applications involving sensitive or
classified information that must be protected from unauthorized
disclosure and/or alteration. National cryptography policy --
however it is construed -- has important implications for future U.S.
economic competitiveness, national security, law enforcement
interests, and the protection of the rights of individual U.S. citizens.
In an attempt to clarify some of the issues involved, the U.S.
Congress asked the National Research Council to undertake a
comprehensive study on cryptographic technologies and national
cryptography policy. This study began in late 1994.

The study seeks broad input from stakeholders affected by national
cryptography policy. Thus, the study committee invites interested
parties to answer the following question:

How, if at all, will new telecommunications
technology, such as encryption, make it easier to
protect and/or compromise the interests of the
relevant constituencies? Some of the constituencies
might include individual citizens, organizations in
national security and law enforcement, high
technology businesses, business in general, and
non-profit and/or public service enterprises such as
health care and education.

Please use as the standard of comparison the ease
today of compromising or protecting these interests.
We are interested in scenarios involving both
individual users and large-scale impact. Please be
sure to tell us the interests you believe are at stake.
(If your input involves classified or sensitive
information, contact us to make appropriate
arrangements.)

All responses received by e-mail or U.S. mail prior to June 30,
1995 will be reviewed by the study committee. In addition, the
committee will sponsor a public session to receive oral input on
Friday, April 14, 1995, 8:30 AM to 12:30 PM, at the Lecture Room
of the National Academy of Sciences, 2101 Constitution Avenue
NW, Washington, DC 20418. (No public parking is available.) In
the interests of hearing the maximum number of people, speakers
will be limited to a statement of 6 minutes each. Anyone who
wishes to give oral testimony should submit their request
along with their response to the above question. (If you plan
only to attend, please inform us as well.) Ground rules for oral
presentation and/or a more detailed description of the study and its
charge is available upon request to [email protected].

This is your opportunity to make your voice heard on this important
subject. One way or another, cryptography policy does affect you.
This study is expected to help shape Congressional and
Administration views on national cryptography policy, and the
operative question to you is the following: Should this study take
your views into account? We hope you answer that question in the
affirmative.

Cryptography Project
Computer Science and Telecommunications Board
National Research Council
Mail Stop HA-560
2101 Constitution Avenue, NW
Washington, DC 20418
[email protected]

------------------------------

Date: 16 Feb 95 08:00:04 EST
From: "Mich Kabay [NCSA Sys_Op]" <[email protected]>
Subject: CapAccess compromised

The Washington Post news wire BYTES column for 95.02.13
(via CompuServe's Executive News Service) reports that the Washington, DC
Internet provider, CapAccess, has been compromised by criminal hackers.

The 12,000 users are at risk of impersonation because someone installed
"software that stole users' IDs and passwords."

The attack was apparently discovered only when CapAccess officials were
informed by anonymous e-mail apologizing for the trick.

M.E.Kabay,Ph.D., Director of Education, Natl Computer Security Assn
(Carlisle, PA); Mgmt Consultant, LGS Group Inc. (Montreal, QC)

------------------------------

Date: Thu, 23 Feb 1995 10:24:47 +0900
From: [email protected] (Charles M. Preston)
Subject: Major file corruptions

I would like to describe a strange case of file corruption on one of the
largest on-line service providers that cost me a day's work and a lot of
experimentation to chase down.

Several months ago I used a reliable program with error detection and
"auto downloaded" several megabytes of programs and text files.

Most of the files were compressed with PKZIP. After getting a
warning from PKUNZIP about a file being corrupt, I checked all the rest,
about 15, using PKUNZIP -t. All the files but one were corrupt.

I've downloaded many megabytes and thousands of dollars of files from the
service, without this problem. Thinking it was my ..serial port..hard drive
.download protocol..modem..virus.. or the particular directory (security
associated) that had a lot of corrupt files, I changed all the software
and hardware a piece at a time. Hours of downloads later, there was only
one constant, and it was the on-line service.

I determined it wasn't the files as stored on their hard drive, since I
could eventually get a good copy of most files. On the corrupt ones,
checksums matched over 2,3 or 4 copies downloaded with different computers
and error-detection schemes, including Ymodem, xmodem, and Kermit. This
service has a checksum command to match an already downloaded file and
prevent duplicate downloads, and it matched the files (corrupt) still there
with the files (corrupt) already on my hard drive.

I called support, and they admitted they were having a very odd problem with
one of their machines, probably the one with my corrupted files on it.

Two days later, no file corruption. Two weeks later, another batch of the same
type of corruption problem. None since then.

With some types of files this kind of corruption would not have been
obvious for what it was - the 32 bit PKZIP checksum saved the day, and
made it easier to determine the real culprit.

What type of problem, other than malicious programming, could cause these
symptoms?

Charles Preston Information Integrity [email protected]

Charles M. Preston Information Integrity [email protected]

------------------------------

Date: Thu, 23 Feb 95 17:27 EST
From: Edward S Suffern <[email protected]>
Subject: Compact fluorescent lights

For the last few months, I have experienced intermittent problems with the
infrared remote controls for my TV, VCR, and stereo. The symptoms were
difficulty activating the remote buttons, search operations continuing after
they should have stopped, and, very occasionally, spontaneous channel changes.
More recently, a friend's TV totally locked up as if one of the buttons was
stuck in the activated position.

New batteries had no effect. Disassembly of remotes found nothing. I even
disassembled the friend's TV found nothing until I noticed it would work fine
on the test bench but not in its normal installed location. This lead me to
correlate the problem with the recent installation of energy saving compact
fluorescent light bulbs. Further testing proved conclusively that all of my
infrared remote receivers were adversely affected by these lights.

The lights in question were manufactured by Lights of America (Models 2004 and
2030TP) but I expect other manufacturers may have the same problem. The bulbs
advertise a tri-phosphor that produces a soft white light quality. They also
have instant on, flicker free characteristics produced by a solid state
circuit that replaces the standard fluorescent ballast.

Based on my observations I can only conclude that the tri-phosphor bulbs emit
light in the infrared portion of the spectrum and that the electronics modulate
the light at frequencies used by infrared remote control devices.

The manufacturer does include disclaimers about the devices causing
"interference if placed within 10 feet of sensitive equipment. (T.V.s,
radios, etc.)." (I experienced IR interference problems at 15+ feet.) There
is also a statement about compliance with part 18 of the FCC Rules indicating
that the device may not cause harmful interference. I assumed these
references are directed at RF interference as that is what one normally
expects and there is no mention of infrared emissions.

The real risk deals with possible consequences of these lights causing
interference with existing and evolving applications of infrared technology
such as wireless digital communications, automotive collision avoidance
systems, etc.

Edward S. Suffern INFOSEC Consultant [email protected]

------------------------------

Date: Sat, 11 Feb 1995 13:19:59 +0100
From: Klaus Brunnstein <[email protected]>
Subject: EU office distributes Galicia virus

In December 1994, European Commission's office for "dissemination of
scientific and technical knowledge" distributed a diskette to more than
1,000 European information brokers, patent offices etc containing a CORDIS
News (in German) describing its RTD database etc. This diskette contained a
system (boot sector/MBR) infector which besides displaying a message (on
May 22nd, after noon: ";Galicia contra telefonica!") also overwrites
(unrecoverably) part of a diskette's boot library, and which attempts to
format a disk's cylinder. Though this formatting will likely abort, due to a
programming error, it is possible that formatting may succeed. Indeed, this
virus is malicious and not funny. (For details, see appended VTC Malware
Catalog entry).

It is even less funny that this EU office when informed about its malicious
gift to its customers found it very hard to locate the source of the
contamination; they even could not say whether it came from another EU
office or from one of their PCs. Only after some time, they claimed to have
found 2 potential leaks which their expert said they now have closed. This
implies that for some time, EU's information dissemination was a permanent
danger for its customers.

Even more ironically: this EU office belongs to EU's Directorate General (DG
XIII) "Telecommunications, Information Market and Exploitation of Research",
which (with its branch "B.6 Security of Telecommunications and Information
Systems") is responsible for EU's IT Security Criteria (ITSEC), which also
participates actual in joint US/EU attempts to develop "Common Criteria".
When being informed about the malicious distribution by its sister office,
the head of DG XIII's SOG-IS (Senior Officials Group - Information Security)
informed the author that they dont share responsibility for maintaining a
proper security as this is done by the European Commission's Office of
Security (a typical bureaucratic approach :-). Moreover, this very nice
expert claims that "I recognize that such incidents will happen from time to
time and that the responsibility ***falls equally on both sender and
receiver*** to ensure that the most 'hygienic' procedures are used to avoid
any unnecessary spread of 'infection'"(quoted from a reply of SOG-IS chair;
emphasis added by author). Finally, "controlling viruses is primarily a
procedural rather than technical problem".

Both an evidently failing AntiVirus policy (if existing) and such expert
opinion makes it rather likely that similar incidents will follow. If I were
a virus author (being a civil servant, I have NO CRIMINAL energy as I have NO
ENERGY at all :-), I would dream of such a large organisations (several 10,000
bureaucrats) with such "awareness". With their intellectual innocence, they'd
surely help to distribute my virii if I only succeeded to infect one PC!

Mildly shocked: Klaus Brunnstein (Feb.11,1995)

======= Computer Malware Catalog 2.0: Galicia Virus (10-Feb-95) ======
Entry...............: Galicia Virus
Alias(es)...........: (Telefonica.D Virus, see Particularities)
Caroname............: Galicia
Virtype.............: b
Virus Strain........: ---
Classification......: System virus: Boot/MBR infector, memory resident,
partly self-encrypted.
Length of Virus.....: 1 sector
Length of Virus(RAM): 2 kBytes
--------------------- Preconditions ----------------------------------
Operating System(s).: MS-DOS
Version/Release.....: All models
Computer model(s)...: PC's
--------------------- Attributes -------------------------------------
Easy Identification.: ID word: V1.
Self recognition in memory: 7C B8 (h) at [0:004C]
Self recognition on disk: 56 31 (h) at [01B3h]
Type of infection...: System: Upon booting from an infected diskette
or disk (MBR), virus makes itself memory
resident at top of memory/below 640 kBytes,
and it hooks Int 13h.
Disk: After booting from an infected diskette,
memory resident virus will infect MBR
upon trigger condition; original MBR
is saved.
Diskette: Once virus became memory resident, it
will infect any uninfected diskette in
drive A: and B: upon trigger condition;
original boot sector is saved.
Infection Trigger...: System/Memory: booting from infected disk/diskette
Disk/Diskette: any read (Int 13) access, when
drive is not actual drive.
Storage media affected: Diskette,Harddisk
Interrupts hooked...: Int 13h/02 (Read)
Damage..............: Transient: At trigger time, virus displays
message: "Galicia contra =>telefonica!".
This text string is encrypted in virus body.
Permanent/Disk: Upon trigger condition, virus
attempts to format 1st cylinder
(track 0/head 0/sector 6); due to a programming
error (un-initialised buffer address), this
attempt will very probably abort with an error.
Permanent/Diskette: Upon infecting a diskette,
virus overwrites track 0/head 1/ector which
contains part of root directory:
on 5,25" DD: last sector of root dir;
on 5,25" HD: 3rd sector of root dir;
on 3,5" DD: 3rd last sector of root dir;
on 3,5" HD: 2nd sector of root dir.
As virus does not store this sector elsewhere,
parts of root directory (e.g. entries 16-32
on 3.5" HD) are lost.
Damage Trigger......: Transient: IF (May 22) AND (time > 12:00) AND
(access to drive which is not to actual drive)
Permanent/Disk: IF (May 22) AND (time > 12:00) AND
(access to drive which is not to actual drive)
Permanent/Diskette: upon infection of boot sector
Particularities.....: Findviru calls the virus "Telefonica.d", probably
due to the displayed text, though the virus has
no relation to the Telefonica family.
Cryptomethods.......: Partly encrypted (XOR with FFFFH from offset
003Ch to 0159h).
Stealth.............: ---
Polymorphism........: ---
Tunneling...........: ---
--------------------- Agents -----------------------------------------
Countermeasures.....: Good AntiVirus products (detection/cleaning).
Countermeasures successful: Several actual AntiVirus products detect
Galicia, essentially under its name; at
publication time, only few AV products (e.g.,
Kaspersky's AVP) properly clean it from media.
Standard means......: Cleaning diskettes: format infected diskette
(MS-DOS >=5.0, DR DOS >=6.0) with /U.
Cleaning hard disk: Use DOS FDISK /MBR command
to overwrite the virus.
--------------------- Acknowledgement --------------------------------
Location............: 1) BSI/German Information Security Agency, Bonn
2) Virus Test Center, Univ Hamburg
Classification by...: 1) Hubert Schmitz (GISA V2)
2) Klaus Brunnstein, VTC
Documentation by....: 1) Hubert Schmitz (GISA V2)
2) Klaus Brunnstein, VTC
Date................: 10-February-1995
Information Source..: CaroBase entry (1) and additional analysis (2),
with information from Kaspersky, Skulason etc.
===================== End of Galicia Virus ============================

------------------------------

Date: Tue, 21 Feb 1995 08:35:41 -1000
From: "Ray Panko" <[email protected]>
Subject: Call for Papers, Minitrack on Risks in End-User Computing, HICSS '86

Twenty-Ninth Hawaii International Conference on System Sciences
January 3-6, 1996, Maui, Hawaii

Dr. Raymond R. Panko, minitrack coordinator
[email protected]

Papers are invited for the minitrack on RISKS IN END-USER COMPUTING as part
of the Information Systems track at the Hawaii International Conference on
System Science (HICSS).

Risks in End-User Computing

End users are ordinary computer users, such as managers and professionals,
rather than computer professionals. End users control a great deal of all
computing. There is growing evidence that this dominance of end-user
computing creates risks for organizations and perhaps even society.

We are soliciting research papers in such areas as 1) lab and field studies
on errors in spreadsheeting, query languages, and schema development in
databases, 2) privacy and security issues related to user access to
information, 3) and risks when end users use the Internet. This is not
meant to be an exhaustive list.

HICSS

HICSS is one of the oldest conferences in information systems and computer
science. The 1996 conference will be the 29th in an unbroken series. Each
year, the conference attracts about 500 computer research professionals.
The conference is conducted in cooperation with the IEEE Computer Society
and the ACM. The Proceedings are published by the IEEE Computer Society
Press.

Making HICSS unique is its organization around minitracks. In a minitrack,
the minitrack coordinator receives about fifteen to twenty papers and
selects six for presentation at the conference. Selection is based on
rigorous refereeing, ensuring high quality. All papers to be presented at
the conference are published in the Proceedings, which is available at the
start of the conference.

The minitrack focus of HICSS turns each minitrack into a mini-workshop. It
provides a critical mass of research papers in a target area, providing the
cross-fertilization of ideas. In addition, the conference activities are
consciously organized to maximize interactions among the participants. Of
course, minitrack participants also attend many other sessions in
information systems and computer science.

Please note that HICSS is a research conference. It is not a place for
publishing the types of articles that would appear in popular magazines.
HICSS papers should be potentially publishable in research journals.

Instructions for submitting papers:

1. Submit 6 (six) copies of the full paper, consisting of 20-25 pages
double-spaced including title page, abstract, references and diagrams
directly to the minitrack coordinator. Longer submissions will be rejected,
as will much shorter submissions.

2. Do not submit the paper to more than one minitrack. Paper should
contain original material and not be previously published or currently
submitted for consider elsewhere.

3. Each paper must have a title page which includes the title, full
name of all authors, and their complete address including affiliation(s),
telephone number(s), and e-mail address(es). For purposes of anonymous
refereeing, the author(s) name(s) should not appear in the rest of the
paper.

4. The first page of the paper should include the title and a 300-word
abstract.

DEADLINES:

MARCH 15, 1995: Abstracts MAY be submitted to minitrack coordinators (or
track coordinators) for guidance and indication of appropriate content.
Authors unfamiliar with HICSS or who with additional guidance are encouraged
to contact any coordinator to discuss potential papers. Abstracts are NOT
required but are strongly encouraged.

JUNE 1, 1995: Full papers due [...]
AUG. 31, 1995: Notification [...]
OCT. 1, 1995: Accepted manuscripts due camera-ready plus ONE registration.
NOV. 15, 1995: All other registrations [...]

The Risks in End-User Computing minitrack is part of the Information Systems
Track. There are two other major tracks in the conference: Software
Technology and Digital Documents. The Information Systems Track itself has
several minitracks that focus on a variety of research topics in
Collaboration Technology, Decision Support and Knowledge-Based Systems, and
Organizational Systems and Technology. For more information contact:

Jay F. Nunamaker, Jr.: E-Mail: [email protected]
(602) 621-4475
FAX: (602) 621-2433

Ralph H. Sprague, Jr.: E-Mail: [email protected]
(808) 956-7082
FAX: (808) 956-9889

For more information on other tracks, please contact:

Software Technology Track:
Hesham El-Rewini: E-Mail: [email protected]
Bruce D. Shriver: E-Mail: [email protected]

Digital Documents Track:
M. Stuart Lynn: E-Mail: [email protected]

For more information on the conference, please contact the
conference coordinator:

Pamela Harrington: E-Mail: [email protected]
(808) 956-7396
FAX: (808) 956-3766

Aloha, Ra3y (the 3 is silent)

Prof. Raymond R. Panko Internet: [email protected]
Decision Sciences Department Office: (808) 956-5049
College of Business Administration Fax: (808) 956-9889
University of Hawaii Secretary: (808) 956-7430
2404 Maile Way Home: (808) 261-2675
Honolulu, HI 96822 Time of Day: (808) 983-3211
USA Weather: (808) 833-2849

------------------------------

Date: 6 February 1995 (LAST-MODIFIED)
From: [email protected]
Subject: Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc.

The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks.
Undigestifiers are available throughout the Internet, but not from RISKS.

SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) on
your system, if possible and convenient for you. BITNET folks may use a
LISTSERV (e.g., LISTSERV@UGA): SUBSCRIBE RISKS or UNSUBSCRIBE RISKS. U.S.
users on .mil or .gov domains should contact <[email protected]>
(Dennis Rears <[email protected]>). UK subscribers please contact
<[email protected]>. Local redistribution services are
provided at many other sites as well. Check FIRST with your local system or
netnews wizards. If that does not work, THEN please send requests to
<[email protected]> (which is not yet automated). SUBJECT: SUBSCRIBE
or UNSUBSCRIBE; text line (UN)SUBscribe RISKS [address to which RISKS is sent]

CONTRIBUTIONS: to [email protected], with appropriate, substantive Subject:
line, otherwise they may be ignored. Must be relevant, sound, in good taste,
objective, cogent, coherent, concise, and nonrepetitious. Diversity is
welcome, but not personal attacks. PLEASE DO NOT INCLUDE ENTIRE PREVIOUS
MESSAGES in responses to them. Contributions will not be ACKed; the load is
too great. **PLEASE** include your name & legitimate Internet FROM: address,
especially from .UUCP and .BITNET folks. Anonymized mail is not accepted.
ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY.
Relevant contributions may appear in the RISKS section of regular issues
of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise.
All other reuses of RISKS material should respect stated copyright notices,
and should cite the sources explicitly; as a courtesy, publications using
RISKS material should obtain permission from the contributors.

RISKS can also be read on the web at URL http://catless.ncl.ac.uk/Risks
Individual issues can be accessed using a URL of the form
http://catless.ncl.ac.uk/Risks/VL.IS.html
(Please report any format errors to [email protected])

RISKS ARCHIVES: "ftp unix.sri.com<CR>login anonymous<CR>YourName<CR>
cd risks<CR> or cwd risks<CR>, depending on your particular FTP.
Issue J of volume 16 is in that directory: "get risks-16.J<CR>". For issues
of earlier volumes, "get I/risks-I.J<CR>" (where I=1 to 15, J always TWO
digits) for Vol I Issue j. Vol I summaries in J=00, in both main directory
and I subdirectory; "bye<CR>" I and J are dummy variables here. REMEMBER,
Unix is case sensitive; file names are lower-case only. <CR>=CarriageReturn;
UNIX.SRI.COM = [128.18.30.66]; FTPs may differ; Unix prompts for username and
password. Also ftp [email protected]. WAIS repository exists at
server.wais.com [192.216.46.98], with DB=RISK (E-mail [email protected] for info)
or visit the web wais URL http://www.wais.com/ .
Management Analytics Searcher Services (1st item) under http://all.net:8080/
also contains RISKS search services, courtesy of Fred Cohen. Use wisely.

------------------------------

End of RISKS-FORUM Digest 16.84
************************