A technically detailed article in the Swedish newspaper, Svenska Dagbladet (published 1 Apr 1997; http://www.svd.se/svd/lasvart/solvind.html) explains that the unusually high levels of cosmic radiation (so-called "solar wind") augmented by the presence of Comet Hale-Bopp is causing computer problems, including strange ticking and buzzing sounds that can often be heard if you hold a computer mouse to your ear. This is especially true if you first click on a Java applet. Svenska Dagbladet's researchers note that (1) solar wind strengths are unusually high for this time of the year, (2) the near presence of Comet Hale-Bopp may appear to focus the radiation or, alternatively, reflect it in a currently unknown manner, says researcher Torkel Willdmark. (3) Because it stretches around the world, the Internet comprises a gigantic antenna that, combined with the increasing number of digital superhighways, strengthens the signal. All together, this results in strange sounds that sometimes sound like extremely soft human speech. Svenska Dagbladet recommends that web-surfers empty their browser cache memory frequently to prevent the accumulation of this signal. This need only be done for the next few weeks -- until the comet has left the earth's vicinity. To determine whether you are affected by this problem, Svenska Dagbladet recommends that you move your computer's cursor over a Java applet, then turn off nearby radios and other noise sources. Then, hold the computer mouse to your ear: if you are affected by the solar wind problem, you should hear a soft hiss or buzz from the mouse. Clicking the mouse while it is to your ear, making sure that the cursor is over a Java applet, may make the problem more apparent. Svenska Dagbladet has a test page (accessible to English speakers) at http://www.svd.se/svd/lasvart/solvind.html and a sample of the sound at http://www.svd.se/svd/lasvart/comet.wav Translated and summarized by Martin Minow email@example.com [I note that mouse in Swedish is mus and apple is a"ppel; in German, Apple is Apfel, while Apfelmus is applesauce -- not applemouse. It mus' be a combination of solar winds and Hale Bopp that caused the \344 character for the second letter of Mats Naslund's last name in RISKS-19.01 to cause the entire issue to be bounced by a bunch of systems unable to deal with 8-bit to 7-bit conversions. Let me know if you did not receive your copy and you cannot ftp it. PGN]
This isn't a particularly new risk, it's too bad that there is apparently no way that a credit card could be "partially" deactivated (that is, only valid if the merchant had the actual card in hand, and that verbal transactions would be rejected). What would happen if someone were traveling out of state and all of a sudden had a dead credit card?.. I've always resisted having multiple credit cards, but it sounds like maybe it's a good idea. Date: 31 Mar 1997 19:53:55 GMT >From: firstname.lastname@example.org (Adrian Brandt) Newsgroups: ba.transportation,misc.transport.urban-transit Subject: CalTrain computer stolen -- rider alert! CalTrain's ticket-by-mail computer has been stolen. It contained credit-card data for customers using credit cards to pay for their ticket-by-mail. The computer was stolen out of the ticket-by-mail office inside of the historic Santa Clara CalTrain station building. CalTrain spokeswoman Rita Haskin said CalTrain has, through its bank, initiated account cancellations for all the credit cards in their database. She expressed some surprise when I told her my credit card worked fine on the Saturday before Easter. I've not tried my card since then, but the clear implication was that she already expected my card to have been cancelled by that time. Haskin said that letters of explanation have been sent out to all ticket-by-mail customers as of Saturday. I really, really wish that CalTrain had encrypted the credit-card data, or otherwise taken better care of it--because now I've got to go through the hassle of getting a new card and contacting other institutions or businesses I may have made similar "auto-pay" arrangements with... Adrian Brandt (408) 565-7291 / email@example.com
Bloomberg News reports today (e.g., *San Francisco Chronicle*, C3) that Windows NT security can be breached. Jeremy Allison (Cygnus in Sunnyvale) and Yobie Benjamin (Cambridge Technology Partners in San Mateo) discovered they can extract passwords. Microsoft downplayed the discovery, saying the NT system is ``fundamentally secure''. MS VP Rich Tong said, ``This is not a major security hole.'' Details were a bit sparse.
> (Recall that the meter was recently changed so that the speed of light is > exactly 3,000,000 [should read 300,000,000] meters/second). Actually, a much cheaper solution than fixing all of software and hardware is to slow down the Earth's rotation so 1 year is exactly 365 days. Changing the orbit costs more and messes up the entire solar system, so changing the length of the day is the best solution.
It's not just aging mainframe computers that will go haywire when the clock strikes midnight on 31 Dec 1999 -- the electronic devices we encounter in everyday life could have problems, too, according a letter drafted by three U.S. lawmakers responsible for overseeing public and private sector responses to the Year 2000 problem. "Critical systems that depend on automated devices include security systems for badge readers, surveillance and home security systems, parking lot gates, and vaults. Other products that rely on embedded computer microchips include telephone systems, video recorders, bar code readers, automatic teller machines, medical devices, factory machinery, civilian and military avionics, process control and monitoring equipment, sprinkler systems, and air-conditioning systems." (BNA Daily Report for Executives 25 Mar 1997; Edupage, 30 March 1997)
firstname.lastname@example.org writes: > On my Linux machines, I keep the hardware clock on Universal time > to avoid time-zone problems. One machine is used for both Linux > and MS Win95, so I set the Win95 time zone to "Greenwich Mean Time". > At least that's what the map on the Control Panel called it. Why shouldn't it? GMT is the correct and current name for British civil time. It implies the DST (if selected) will be British Summer Time. That is the behaviour I want when selecting GMT in Windows 95. You don't say what Linux you are running, but Caldera OpenLinux allows the hardware clock to run local time and strongly recommends this if the machine is shared with another operating system. Al Grant, Cambridge University Computer Lab
In the Belgian newspaper Le Soir (http://www.lesoir.com), a journalist related his experience. Last week-end, he came back from Wales (after a soccer match). His plane lands at the Brussels airport. Our friend goes to the parking lot. It is 1:58 AM (Sunday morning). He takes his ticket and puts the money in the machine (entrance of the parking lot), goes to the exit in his car, puts the ticket into the device to open the gate. But, the gate doesn't open. Our reporter looks for an employee. They check. And all is clear. The device has changed its time. Explanation: the ticket was paid at 1:58 AM. The reporter tried to exit at 3:05 AM. And you are not allowed to saty in this parking lot for more than one hour. Andr=E9 Sintzoff Braine-l'Alleud, Belgique Andre.Sintzoff@ping.be [At the other end of the spectrum, don't forget Tsotomu Shimomura's tale (RISKS-13.28) of being charged $3771 because of a 1992 leap-day glitch. PGN]
I know a businessman who runs a mail-order business. He claims that for the first time in over twenty years his mail order business is declining slightly in a market in which sales are growing -- despite his quite competitive prices. He believes his competitors are using the UPS tracking system to uncover his customers. Despite not being a computer person, he deciphered the simple checksum system after some day's thinking about it, and showed me how he is able to fetch a random package destination of his competitor's in under a minute of effort. He is quite angry at UPS, and considered using FexEx to ship his packages, but found the FedEx system similar enough to enable him to do the same thing. He wishes there were a way to force UPS to improve security as soon as possible. Meanwhile, he is turning the tables on his competitors by laboriously retrieving their shipping destinations. Needless to say, I declined to automate his efforts.
I fear the steady stream of news reports about yet another security flaw in this or that web program may give rise to some severe metarisks; I dunno which if any of the following possibilities would be most likely: o A "boy-who-cried-wolf" reaction -- maybe people will start ignoring stories about Yet Another Web Security Flaw. o An exaggerated fear of security problems may cause people to give up on the Web entirely. I dunno whether using the Web to buy stuff is more or less risky than using older technologies to accomplish the same tasks. I do know that older technologies are far from 100% perfect; for instance both my wife and my father have had their bank accounts hit by check forgers. o Those who favor tighter Government control over the Internet may use such incidents as "evidence" that the net community can no longer be trusted to run something that is rapidly evolving from nifty techno-toy to serious communications infrastructure. o Overly-rapid attempts to fix the known bugs in what are, by and large, kludges that were implemented in a big hurry may produce more and worse bugs. I strongly believe the root cause of most web-related security holes is that market pressures pushed developers to concentrate on implementing new features quickly, without taking the time to do it right. The most positive imaginable outcome would be for those who develop web software to slow down and focus on getting things right; anybody wanna lay odds on _that_ happening any time soon? Matthew.Healy@yale.edu http://paella.med.yale.edu/~healy
If you have a page that is fetched by SSL GET that has links offsite, then targets of those links get whatever secure information was passed to the site over SSL because of the 'Referer' header field. For example, imagine I'm shopping at LL Bean and I enter my credit card number on a page and submit it. Then that page has a link to the Wall Street Journal. The Journal gets my credit card number in the referrer header. I don't know for sure that this is the problem described here, but it matches the described facts and I've verified that this problem in fact exists. There is an interesting variant of this involving inline images on pages which are fetched with SSL. They get the Referer header too. Now, there are several ways this can go wrong: 1. GIFs that are pointers to other web sites. E.g. advertising or the ever-popular numbers used to display the number of hits on the page. This has the same consequence as described in the article, that is to say that the site which is referenced gets the referrer header. 2. GIFs that are pointers to the same web site but are fetched using HTTP. Navigator seems to forbid this (i.e. it pops up a warning box and then refuses.) IE pops up a warning box about loading insecure media (which you might very well not mind doing) and then proceeds with the fetch. The consequence of this is obvious: your secret information which you went to all that trouble to encrypt is now passed over the net in the clear. In general, all links off an SSL page whose URL+arguments is sensitive need to be SSL protected themselves. > :: Server-side remedies include referring visitors to an in-house dummy > page to "wipe the browser's feet," or use the POST command instead of GET. "Wiping the browsers feet" will work, but the dummy page must be fetched with SSL itself, otherwise you'll just pass that secret information in the clear when you fetch the dummy page. > > Users finally, can protect themselves by typing in Internet addresses > > manually instead of using links from "secure" pages. As the inline GIF cases above show, this remedy is insufficient. This seems to be another case of the law of unintended consequences. Neither SSL nor the Referer header is the problem. It's the combination of the two that creates it. Eric Rescorla, Terisa Systems
A risk of using the GET method of the HTTP protocol for sending in confidential data (such as credit-card numbers) was reported widely yesterday including on CNET (see http://www.news.com/News/Item/0%2C4%2C9193%2C00.html?..). Warning: this link may be outdated soon. The article states: For users, security risks could arise if they make a purchase at a site that uses the GET function to retrieve their credit-card data. Once a user has submitted an order and credit-card number, the data is sent to the Web vendor in encrypted format. But if the user clicks on a hyperlink to another Web site, they could be exposing their unencrypted credit-card data to that site. What is not explained in the article is why credit-card numbers are at risk. The sum and substance of it is that when the Web site uses the GET method in a query or form to retrieve your credit-card number, the parameters of the query are logged in the Web server log files. Using the POST method does not appear to log the parameters of a query. If you are dealing with a secure site to whom you are sending your credit-card number, sending your sensitive parameters using either method should be OK---since the data is encrypted in transit to the site regardless of the method. You also trust that site to carefully handle the credit-card number once it is decrypted on their server. The problem arises when you jump to another site (that has no business knowing your credit-card number) after you have submitted your form. The next site may very well be keeping a record of where you were "referred" from. That is, the server logs of the next site will record the previous site you jumped from before arriving at their Web page. In the one popular Web server, the referrer_log file records this information. For example, using Alta Vista's search engine for "java security", I found our Web site, then jumped to it. Looking at the referrer_log entry below, I find not only the site I jumped from, but also the parameters of my request. Alta Vista's query form uses the GET method. http://altavista.digital.com/cgi-bin/query?pg=q&stq=50&q=java+security&r=java+security+ -> /java-security.html It is easy to see how filling out one of these forms with sensitive information like credit-card numbers can be recorded in the next site's referrer logs. The risks are obvious. When using the Web for Internet commerce activities, people expect that a secure session will protect their credit-card numbers from unauthorized third parties. This vulnerability in the GET method illustrates how this may not be the case. This risk also illustrates the lack of privacy in Web surfing. Not only do you leave your calling card when you hit a site, you also let the site know where you came from and potentially any sensitive data you may have submitted to the last site (if the GET method is used for a form). Finally, it is important to realize that even if the POST method is used and a secure protocol layer such as SSL is employed to protect the data in transit, the data inevitably ends up in plain text on the Web server's host machine. The privacy of that data is now only as good as the security of the Web server and scruples of the people handling the data. Anup K. Ghosh, Ph.D. http://www.rstcorp.com/~anup Research Scientist Reliable Software Technologies Corp., Sterling, VA
> Dead Bolt allows online users to share their "blacklists" of spam > purveyors so that they can more effectively filter offending e-mail. Something like this has, unfortunately, become necessary. It will happen someday. Stopping spam is a topic near and dear to me, and I've already considered the risks mentioned. > The risk of false and malicious blacklisting of non-spammers. This is a serious problem. A step towards solving it would be a secure clearing house of data on spammers. It would need to be distributed via a technique like PGP-signed Usenet messages or a on online database downloadable through some secure transfer medium. Whoever maintained the database would need to somehow decide what went into it and what didn't. The entries would have to be classified by reliability level so that the users could decide which data to use and which to ignore. Unfortunately, doing this would subject whoever did it to a suit by spammers who didn't want to be blocked. I haven't figured out a way to avoid this particular risk short of establishing the operation in a country without spammers. > The risk of harm to innocent bystanders who happen to share hostnames, > ISPs, or other characteristics with targeted spammers. This is not a risk. This is a benefit. If users at an ISP get blocked because the other users at that ISP are spamming, they will take their business elsewhere. ISP's will either take measures to avoid harboring spammers, or they will lose their customers and go out of business. Either way, spammers will have one less place to hide. > The possibility that spam messages will avoid detection by varying return > addresses and other signatures in each copy of a message. If the source of a spam can be discovered, this is not a problem. The original spamming host is going to show up somewhere in the Received: line, even if only as an IP number. Poorly configured sendmails on intermediate (relay) hosts might not properly include the Received: information. If this is the case, the defective site should be blocked until its owners fix it.
A recent trend in the war against spam is to munge the "From:" line in outgoing Usenet and e-mail messages (e.g., by adding asterisks or exclamation points to the beginning or end of the userid). These messages are typically accompanied by a terse note at the bottom of the message instructing respondents to "Remove asterisks [or whatever] from my address if you would like to reply." I see several risks with this technique: - False security: Most mail and news agents will dutifully add a "Sender:" line containing the "actual" e-mail address, if the user-supplied "From:" line doesn't look right. Since many spammers already gather addresses from the "Sender:" line, munging the "From:" line provides only limited protection. - Inconsideration: In that a munged "From:" line reduces the spam received, it reduces the amount of work the munger has to do. So instead of having to press one key to delete a junk e-mail message, everyone that wants to reply to one of his messages has to (a) notice that the address is bogus (b) press many keys to fix it. (Indeed, some mail readers make it quite tedious to edit the headers in replies.) In other words, it hasn't eliminated the problem; it's merely shifted the work from the sender to his correspondents. - Lost messages: a non-scientific survey of some novice-user friends indicated that a large number of them had no idea what the "remove asterisks..." directive meant, how to perform this task, or what to do with the bounced messages that will result from the failure to do so. - False security 2: In the ever-escalating spam arms race, it won't be long before spammers' address-gathering software is modified to unmunged munged "From:" lines. (I can think of two obvious techniques, which I won't describe here so as to avoid providing aid and comfort to the enemy.) Wayne
In RISKS-18.94, Lord Wodehouse reports on the problems some UK banks have had in clearing pay checks, and speculates on the difficulties this could cause, especially as it occurred just before a four-day bank holiday. An article on these kinds of risks appeared in CACM in the mid- to late-70s. At that time, ATM's and direct deposit were just beginning to appear. The authors of the article, as I recall it after all these years, foresaw all of the problems Mr. Wodehouse mentions. They speculated on the potential for much larger-scale problems - "bank blackouts", in which problems in one bank system would cause overloads, delayed deposits, and ultimately failures at other bank systems (much as power system problems can propagate to the systems to which they are connected). I recall being impressed with the article at the time it was published, and surprised over the intervening years that so little of what it speculates on has actually occurred. Perhaps, as with many technological predictions about *positive* results of technology, it's not so much that the prediction is wrong as that the effects it predicts take much longer to arrive than expected. Jerry
In RISKS-18.96, Thiemo Sammern <email@example.com> wrote on the subject "Printing with different resolutions in MS Word 7.0" about documents not looking the same on 300 dpi and 600 dpi printers and commented on the Windows API for advance width using rounded integers. This is a well-known characteristic of Windows typography. Microsoft thinks it is a feature, judging from posts I have read from MS personnel in the newsgroup comp.fonts. It does not take multiple printers to see this. Just set up a spreadsheet with text overflowing a cell boundary and then zoom the display in and out. You will see the cell border shifting relative to the text characters. The risk? Mainly that Windows typography is not "wysiwyg" although one would naively think so. Some applications manage true wysiwyg, others do not, and document portability has been sacrificed. Some applications have smarter typographical guts and avoid this problem. I believe that WordPerfect is one of them, as long as you use the WP printer drivers. Various high-end typesetting programs also manage this. In all fairness, I should add that MS's reasoning is related to their emphasis on on-screen output. They apparently overlook or don't know that many people prefer good old-fashioned paper to on-screen display. Perhaps we see here the risk of one man and his business having far too much power and influence. Rodger Whitlock
COMPASS '97 12th Annual Conference on Computer Assurance June 16-19, 1997 Gaithersburg, MD, USA WEB SITE http://hissa.ncsl.nist.gov/compass/ Sponsored by IEEE Aerospace & Electronic Society IEEE National Capital Area COMPASS (COMPuter ASSurance) is an annual conference held in the Washington, D.C. area with the purpose of bringing together researchers, developers, integrators, and evaluators interested in problems related to specifying, building, and certifying high-assurance systems. What distinguishes COMPASS is its emphasis on bridging the gap between theory and practice. The theme of COMPASS '97, "Are we making any progress toward computer assurance?", will focus discussion on whether the approaches developed and reported during the past twenty-five years have any hope for solving today's assurance problems. In addition to exploring technical strengths and weaknesses in the state-of-the-art and state-of-the-practice, conference goals include: identifying barriers to applying existing assurance technologies in industry, understanding what properties new technologies must have to meet industrial needs, and identifying advanced technologies that are effective in attacking the key problem areas of safety, security, fault-tolerance, and real-time control. For researchers, COMPASS '97 provides an opportunity to present new theories, techniques, methods, or results of case studies to other researchers and practitioners who can put them to use. COMPASS '97 also provides a unique opportunity for participants to learn from practitioners about issues and problems encountered in constructing practical systems. This mix of cutting-edge research and practical real-world experience is unique among software conferences. Dolores R. Wallace, National Institute of Standards and Technology, NIST NORTH, Bldg 820, RM 517, Gaithersburg, MD 20899 +1(301)975-3340 http://hissa.nist.gov [COMPASS is one of the few conferences that encompasses most of the risks requirements -- safety, reliability, security, etc. -- and application areas. PGN]
Please report problems with the web pages to the maintainer