Subject: RISKS DIGEST 18.48 RISKS-LIST: Risks-Forum Digest Monday 23 September 1996 Volume 18 : Issue 48 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, caveats, etc. ***** Contents: An unlosable casino game (Kristiansen) When is -32768 != -32767-1 ? (Bear R Giles) RISKS of temporary change-of-addresses (Simson L. Garfinkel) AIDS list compromised (Winn Schwartau) "PRIVACY Forum Radio", Lexis-Nexis "P-TRAK" Interview/Update (Lauren Weinstein) Detailed Update Regarding Lexis-Nexis "P-TRAK" Database (Lauren Weinstein) Even more ATM Risks (James Robertson) SYN Floods, IP Spoofing, and what to do about it (Fred Cohen) More on portable electronics/airplanes (Peter Ladkin) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Sun, 22 Sep 1996 14:37:03 +0200 (MET DST) From: Kristiansen Subject: An unlosable casino game The Dutch radio station Radio 538 (http://www.radio538.nl [in Dutch] has set up a "Virtual Casino" on their web server, as a protest against legislation-in-the-making against Internet gambling. The "casino" consists of a virtual slot machine. Playing is free of charge, and you can win real prizes, presumably paid by the sponsors whose company logos appear prominently. So far so good. The amusing part is that the constructor of the Web site missed one little detail: If you lose in a turn of the game, you just click on "BACK" on your Web browser, and you undo your loss! Erling Kristiansen [The object is probably to let you win, gaining free publicity. It would be a risk if there is no limit on individual winnings. But this should certainly be a reminder to future webgame developers. PGN] ------------------------------ Date: Fri, 20 Sep 1996 15:07:31 -0600 (MDT) From: bear@indra.com (Bear R Giles) Subject: When is -32768 != -32767-1 ? We have recently started using the Borland 5.01 C/C++ compiler[*], and came across an interesting anomaly. The minimal "short" integer, as defined in the ANSI-standard file , is -32768. Curiously it is defined as "(-32767-1)". At first I attributed this format to symmetry; the maximum "short" small integer was defined as 32767. However I soon noticed "long constants" and "possible loss of precision" error messages with any code which initialized a "short" integer to -32768. If this were human generated code, these values could be easily changed to "SHRT_MIN", but this code was state tables output by Gnu Flex. Turning off these error messages is risky since a fair number of bugs (in my experience) are related to precisely this type of logic flaw, especially when the software needs to run on multiple platforms. On the other hand, leaving the error messages enabled prevented me from compiling this program, due to "excessive errors or warnings." Still, this situation is better than I would face when using a personal copy of Microsoft Visual C++ 1.5. It limits SHRT_MIN to -32767. [*] A bit of research shows that the problem goes back to a least Borland 4.0. Bear Giles bear@indra.com ------------------------------ Date: Fri, 20 Sep 1996 12:30:28 -0600 From: "Simson L. Garfinkel" Subject: RISKS of temporary change-of-addresses For the past year I've lived on Martha's Vineyard, but I spent the summer in Boston. Eager to have my mail forwarded the 80-mile jump, I filed a temporary change-of-address with the US Post Office. The forwarding order expired on September 4th. Now, it has been widely reported here and elsewhere that the US Post Office sells its national change of address register to the nation's top bulk-mailers so that they can automatically update their addresses. I've also documented how this information is used for target-marketing purposes, even though such uses are strictly forbidden by the Post Office. What I discovered this summer, though, was that either the Post Office or the users of the databank do not distinguish between temporary change of addresses and permanent change of addresses. During the summer, I had many magazines and financial statements delivered with the "corrected" address, which was a rented post office box in Boston. I had my insurance company call me up and ask me why I had moved without telling them. I had a lot of confusion. What makes the confusion all the worse is that my rented mail box was cancers a week after the mail forwarding order was canceled. All mail sent there will be returned-to-sender. And, no, the post office will not forward paper mail that is destined for a rented post office. Now I'm trying to find every company that I do business with that updated its copy of my address, and tell them that they shouldn't have updated the address, even though they thought they were doing the right think. All of this has been a huge waste of time --- not just mine, but the roughly three dozen companies that I've had to deal with. What is the most frustrating, though, is that I did everything exactly the way I was supposed to, and still I got screwed by the system. On the other hand, I don't see any way that I could have gotten my mail forwarded and not had to suffer with these problems. Simson Garfinkel PO Box 4188, Vineyard Haven, MA 02568. 508-696-7222 http://www.packet.com/garfinkel ------------------------------ Date: Fri, 20 Sep 1996 16:10:59 +0100 From: winn@Infowar.Com Subject: AIDS list compromised The names of over 4,000 AIDS patients were secreted out of a Pinellas County, Florida, computer and sent to the *St. Petersburg Times* on 18 Sep 1996. William B. Calvert III, 35, one of only three people allegedly with access to the computer containing the files has been placed on administrative leave (with pay!) while investigations continue. The computer disc was accompanied by an anonymous letter claiming that Calvert had been showing and bragging about the disc and its contents at a Treasure Island gay bar, Bedrox. The *St. Pete Times*a said they did not look at the names on the list. Preliminarily, the security controls over the list are said to have included: - A double-locked room - A computer (no type specified) with a lock (unspecific) - A single-attempt password system. (no specifics.) I have been talking to the local reporters to see if we can determine any additional details like: - Is there any other connectivity to the machine, despite the locked room? - Are there audit records? - What were the real security controls - Why there was no encryption - Why officials do not consider such data bases confidential. This story is making major headlines here in the St. Pete area where I live, especially since no one knows how many other disks have been circulated and where they might be sent, or worse posted. According to some reports, Calvert was a disgruntled employee, with a history of allegations. This one incident may be the largest single case of AIDS related disclosures ever. In 1993 a Miami data base of 6,000 HIV positive people was stolen, but investigators said the list was a corollary part of a hardware theft. The RISK we face, beyond the obvious leakage of the names and the possible disruptions of people's lives already disrupted by this terrible disease, is that others may not come forward for testing and treatment for fear that their names, too, will be publicized. Winn Schwartau - Interpact, Inc. Information Warfare and InfoSec V: 813.393.6600 / F: 813.393.6361 Http://www.infowar.com Winn@infowar.com ------------------------------ Date: Sun, 22 Sep 96 23:22:10 PDT From: Lauren Weinstein Subject: "PRIVACY Forum Radio", Lexis-Nexis "P-TRAK" Interview/Update In the message following this one, I've provided a detailed update on the current Lexis-Nexis "P-TRAK" personal information database furor, based on my own research. Since the situation has been changing very rapidly, this represents the most up-to-date information I'm aware of regarding both the service and your options for dealing with it if you so choose. With concerns over databases and personal information running at such a high level, this seems like the appropriate time to announce the first program from the PRIVACY Forum's new effort: "PRIVACY Forum Radio". As longtime readers of the forum know, one of my major concerns is getting the word out to people that privacy really matters, and that there are actions they can take to help protect themselves, *before* troubles arise. Whether related to computer, telecommunications, or database privacy issues, or the less esoteric aspects of privacy in our personal lives, to be forewarned is critical. PRIVACY Forum Radio will be an ongoing production of the PRIVACY Forum. It initially will include audio interviews, discussions, and other programs conducted with all manner of persons involved in the privacy, security, and related areas. Participants will include persons from business, industry, government, concerned organizations, and other individuals. Both the well-known "movers and shakers" and the unknown folks affected by privacy problems will be featured. All aspects of privacy in our personal, commercial, and public lives will be topics for various guests. Initial programs will be prerecorded, but shortly we'll begin live broadcasts offering listeners the ability to call in by phone, or send in e-mail queries, to directly participate in the discussions. The primary distribution medium for these PRIVACY Forum Radio materials is the Internet, via the Xing "Streamworks" system. Versions of the shows, including live programs, will be available for access by listeners at network connection rates as low as 14.4 Kbps per second. Some materials will also be made available at higher rates for those with the appropriate capabilities. In the very near future, we also plan to make some items available with accompanying video ("PRIVACY Forum TV"), using the same system. These shows are also available, by arrangement, for conventional radio syndication. Since my primary goal is to try get the word out about these issues as widely as possible, PRIVACY Forum Radio is also making available a short (e.g. 60-second) "Privacy Bites", suitable for use by regular broadcast radio stations who want to help their listeners not only become aware of privacy risks, but to learn what they can do about them. Inquiries regarding any of these materials should be directed by e-mail to privacy-radio@vortex.com, or by voice to (818) 225-2800. The first special program from PRIVACY Forum Radio is an interview I conducted a few days ago with Lexis-Nexis Corporate Counsel Steven Emmert, on the subject of concerns over the "P-TRAK" database, and on the topics of personal information and databases in general. It provides fascinating insight into views of privacy from the "database industry" side of the fence. To hear this program, follow the PRIVACY Forum (and PRIVACY Forum Radio) links from http://www.vortex.com Links are present within the PRIVACY Forum Radio area explaining the technical details of hearing the interview and other materials, and for downloading the (free) Streamworks software for your system that you'll need if you don't have it already. This is an exciting step in the evolution of the PRIVACY Forum, one that I'm hoping will be a major stride towards helping people worldwide deal with the ever-encroaching loss of privacy that has become part and parcel of our modern societies. Please direct any questions about accessing or obtaining PRIVACY Forum Radio materials to the e-mail address or phone number mentioned above. Thanks much! --Lauren-- ------------------------------ Date: Sun, 22 Sep 96 23:22:58 PDT From: Lauren Weinstein Subject: Detailed Update Regarding Lexis-Nexis "P-TRAK" Database This is going to be a longish message, but I urge you to read it in its entirely. As many of you are no doubt aware, considerable controversy has been raging around the Internet, and now in the mainstream press, concerning the Lexis-Nexis "P-TRAK" personal information database. Since the transmission of P-TRAK related messages here in the PRIVACY Forum early this month, various information, some accurate, some inaccurate, has been widely disseminated. In some cases, I've seen versions of the original PRIVACY Forum items in excerpted and usually unattributed form, sometimes having been modified or addended in manners that significantly alter the original content. Concern over P-TRAK has mushroomed around the country, perhaps especially due to Lexis-Nexis' high visibility. Many people are concerned about their personal information, however innocuous some might consider it to be, residing in publicly accessible databases. They want some measure of control over their personal data. It is this concern that has brought this story to national prominence. Lexis-Nexis has put forth an official statement concerning P-TRAK (accessible via http://www.lexis-nexis.com) which is accurate as far as it goes--but in my opinion leaves out some *very* important points which people should be aware of and that I'll describe in detail below. Adding to the confusion is the fact that over the last couple of weeks the mechanisms available for people to request removal from the P-TRAK database have been changing, largely due to the high volume of requests that Lexis-Nexis has been receiving. Callers to various Lexis-Nexis numbers were at times told conflicting or apparently inaccurate information, and the exact mechanisms for requesting removal, and what such a request really meant in practice, has been in a state of flux. Early deletion requests were taken by operators, then by voicemail systems, and then later callers were told all requests had to be by mail or fax. Most callers were asked for their Social Security numbers. Some were told that it was essentially useless to request removal, since they could easily pop right back on the database again later. Questions about how to verify removal persisted. Given all this, I decided to take it upon myself to go directly to the source, and had a number of detailed conversations with the Lexis-Nexis Corporate Counsel, Steven Emmert. Since Lexis-Nexis was in the process of making decisions on some of these issues, I held off this update until now to give Mr. Emmert time to get me the latest information, which he has done. As described in the previous message, I'm also pleased to announce that PRIVACY Forum Radio is presenting a detailed audio interview with Mr. Emmert, via the PRIVACY Forum web page (access via http://www.vortex.com). Mr. Emmert and yours truly discuss both the details of the P-TRAK controversy and some of the more philosophical aspects of personal information databases. If you're at all concerned about these topics, you will probably find the interview quite interesting. Where do the P-TRAK issues stand right now? First off, it should be noted that Lexis-Nexis is a reseller of the data in P-TRAK, not the collector. They don't verify or otherwise amend the original information. The information itself is the so-called "credit header" data which FTC and other decisions ruled were not covered under the FCRA (Fair Credit Reporting Act) and could be openly disseminated. This includes name, address, phone number, Social Security number, and other related data. Lexis-Nexis obtains this info from one of the big credit data agencies (published reports have suggested that this is Transunion). Lexis-Nexis receives this data, which includes more than 300 million records, on a monthly basis. While Lexis-Nexis notes that their marketing focus is to government, law enforcement, and the legal profession, it's important to realize that the P-TRAK database is not *restricted* in any way to ensure that only persons in those categories are using the data. Anyone who wants to the pay the appropriate fee can obtain search data. This is a crucial problem in the database industry--the almost total lack of even rudimentary "need to know" requirements before gaining access to information that many persons consider (obviously erroneously in many cases!) to be private. Lexis-Nexis points out that you cannot view Social Security numbers through P-TRAK. This is true. When the database was originally established in June of this year, SS#'s were available for viewing, but in short order concerns led to their display being terminated. So, you can't derive a SS# from someone's name via P-TRAK. HOWEVER--this does not mean that SS#'s are not in the P-TRAK database. In fact, they are there, and if you already have an SS# you can use it to search in P-TRAK for all of the other data associated with that number (e.g., name, address, phone number, and so forth). Lexis-Nexis considers the SS# to be the only reliable personal identifier, and in fact has told me that when a person requests removal from the P-TRAK database (more on this below) the best chance of actually getting removed exists when that person provides their SS#. Name and address are considered less desirable for this purpose, due to name duplications, name or address changes, etc. This is the reason that callers asking to be removed have typically been asked for their SS#'s. To Lexis-Nexis' credit, it should be noted that they have competitors (some on the Internet) who don't restrict SS# information at all, and don't offer any opportunity to be removed from their databases either. Still, it's important to understand that SS#s *are* in the P-TRAK database, and that you still can search *by* SS# in that database. Information available for direct view in P-TRAK includes name, maiden name (if any), current address, up to two previous addresses, phone number, and year/month of birth. Mother's maiden name is not included. The source of phone numbers is of particular interest. Lexis-Nexis in their statements has likened all this data to the telephone company "white pages", pointing out that it is all based on publicly available information. But the definition of "publicly available" is very broad--much broader than most people realize. Phone numbers in P-TRAK are *not* derived from telephone company (e.g., white pages) information. They are obtained from a variety of other sources, notably data provided by businesses that have conducted transactions or other business with a person, to whom that person may have provided their phone number. As such, unlisted (non-published) phone numbers *can* appear in P-TRAK, since an unlisted designation only affects phone company records, not all the other places where you have provided a number, probably with the expectation that the number would not be provided to commercial databases! There are no legal restrictions on the dissemination of such phone numbers, even though many persons keep their phone numbers unlisted for quite valid and serious reasons. OK, let's say you've decided that you consider the information in P-TRAK to be significant to you, and you want your record deleted. First off, be aware that it could take up to 60 days for a deletion to occur. This is due to the 30 day cycle on the database source; the deletion request needs to be present long enough for a complete cycle to process. Can you verify (for free) that a deletion has taken place? No, not easily; you need to pay for a regular P-TRAK search. Previously there was a contact person for verification of deletions, but due to the high volume of requests that option is apparently no longer being offered. Will you stay off the list once a deletion request has been processed? Maybe. It would seem to depend strongly on how much information you provided with your original request. If you provided a SS#, you probably have a better chance of not finding yourself with a new record in a future cycle due to non-identical name or address information appearing for you in a future load of incoming data. Do you want to provide your SS# with your request for deletion? That's a personal decision of course. What if perchance you don't currently have a record in P-TRAK? Will your deletion request be held until a record does come in? No, it will not. If you don't have a matching record at the time your deletion request is processed, that request will be flushed, and if a record for you appears in future data that record will enter the P-TRAK database. There is no mechanism present for a "permanent" deletion request that would deal with such situations. As noted above, the methods for requesting deletion have changed over the last two weeks. In fact, they've even changed in the few days since the recording of the interview with Steven Emmert (a different fax number and the re-establishment of voice requests on a new number). So be sure to use the information specified below, not the number that Mr. Emmert provided during the interview. The following is the most up-to-date information as of this writing, and comes directly from my communications with Lexis-Nexis. Here are your options: Telephone (toll free): 1-888-965-3947 Please note that this is a new number at Lexis-Nexis and is not scheduled to be working until this Monday morning (9/23) Eastern Time. It is currently scheduled to go to live operators, but if volume is very high it might be switched to voicemail. FAX (toll free): 1-800-470-4365 Again, this number is scheduled to become functional on the morning of 9/23, Eastern Time. Mail: P-TRAK, P.O. Box 933, Dayton, OH 45401 E-mail: p-trak@prod.lexis-nexis.com A web form for removal requests is also available at Lexis-Nexis via http://www.lexis-nexis.com. The minimum information required to request removal is full name and mailing address. As noted above, Lexis-Nexis feels that the strongest likelihood of a successful removal will occur when Social Security number is also provided. The web form (as of this writing) doesn't request SS#, and you of course should use your judgment about choosing to send your SS# in e-mail. My own recommendation would be to use the telephone or fax options. By no means is P-TRAK the most onerous database of personal information now available. But I believe the furor that has erupted demonstrates the deep-seated concerns that many people have with details of their personal lives being collected and sold merely as "information commodities", with the subject of that data having virtually no input on how it will be used, or abused. It's time for a detailed examination of what information should and should not be considered to be "public", who should have access to that data, and under what circumstances. Some database companies themselves admit that this is not an area that they can unilaterally address in any general way--they have competitive concerns. Only through serious legislative efforts can we really begin working toward reasonable changes in the commercial database field. And we'd better get started now, unless we want the 21st century to be a time when the word "privacy" becomes nothing more than an amusing anachronism in the history books. --Lauren-- P.S. Be sure to check out my audio interview with Steven Emmert of Lexis-Nexis on PRIVACY Forum Radio if you can. Just follow the PRIVACY Forum links from http://www.vortex.com to PRIVACY Forum Radio. ["Michael J. Chinni" noted a change in the web address reported by Pease in RISKS-18.47. He suggests searching down from main address, noted above. PGN] ------------------------------ Date: Mon, 23 Sep 1996 22:15:24 +1000 From: James Robertson Subject: Even more ATM Risks (Chisholm, RISKS-18.47) Rory's description of his close encounter with a dodgy ATM machine reminded me of a more than annoying incident I suffered recently. Needing to withdraw a large amount of cash in a hurry, I went to my local ATM machine, and requested $700.00 in cash. The machine normally gives out $20.00 or $50.00 notes, and obviously I was expecting the latter. Unfortunately, it gave me the former. Of course, this consists of 35 bills. It spent some time shuffling bills behind the scenes (which was where I started to get the idea that something was not well). Some clunking noises later, and it gave me some bills. Eleven of them to be exact. It then gave me a receipt. Needless to say, it deducted the full $700.00, even as I could hear it withdrawing the bills back into the bowels of the machine. The cause: it simply couldn't fit that many bills through the slot. So it sent through what it could, and took back the rest. The RISK: Somewhere in the bank there are teams of programmers, writing and maintaining the software for the ATMs. They handle many types of exceptions, and error conditions. Elsewhere, there are many engineers, carefully poring over the design of the ATM, its cash dispenser, checking that there are no foulups, or possible causes of mechanical failure. Then there is the person who takes the hardware, loads the software, and sends the ATM out. The programmers never see an ATM (except when they are withdrawing their money), and are likely never told its physical characteristics. Similarly, the engineer is simply told that some software is loaded on the computer that he (or she) has bolted into the case. I'm sure it has just not occurred to the managers that mere physical constraints can affect the operation of ATM software ... The even greater RISK? How do I get a message to the programmers responsible for the problem? There is no mechanism in the bank for you to write a complaint to the support staff. And what do you think are the chances of them having the time to think about the problem and discover the cause for themselves? James PS. It took over a week for them to finally get my money back into the account. Several checks almost bounced as a result. James Robertson * jamesr@desklaw.com.au Coding * Design * Layout * Newton * Windows "Beyond the idea" ------------------------------ Date: Fri, 20 Sep 1996 09:14:27 -0700 (PDT) From: "Fred Cohen" Subject: SYN Floods, IP Spoofing, and what to do about it Several years ago, several authors published details of a flaw in the design of TCP allowing denial of services via sending a SYN packet and not following up. In the last week or so, several magazines have published code for a SYN flood attack, and now many ISPs are going down because of their lack of defense and inability to trace the attacks to the sources. I thought I would note that the CERT has now decided to advise all on the Internet to use the techniques against IP spoofing published some months ago in Network Security Magazine (Elsevier) in an article on IP spoofing (part of the "Internet Holes" series. This article was also published in the BoS mailing list (although they should not have done so because of copyright violation). The basic defense is for the Internet community as a whole to refuse to route packets from known forged addresses. For example, we shouldn't be routing packets from 0.0.0.0 and 255.255.255.255 or the IP addresses associated with internal-use-only IP ranges or - most importantly - packets from IP addresses not in the range appropriate to an incoming link. (If you service IP range 204.7.229.*, don't let inbound packets from that port with from IP addresses not in that range). FC ------------------------------ Date: Fri, 20 Sep 1996 08:49:52 +0200 From: Peter Ladkin Subject: More on portable electronics/airplanes (RISKS-18.47) Also see AWST Sep 9, p82. The RTCA is a non-profit organisation that evolves avionics and other electrical standards for aviation. It reports on RTCA Special Committee 177, formed in 1992 to consider just this potential problem. ------------------------------ Date: 15 Aug 1996 (LAST-MODIFIED) From: RISKS-request@csl.sri.com Subject: Abridged info on RISKS (comp.risks) The RISKS Forum is a MODERATED digest. Its Usenet equivalent is comp.risks. => SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) if possible and convenient for you. Or use Bitnet LISTSERV. Alternatively, (via majordomo) DIRECT REQUESTS to with one-line, SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:] or INFO [for unabridged version of RISKS information] => The INFO file (submissions, default disclaimers, archive sites, .mil/.uk subscribers, copyright policy, PRIVACY digests, etc.) is also obtainable from http://www.CSL.sri.com/risksinfo.html ftp://www.CSL.sri.com/pub/risks.info The full info file will appear now and then in future issues. *** All contributors are assumed to have read the full info file for guidelines. *** => SUBMISSIONS: to risks@CSL.sri.com with meaningful SUBJECT: line. => ARCHIVES are available: ftp://ftp.sri.com/risks or ftp ftp.sri.comlogin anonymous[YourNetAddress]cd risks or http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue]. The ftp.sri.com site risks directory also contains the most recent PostScript copy of PGN's comprehensive historical summary of one liners: get illustrative.PS ------------------------------ End of RISKS-FORUM Digest 18.48 ************************