Subject: RISKS DIGEST 16.84 REPLY-TO: risks@csl.sri.com 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 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 info@iss.net 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]" 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" 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 CRYPTO@NAS.EDU. 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 CRYPTO@NAS.EDU ------------------------------ Date: 16 Feb 95 08:00:04 EST From: "Mich Kabay [NCSA Sys_Op]" <75300.3232@compuserve.com> 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: cpreston@alaska.net (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 cpreston@alaska.net Charles M. Preston Information Integrity cpreston@alaska.net ------------------------------ Date: Thu, 23 Feb 95 17:27 EST From: Edward S Suffern 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 Suffern@Dockmaster.ncsc.mil ------------------------------ Date: Sat, 11 Feb 1995 13:19:59 +0100 From: Klaus Brunnstein 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" 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 Panko@dscience.cba.hawaii.edu 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: nunamaker@bpa.arizona.edu (602) 621-4475 FAX: (602) 621-2433 Ralph H. Sprague, Jr.: E-Mail: sprague@uhunix.uhcc.hawaii.edu (808) 956-7082 FAX: (808) 956-9889 For more information on other tracks, please contact: Software Technology Track: Hesham El-Rewini: E-Mail: rewini@unocss.unomaha.edu Bruce D. Shriver: E-Mail: b.shriver@genesis2.com Digital Documents Track: M. Stuart Lynn: E-Mail: msylnn@cpa.org For more information on the conference, please contact the conference coordinator: Pamela Harrington: E-Mail: hiccs@uhunix.uhcc.hawaii.edu (808) 956-7396 FAX: (808) 956-3766 Aloha, Ra3y (the 3 is silent) Prof. Raymond R. Panko Internet: Panko@dscience.cba.hawaii.edu 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: RISKS-request@csl.sri.com 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 (Dennis Rears ). UK subscribers please contact . 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 (which is not yet automated). SUBJECT: SUBSCRIBE or UNSUBSCRIBE; text line (UN)SUBscribe RISKS [address to which RISKS is sent] CONTRIBUTIONS: to risks@csl.sri.com, 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 Lindsay.Marshall@newcastle.ac.uk) RISKS ARCHIVES: "ftp unix.sri.comlogin anonymousYourName cd risks or cwd risks, depending on your particular FTP. Issue J of volume 16 is in that directory: "get risks-16.J". For issues of earlier volumes, "get I/risks-I.J" (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" I and J are dummy variables here. REMEMBER, Unix is case sensitive; file names are lower-case only. =CarriageReturn; UNIX.SRI.COM = [128.18.30.66]; FTPs may differ; Unix prompts for username and password. Also ftp bitftp@pucc.Princeton.EDU. WAIS repository exists at server.wais.com [192.216.46.98], with DB=RISK (E-mail info@wais.com 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 ************************