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…
Our CSL majordomo server was apparently blown away by the installation of a new version of sendmail. If you received a bounce on a subscription change request on the Ides of March (Monday 15 Mar), or if you requested a change but this issue is still using your old address, please try again. TNX. PGN Beginning last Friday, an enormous number of pieces of mail on a private distribution to me at sri.com rather than the customary CSL found their way into a black hole as the result of a seemingly harmless DNS upgrade made by the sys admins at sri.com. Fortunately, someone deduced that I was not responding, which triggered the discovery and temporary fixing of the otherwise undetectable problem (there were no bounces, just bit-buckets). I am told that the fix will go away on the next upgrade, so please use only my CSL address. Once again we are reminded of the incredible variety of risks of e-mail.
North American operations of the Associated Press (among others) were affected on 12 Mar 1999 by the failure of a GE-3 satellite, which is spinning out of control. [Source: *USA Today*, 12 Mar 1999] [A Reuters item in *The Washington Post*, 15 Mar 1999, reported that service was out for almost 6 hours, and is now back to normal. The cause was not given. Reported to RISKS by Paul Walczak. PGN]
http://www.usnews.com/usnews/issue/990322/22hist.htm (Cover story 22 Mar 1999 on a partial history of e-mail) OCTOBER 1969: Leonard Kleinrock, a UCLA computer science professor, sends the first e-mail message to a colleague at Stanford. The computer promptly crashes. — and nothing much has changed since. amusing list, btw. worth a look. [Well, it was certainly not the FIRST e-mail message, but it might well have been the first ARPAnet e-mail message. USNews should add earlier items, such as the CTSS e-mail system written by Tom Van Vleck and Noel Morris, which I used during the early Multics days in 1965, and it apparently did *not* cause any crashes. An paper reference is found in CTSS Programming Staff Note 39 by Glenda Schroeder, Louis Pouzin, and Pat Crisman, undated, but it was prior to PSN 40, which was dated 8 Jan 1965. RISKS will be happy to set the record straight on any earlier e-mail systems, in the RISKS-of-historical-inaccuracies department. PGN]
On Wednesday, March 10, 1999, two of the three hospitals that make up Long Island Jewish Medical Center in Long Island, NY were without power for a period of 47 minutes, starting at 5:58pm. Patient care was apparently not impacted, although 2 operations were completed by battery operated lights and bags of ice were hauled from the cafeteria to the blood bank to keep things cold. Life support equipment has an internal battery backup and kept functioning during the outage. Investigations are underway to determine none of the four backup generators worked. Kids, let this be a lesson. It's not enough to have a backup system in place...you need to make sure it will work when needed. Dave Weingart, Randstad North America email@example.com 1-516-682-1470
Three patients on intensive-care life support died on 11 Mar 1999 in a Siberian hospital in Prokopiyevsk (Kuzbass) because the local electricity company cut the power after warnings over unpaid bills. [Source: Agence France-Press, 11 Mar 1999; PGN-ed] [Just a note to show, again, that Y2K is not the only issue in Russia. KAR]
Wired News (http://www.wired.com/news/news/technology/story/18401.html) reports that Berlin subways will be using Motorola's Venus SmartCards as tickets for travel. The smartcards have up to 32kbytes of EEPROM (electrically erasable read-only memory). Would it be a risk for static discharge to wipe the EEPROM, thus losing all your "cash"? Any cases of this sort reported? Alpha Lau, Ericsson Australia, Network Systems GPO Box 256C Melbourne VIC 3001 firstname.lastname@example.org MC34.22 ph: +61 3 9301 6197 [That would be a case of U-Bahn-ic plague! PGN]
An item in The Register <http://www.theregister.co.uk/990319-000002.html> notes that the personal data sent to Microsoft by the Windows 98 registration wizard may be in breach of European privacy legislations. The Swedish Computer Inspectorate is reportedly considering an investigation. [So, we can wait for the Expectorate? PGN] In a related matter, Jason Catlett of the Junkbusters privacy lobby has filed a formal complaint about Microsoft with TrustE, the voluntary American computer privacy auditing organization. The Register notes: "But TrustE is a Microsoft corporate partner, and gets $100,000 a year from Redmond. Tricky - the company intends to say what it's going to do about this particular hot potato today [March 19, 1999]". Transcribed and summarized by Martin Minow, email@example.com
A reporter's summary of MS-Word98 and MS-office98 in general can be found at http://www.macintouch.com/o98securitysamp.html In the same page, there are comments from the readers. Some mention that they can find information such as credit card #, directory names where important files are kept, etc. that they think should not be in the files. I think some of these observations are due to the re-use of old file blocks without clearing the file blocks first. In any case, it is a little disturbing to think that `1984' has arrived without much fanfare. [Surprised? RISKS began in 1985, and we observed early-on that it was already here. PGN] Chiaki.Ishikawa@personal-media.co.jp.NoSpam Personal Media Corp., Shinagawa, Tokyo, Japan 142-0051
I just got off the phone with support line of the remaining Boston Bank (no need to name it except for those who don't know about Fleet taking over BankBoston). Their home banking does not work with Internet Explorer 5. This would be understandable if they had tested and discovered a new problem with the retail release or if Microsoft hadn't mentioned that a new release was coming out. But, in December, I had a long e-mail exchange when IE5 suddenly stopped working with their service and the response was that they didn't support unreleased browsers and weren't even curious about why it might have stopped working. Today I had two conversations with their support staff. During the first one they basically said it was Microsoft's fault because they released a new browser. I presume they'll blame the Pope for surprising them with the year 2000. They also made up excuses such as IE5 not having 128 bit security, which was totally bogus. Even if any of this were true, it is still the bank's fault since if were is an IE5 problem, they should simply produce a message saying the browser is not supported instead of simply going mute. I then looked at the code. If I read it correctly, the progress messages are completely bogus and are generated by a local timing loop purely to pacifier the user. More striking was that the body of the message looked like the boiler plate for the web page. It seems as if the server explicitly checks for the browser version and produces browser-specific HTML. For IE5, it seems to fall through to the template code but there is no error checking. I called back and spoke to a supervisor who accepted my analysis, but there wasn't much he could do about it. At least, it reduced my hostility. This is very disturbing since it is so trivial and obvious and, even more so, something I had reported in December. Unlike the subtle bugs often reported here, this is simply stupid and inexcusable. There doesn't seem to be much connection between the support staff and the backroom. It is very embarrassing since it is so visible and unnecessary. Even more so since the IE4 support simply worked in IE5 and someone had to explicitly break the support on (or about) December 28, 1998. Sadly, this will soon be the last of the larger banks in Boston ... IE5 does work with BankBoston. Bob Frankston http://www.Frankston.com
Central Bank has decided to close all banks to the public December 31 this year to do the final assessment on all computer systems compliance to the Year 2000 (Y2K) problem. [Beginning of an item in *The Island*, 12 Mar 1999, noting that employees will be at work. PGN-ed] Risks: 1. December 31 appears to be a little late for final testing of Y2K readiness. What if something isn't ready? Oh, well there'll still be the weekend to fix it I suppose! 2. The contingency plan to close on December 30 as well would seem to be superfluous. Will the decision to close then be made half way through testing on 31st when they realise they don't have enough time? 3. Moving the deadline from March 31 to June 30 would also appear to be a time waster. What will happen if some banks are still lagging behind in June, will the deadline move again? Will it keep moving until it reaches December 31? That's one deadline which won't move! 4. That some bankers were not even aware of the Y2K problem is beyond belief. Which banks? I want my money out now! 5. The CEB is only testing power plants they suspect aren't compliant. What about the rest? 6. [Power plant] Sapugaskanda was confirmed as compliant, but won't work after 2001. How many other power plants around the world will fail on January 1, 2002? 7. The operating system is too advanced for the local staff. What more can I say?
Computer terminology is becoming more precise: the International Electrotechnical Commission, which creates standards for electronic technologies, is adopting new prefixes to describe data values. The new term "kibibyte" will more accurately describe the number of bytes in a kilobyte — rather than being 1,000, as could be inferred by the prefix "kilo," a kilobyte actually has 1,024 (2 to the 10th power) bytes. The metric prefixes currently employed — kilo, mega, giga, etc. — accumulate as a power of 10, rather than the binary system used in computer code. Thus, the Commission will use kibi, mebi, gibi, tebi, pebi and exbi to express exponentially increasing binary multiples (2 to the 10th power, 2 to the 20th power, etc.). "There was a need to straighten this out," says Barry Taylor of the National Institute of Standards and Technology. (*Science*, 12 Mar 1999; Edupage, 16 March 1999) [This may lead to kibi-tsars, mebi-or-mebi-not, gibi-ous moonings, tele-tebi, pebi-le-mocha, and exbi-gated Websites. (Garrulous in the NIST?) But, following on an earlier observation from Peter and Dorothy Denning, it does create a new solution to the Y2K problem: Change K from kilo to kibi, which puts the problem off until 2048. PGN] <REMINDER to the media: PLEASE STOP calling it the Millennium Bug. It is a really a collection of design flaws and not just a program bug, and it is not the end of the Millennium, for which we have to wait until "1/1/01"!> PGN]
Port Moody, BC, (where I currently reside) installed some nice "Welcome to..." signs a few years ago. They incorporate a nice little automated light display which typically is used to tell us about upcoming local events. For the last month or so, one sign has been consistently displaying "NO CARRIER". Which probably gives us some indication about how these are getting their daily dose of information. Wonder if the modem is fried or did someone forget to pay the phone bill? Stuart Lynne <firstname.lastname@example.org> 1-604-461-7532 <http://edge.fireplug.net> [Carrier is a major producer of air conditioning. In that the air in Port Moody obviously does not need conditioning, I'd like to imagine that the sign was hacked by the Carrier Corporation in protest. But more likely, the sign is programmed to grab the message of the day remotely and could not connect. PGN]
About a year or so ago, I got a letter from the marketing department of British Gas (with whom I have a gas account) addressed to me as "Mr Attorney". My bills arrived correctly addressed to "Mr Atty". I subsequently discovered my father had had a similarly addressed letter. This summer I moved house, and moved my gas account. Properly addressed bills arrived. Then, last week, a marketing letter arrived for "Mr Attorney". So, somewhere inside British Gas is something that transfers names and addresses from their billing system to their marketing system. And for some incomprehensible reason, it treats people's names as abbreviations and expands them. And what is even odder, it doesn't expand titles ("Mr" rather than "Mister". The fact I'm "Dr", and have told them so, is a side issue). Overseas readers should note that "Atty" is not used in Britain for "Attorney" - I'd never come across it in my life until I started to use the internet. So anyone else with my (rare) surname could be utterly confused. Needless to say, the letter completely fails in persuading me I should let them anywhere near my heating system. And I've had a lot of fun wondering just what it does to other people's names. Nick Atty
Following up on the recent discussion of Y2K fraud, readers might find this URL of some interest. http://www.cba.ca/eng/Media_Centre/Press/990309-a.htm It describes a telephone scam where the caller identifies himself as a bank employee, and requests personal account information to help verify their Y2K testing. Elliot Silver, ALI Technologies Ltd., 95 - 10551 Shellbridge Way Richmond, BC, CANADA V6X 2W9 604/279-5422 x376 email@example.com
Anthony Nudelman <firstname.lastname@example.org> writes: > This is an update about California, taken from > http://www.immigration-lawyer.com/news/DOL.htm > > CALIFORNIA LCAs RE-ROUTED TO DOL/WASHINGTON, DC > 5 Mar 1999 (report from AILA) > Due to a severe breakdown in Region IX's computer system, LCAs (for H1B > petitions) and labor certifications have been at a complete standstill. > After extensive negotiations, AILA liaison attorneys report that the > problem has been temporarily resolved by electronically filing these > Region IX petitions at the DOL office in Washington. LCAs caught in the > backlog can be refiled to the electronic system at DOL headquarters. Jason Steffler
Re: Neumann, RISKS 20.24 and Minow RISKS 20.23 PGN> As we approach April Fool's Day, it seems to be more difficult to separate the wheat from the chaff, as in the case of "Mobile phones cause memory loss" in RISKS-20.23, which is speculative at best. The article in _The Register_ referenced by Martin Minow was vague, but that, it seems, was a deliberate joke, changing names and places each paragraph and repeating itself to make the reader think that they had used their mobile 'phone too much! The story does not seem to be a fabrication, though. More serious articles on this topic, with more information, can be found at the BBC News site: http://news.bbc.co.uk/hi/english/health/newsid%5F288000/288245.stm "Scientists cut their mobile phone use" (1999-03-01) Colin Blakemore, Waynflete professor of physiology at Oxford University, is reported as having cut back on his own use of mobile telephones, and speculating upon short-term and localised effects of microwave radiation near certain parts of the brain; but is also reported as saying that reports that suggest that mobile telephones could cause permanent damage should be treated with caution. Some of the pertinent details missing from or not clear in the article in _The Register_ are that the research that sparked the story was carried out at Bristol Royal Infirmary, by a team led by Dr Alan Preece, and that it will be published in April in the International Journal of Radiation Biology. (Does the IJRB publish April Fool articles?) The article also includes quotes from the National Radiological Protection Board and spokesmen for the mobile telephone industry. http://news.bbc.co.uk/hi/english/health/newsid%5F296000/296976.stm "Mobile phone caused brain damage, claims man" (1999-01-15) A former BT engineer is suing BT for damages of up to =A3 100,000, claiming short term memory problems as a result of being required to use a mobile telephone for up to 90 minutes. More quotes from the NRPB.
I just go this happy note from a sender who will remain anonymous for obvious reasons. Before continuing on, the reader should be aware of the previous threats made by several virus writers associated with codebreakers.org (published in a recent Risks) who were offended by the fact that their ISP decided to shut their site down. They believe that I caused this to happen and have decided to get even by associating my name and Web site with the virus. I did not write the virus and it has never been to my Web site or on any of my systems (I don't run Excel or Word). FC > Here's a message (see below) I have just posted to the following three > newsgroups: [...] concerning two word documents which I downloaded > containing a virus. The file information for both documents listed the > author as Fred Cohen and the corresponding website as www.all.net > Just thought you might be interested to be informed. Perhaps if Mr Cohen > wasn't the perpetrator of the virus himself, then perhaps he should be > aware that his system has picked it up from somewhere and passed it on! > > N > > ===================================================================== > > I recently (& stupidly?) downloaded two Word documents from, I think, one of > these newsgroups, which supposedly gave details of adult site passwords. > (Contents of files repeated below - both were the same.) > > Although I subsequently deleted these files, my copy of Norton AntiVirus > (armed with the latest set of virus definitions dated 8 March 1999) later > detected that these files were infected with a virus. (It detected them > because, although deleted, they were still present temporarily in the Norton > protected recycle bin.) > > The virus is called 097M.Jerk and is a Polymorphic macro virus which infects > Excel97 and Word97 files. There are apparently two variants, both of which > causing a message to be displayed in May/June I think. > > Just to warn anyone who might have downloaded these documents also! Beware! > > N > [Contents of the doc file omitted. PGN] Fred Cohen & Associates: http://all.net - email@example.com - tel/fax:925-454-0171 [Fred's extensive disclaimer omitted, as per RISKS policy.]
BKTMBSSC.RVW 990212 "Time Based Security", Winn Schwartau, 1999, 0-9628700-4-8, U$25.00/C$37.00 %A Winn Schwartau firstname.lastname@example.org %C 11511 Pine St. N., Seminole, FL 34642 %D 1999 %G 0-9628700-4-8 %I Inter.Pact Press %O U$25.00/C$37.00 813-393-6600 fax: 813-393-6361 %P 174 p. %T "Time Based Security" The idea is simple, and even elegant. Given enough time and resources, somebody is going to be able to crack whatever security you put in place. Therefore, instead of building ever bigger and more imposing (and expensive) walls, balance how long it will take someone to get through the wall against how long it will take you to figure out that digging is going on and how long it will take you to stick a fire hose down a putative gopher hole. The idea isn't, of course, radically new. Community policing officers have been saying the same thing in public security seminars for years. Make the bad guy take longer to get in, and you'll have more time for someone to notice, or for us to get there. Implementation, though, is not quite so simple. Especially when you are dealing with something as complex as a publicly accessible and networked computer system. Chapter one is a general promotion for the Time Based Security (TBS) model, which hasn't been presented yet. The introduction's cry that we never have enough time and have to move ever faster is reiterated in chapter two, along with another assurance that Time Based Security is what we need. The demise of the big, limited, simple to protect computer is bemoaned in chapter three. Chapter four says that the fortress mentality never did work, and besides, we want people (some people) to access our systems for some purposes. (Were it not for the fact that the chapters are so short, and the vague idea that we are getting closer to TBS, I would be getting a little impatient about now.) Sorry, but chapter five goes into the shortest history of computer security I think I've ever seen, six says it didn't work, and seven runs us right back to Jesse James. But by the end of chapter seven, we are at least pointed in the right direction: the security of a container is a comparison between the time the bad guys need to get in, and the time the good guys need to get there. This is repeated in a different form in chapter eight. Chapters nine to eleven repeatedly formularize this, pointing out that you need to measure your protection in terms of time to fail, and that the time taken to detect a problem, plus the time taken to effectively respond to it, must be less than the time the protection provides. Schwartau gets into a lot more detail, though for only one situation, with a questionnaire in chapter twelve. Chapter thirteen starts to get into the complexity of things, looking at the variable amounts of damage that can be done in a given amount of time. Fourteen looks at costs of attacks while fifteen talks about the value of data. The title of chapter sixteen seems to indicate that some things don't need protecting, while the content looks more like some things cannot be exposed to any level of risk. Recursion of detection is promoted in seventeen. I think that chapter eighteen is suggesting that you use multiple barriers to stop intruders. But I'm not very sure of that. Nineteen and twenty seem to be saying that you should protect vital points with greater security, and try to avoid "single points of failure." Chapter twenty one looks at improving the reaction time. Twenty two stresses the importance of taking a long time to look at all the options in order to assess your security. (This is in rather stark contradiction to the promises on the cover and in the introduction that TBS was going to provide a shortcut.) A few options to increase protection get some detail in twenty three while increased detection is looked at in twenty four. A metric is achievable with TBS, but chapter twenty five does rather gloss over the work you will have to go to in order to accomplish it. Chapter twenty six talks about denial of service, but does not really integrate it with the TBS concept. Some infowar classes are used to repeat the adjuration to put protection where it is most needed in chapter twenty seven. Twenty eight suggests that deception is a good protective tool. (Sounds just a tad like security by obscurity, but we'll let it go, shall we?) The final chapter again promises that TBS will give you measurable security. The concept is sound. The implementation is left as an exercise to the reader. copyright Robert M. Slade, 1999 BKTMBSSC.RVW 990212 email@example.com firstname.lastname@example.org email@example.com firstname.lastname@example.org http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade
C A L L F O R P A P E R S The Internet Society Year 2000 Network and Distributed System Security Symposium (NDSS 2000) Catamaran Resort Hotel, San Diego, California 2-4 February 2000 Dates, final call for papers, advance program, and registration information will be available soon at httl//www.isoc.org/ndss2000. Paper and panel submissions due 16 Jun 1999. GENERAL CHAIR: Stephen Welke, Trusted Computer Solutions PROGRAM CO-CHAIRS: Gene Tsudik, USC / Information Sciences Institute USC Information Sciences Institute, 4676 Admiralty Way, Marina Del Rey, CA 90292, email@example.com TEL: +1 (310) 822-1511 ext 329, FAX: +1 (310) 823-6714 Avi Rubin, AT&T Labs - Research Publ: David M. Balenson, Cryptographic Technologies Group, TIS Labs at Network Associates, Inc. 3060 Washington Road #100, Glenwood, MD 21738 1-443-259-2358 [NDSS 1999 was a really fine conference. Support your ISOC. PGN]
Please report problems with the web pages to the maintainer