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…
Seen at http://news.bbc.co.uk/1/hi/wales/3492778.stm A mother is urgently appealing for help after her eight-year-old son's heart monitor scanner was stolen from her car outside the family home. Daniel Hunter from Bridgend in south Wales, is fitted with a pacemaker which is monitored by the scanner — the size of a mobile phone — without which his health is at risk. It is the only one he can use, and if it is not found he will have to undergo potentially dangerous operation to be fitted with a new pacemaker — a device which sends electrical impulses to the heart to keep it beating regularly. The idea of an implantable medical device apparently requiring physical reconfiguration (at least) to talk to an external monitor implies a level of trust in the reliability of the external device which is seriously scary. The RISKS hardly need pointing out here...
IT GlobalSecure sells software that prevents network vandals and dishonest players from manipulating online gambling. The company's chief executive says: "If you look online, there are whole Web sites either complaining about cheating or sharing ways to cheat. We've had people who are even just playing gin rummy online saying, 'We think we're being cheated, but we don't know what to do.'" The firm's software is based on encryption technology that can be applied to any network gaming system to validate the randomness of events in games of chance, verify player identities and create audits of each game. [*The Washington Post*, 1 Mar 2004; NewsScan Daily, 1 Mar 2004] http://www.washingtonpost.com/wp-dyn/articles/A17983-2004Feb29.html [What about keeping the gambling software "honest"? PGN]
[From Dave Farber's IP list, where the identity of the contributor was withheld. PGN] The Tokyo Metropolitan Police arrested three men on suspicion of trying to extort up to 3 billion yen (U.S. $28 million) from Softbank. The suspects claimed that they obtained DVD and CD disks filled with 4.6 million Yahoo BB customer information. The two of the suspects run Yahoo BB agencies which sells DSL and IP Telephone services. Last month, Softbank was contacted by the suspects who demanded investment to their venture in exchange for the disks. Although the company confirmed that a part of the customer data shown by the blackmailers was that of real Yahoo BB customers, the company so far has not admitted their whole customer data was stolen. The police and Softbank will examine the data on the seized disks. It will take several days before we know the exact scale of the leak. According to Softbank, the stolen data includes name, address, telephone number, and e-mail. No billing or credit card information was leaked. Also, it has been reported that the police in Nagoya arrested another man who attempted to extort 10 million yen (U.S. $ 90,000) from Softbank. The man sent the company e-mail messages including the one with 104 customer data and claimed to have over 1 million customer information on floppies. He worked as a temporary customer support personnel for Yahoo BB in the past and it was likely that he stole the customer data while he worked for the DSL provider. The police considers the Nagoya attempt is not related to the Tokyo case and the sources of the data leak are different. At this point, there is only speculation on how the customer data was stolen. The data was not accessible from the public networks and Softbank denied any intrusions to their computer networks from the outside. It was likely to be an inside job. There might have been an accomplice(s) in the company or its subsidiaries/affiliates. An Softbank executive stated that there were over 100 people who could log-on to the PCs connected to the customer database. The company is in the process of cheking the log to find any suspicious access to the data. (Although Softbank is a victim of hideous crime, I expect that there will be a lot of scrutiny on the company's policy and practice regarding data security and privacy protection.) Although the both extortion attempts were foiled, the backgrounds of the Tokyo suspects are disturbing. One of the Tokyo suspect is the leader of a right-wing political organization. In Japan, the shady right-wing groups are often a part of the organized crime(Yakuza gangsters) or have a close tie with Yakuza. It is unthinkable that the 4.6 million personal data fell into the hands of the underworld. The bogus Internet bills from the use of dating and porn sites have become social problem in Japan.(Even they have no idea of using those services, some people send money when they receive a letter or e-mail from the collection agencies sounding like Yakuza-related. I am hoping the suspects are just bluffing.) The other two are the followers of a powerful religious group affiliated with a major political party. According to some tabloids, one of them was a former ranking member and was participated in the wiretapping of the home of the communist party leader in some 30 years ago (The communist party and the religious party were strongly criticising each other then.). Although he was acquitted in criminal courts, a civil trial acknowledged his involvement (like O.J.?). The opposition parties are demanding the government to investigate the unprecedented scope of the personal data theft and a committee in the House of Representatives is considering to call Masayoshi Son, the Softbank president to testify. IP Archives at: http://www.interesting-people.org/archives/interesting-people/
The German online news magazine Spiegel Online [1] recently reported on an
interesting combination of risks [2]: using T-Online as your Internet
provider, and having a WLAN access point.
T-Online is Germany's largest Internet provider, and while this in itself is
not a risk, T-Online has always used a unique approach towards POP3 mail
delivery. When being connected via T-Online, one does not have to provide a
username or password to connect to the T-Online POP3 server in order to
fetch mail, since the user is identified by his IP address.
Combine this with the growing number of (unsecured) WLAN access points and
DSL routers and you get to read other people's mail just by driving along
the streets. T-Online is aware of the problem, and provides information to
secure WLAN access points on their web site, but changing the POP3
identification system (which was introduced long before anyone thought of
broadband Internet, connection sharing and wireless LAN) seems to be almost
impossible, having millions of customers.
[1] http://www.spiegel.de
[2] http://www.spiegel.de/netzwelt/technologie/0,1518,288033,00.html
[PGN showed this a colleague, who commented thusly:
"Just how long have we been telling people that it's a bad idea to do
authentication based on IP address? The Berkeley r-commands, after all,
where supposed to be an interim solution, IIRC. That was 1982.
Anyways, I'm quite sure that this was known to be a Bad Idea(tm) before
T-Online went into business."
And when a very well-known bank first put up its Internet banking on the
Web, it authenticated on IP addresses. Bad ideas are often popular.
PGN]
Lawrence Kestenbaum substantiates in his RISKS-23.19 note the considerable problem generated by inappropriate e-mail server responses to virus/worm/spam e-mail, which I noted with regard to Sobig (Some observations on e-mail phenomenology, RISKS-22.88). However, his last paragraph misplaces blame. The spammers and worm/virus writers are no more responsible for the amounts of junk generated by misconfigured e-mail servers than I am responsible for the damage caused by an automobile whose driver does not observe my bicycle until the last second and manoeuvres suddenly. I agree with Kestenbaum that the e-mail system is more or less broken. *The Economist* has addressed the issue in its edition of 14 Feb 2004 (Business Section. The article is available on its WWW site for a fee to non-subscribers). In an article entitled "Make 'em pay" (supertitled "The fight against spam", subtitled "The dismal science takes on spam"), the journal suggests that techies have had a go at the problem, then politicians, and now economists are "taking over". Risks readers may recall that Bill Gates said in an interview at the recent World Economic Forum at Davos that certain measures Microsoft favors will get rid of spam in two years. One of those proposals was a per-mail fee, like postage. The article says that "Sceptics noted that Microsoft could also help by fixing security flaws in its products — the latest confessed to this week — that can be exploited by spammers". The article discusses various schemes, namely those by Goodmail Systems, IronPort Systems, and Balachander Krishnamurthy at AT&T Labs. I hope that the techies and politicians are not yet finished. The payment proposals distinguish between two classes of user: bulk mailers and others. (The post office does also: bulk mail there is cheaper than ordinary mail.) Bulk mailers should, somehow, pay. But not all bulk mailers are spammers. I suggest that a much more fundamental distinction lies between fraudulent e-mail (e.g., that with intentionally false header information) and non-fraudulent e-mail. In my opinion, this issue must be addressed come what may. Fraud in electronic communication covers much broader issues, even for business, than spam and its responses: for example, one needs reliable processes for establishing, validating and enforcing contracts electronically. E-mail authentication would be a great help. Since the e-mail server market is dominated by very few pieces of SW, one imagines a coordinated effort to alter e-mail protocols to introduce some degree of authentication, say along the lines of Tripoli, lies at least as well within reach as schemes to introduce payment for e-mail. We may presume that producers of such SW are well aware of such proposals, and we may conclude that they are not favored because they do not fit someone's business model. I find some confirmation for this conclusion in that schemes to introduce individual payment for free e-mail service are being touted at the very time when just the reverse is happening with telephony: schemes for Internet telephony are apparently arousing interest in major telecommunications companies over the traditional individual payment model. I imagine that if one is a commercial SW producer it is easier to make money by responding incrementally to Internet users' issue du jour rather than by introducing a procedure that would handle a large class of such problems all at once. One argument in favor of the business model could be that the economy which has sprung up to deal with spam and Internet security issues is now large enough to lobby successfully against any proposal that would reduce its potential clientele at a stroke. If this is so, then incremental modification would seem to be the only socially viable possibility. What a depressing thought. Peter B. Ladkin, University of Bielefeld, http://www.rvs.uni-bielefeld.de
I always say, whenever laptops are mentioned: "Forget everything else, I have nightmares already!". The loss of information due to laptop thefts is extremely high, here is an innovation that may possibly be as useless as car theft alarms (unless you are nearby and didn't leave the laptop in the car), but it's a good start. This may actually be useful. What I'd like to see is a GPS device with wireless communication to my cell phone. It can be a quiet indicator, or perhaps ring when it is being moved.. or even when I move too far away from it. You can find the article at: http://www.canada.com/vancouver/story.html ?id=511952d3-89a0-4a03-a092-be29eaeb346f
Chris Meadows account of printing sensitive information using a wireless network at Kinko's, only to discover that it had not printed on any printer _at_ Kinko's, reminded me of a vaguely similar occurrence circa 1990. I worked in R&D at a Fortune 500 minicomputer company, which at that time had one "corporate" fax number which connected to _one_ fax machine whose phone line was, understandably, usually busy. Someone at another company needed to send me an urgent fax. He happened to have a copy of my company's phone book. After listening to his fax machine redial continuously for five hours, he checked the phone book and noticed that it listed about fifteen fax other numbers. He selected the "R&D Documentation" number, and called me to let me know he had just gotten his confirmation that it had been received at "R&D Documentation." I went to R&D Documentation. They had no fax machine. They did not know of any "R&D Documentation" fax machine. Indeed, they did not know of any fax machine in R&D. The phone book had no information beyond the machine names and numbers. I worked my personal connections as best I could, asking every knowledgeable old-timer I knew to regale me with lore and legends relating the locations of _any_ fax machines other than corporate. I slowly discovered the location of several fax machines. The fifth one--located in Purchasing--happened to be the one that identified itself as "R&D Documentation." They'd inherited the machine and the phone line, and nobody knew how to change the message, so they'd left it set that way. Daniel P. B. Smith, dpbsmith@world.std.com alternate: dpbsmith@alum.mit.edu
Burroughs (now Unisys) large (now Clearpath/Libra) systems have had hardware detection of buffer overflows since at least the late sixties. Only memory areas marked as code are executable and only certain processes can mark the memory as such. Consequently, data cannot be executed. Furthermore, although data can be overwritten by the user, hardware bounds checking in conjunction with memory bounds markers prevents writing outside the bounds of data owned by the user. Usually this is a fatal error terminating the process. The fatal error can be suppressed so that the process continues, but the process still cannot write into data areas not owned by itself or into code areas. To a certain extent, these mechanisms also serve to protect the user from himself. Of course, the MCP (OS) can overcome these limitations through the use of special constructs in the language (NEWP) in which the OS is written, as can other processes written in NEWP and granted privileged abilities. It is also worth noting that only high-level languages are used for programming: there is no assembler or machine code programming (not even for the MCP, although some NEWP constructs are very close to machine code).
IIRC the late VAX/VMS systems also had built in buffer overflow prevention features, probably a lesson learned from Multics. The hardware had protections that could be set on memory segments to be: Execute/No execute and read only/write only/read-write, and the OS system calls requiring buffers also had to have the length of the buffers specified.
Issues associated with the MSJVM have been the subject of legal proceedings between Sun and Microsoft. Further information on the transition can be reached at http://today.java.net/pub/n/SUN_Upgrade_Site
* Regarding garage-door openers: Early garage door openers were quite simple. IIRC, some of them were no more than a sequence of Antenna, Bandpass filter, Energy detector. They operated at low powers in bands shared with other operations. Thus, false triggering of the garage door opener would not be uncommon. Steve Bellovin's calculations are correct. No way Sputnik could be exacted to trigger a garage door opener. In contrast, a 707 flying 1,000 feet above such a garage door opener could easily trigger it. Modern garage door openers use modulated sequences-i.e. a string of 1s and 0s-to carry commands. False triggering by other systems, such as land mobile or aircraft transmitters, is thus highly unlikely. * Regarding exploding batteries in cellular phones: This is not an urban legend. It has been widely reported. I recently received a letter, dated 9 Feb 2004, from legal counsel for the manufacturer of the wireless phone that I use. Some quotes from that letter: "an allotment of batteries ... Might contain a risk hazard." "the root cause was a quality-control issue at the battery manufacturer" "Of the 50,731 units shipped in the United States ... four(4) confirmed reports of rapid disassembly. Of these four (4) reports, one involved personal injury in the form of a second-degree burn . . " Continued use of the phone ... could result in injury due to ... rapid disassembly (which may appear as an explosion) ... " The risks of this lawyer weasel wording are obvious. While engineers may immediately recognize the hazards associated with "rapid disassembly" the everyday user may not. Only later in the letter does the more familiar term "explosion" appear.
I had a similar experience recently and reading this prompted me to check something I thought I remembered reading. In late 2002 the Shell company was under fire for having hidden mobile phone masts in the forecourt signs of 210 of its 1,100 UK petrol stations. http://news.bbc.co.uk/1/hi/uk/2309645.stm The criticism was directed at the perceived health risks associated with these masts — a much discussed subject in it's own right. I have been involved in the approval process for locating a transmitter close to gas storage tank, and most risks are calculated objectively. Substance stored, loading and dispensing methods, transmitter power, distances etc are all taken in to account. I am somewhat bemused that the urban myth of the dangers of using mobile phones in petrol stations is still being spread by the companies who own them.
A true story that can be found in the *LA Times* archives discusses problems
back in the 1980's when Reagan was president. When he was staying at his
ranch in California, Air Force One would be parked at a local Air Force base
near Riverside California. Whenever that plane was there, everyone for
several miles around would know because their garage door openers would stop
working.
As soon as the plane left, they'd be working again. The Secret Service
would not comment.
[This was noted in my ACM SIGSOFT Software Engineering Notes vol 11 no 2,
April 1985, issue, four months before the first issue of RISKS. Most of
the relevant pre-RISKS cases are indexed in my Illustrative Risks doc:
http://www.csl.sri.com/neumann/illustrative.html
(with .pdf and .ps for printing rather than browsing). PGN]
Try to plan a trip from Calais, Maine to Sault Ste Marie, Michigan, using the DeLorme mapping product, or a trip from Niagara Falls, New York to Detroit, Michigan. Look at the results and be prepared to spend extra time or days on the road. The same thing happens if you are trying to travel to anywhere where traveling through Canada is substantially shorter than traveling through the US. The reason? Delorme leaves Canada out of their product totally! To go from upper Michigan to upper Maine you go south of the Great Lakes if using their product but north of the Great Lakes if trying for a rational trip. If you ask Delorme, who are located in Maine, they shrug their shoulders and say that those who really care about that minor problem know to use other sources of information... [I.E. They don't seem to care.] For what it worth, the risks are not only online...
In Risks 23.20, Mike Brandt <MyLastName@syr.edu> was quoted as writing: "In the early days of Amtrak's online trip planner, I asked it about trains from Portland (Oregon) to Seattle. There are several trains each day that make this 3.5 hour trip. The first choice on the route planner's list was Portland -> Chicago -> LA -> Seattle taking about a week, and passing through Portland again 3.5 hours before arriving in Seattle." Has the problem been fixed? You be the judge. I live in Madison, Wisconsin, about 1/3 of the way across the North American continent. My sister lives in Denver, Colorado, about 2/3 of the way across. Amtrak's recommended route for getting from here to there had me going via Minneapolis to Seattle (apparently a magnet for Amtrak customers), then to San Francisco, then backtracking to Denver — about 4 times as long a trip as necessary once you add the extraneous north-south travel to the extraneous east-west travel. My solution was to take a bus to Chicago and catch the direct train to Denver from there. I was bemused to notice, however, that the westbound train to Denver was scheduled to leave Chicago half an hour BEFORE the eastbound one arrived from Minneapolis and Madison, so Amtrak was apparently trying to spare me a 23.5-hour layover in the Windy City. Good theory; bad implementation. Solution: More frequent passenger trains. I continue to be frustrated that Congress insists that Amtrak must be 100% self-supporting while it lavishes billions of dollars in subsidies on its competitors — highway builders; air-traffic control, National Weather Service, and airline bail-outs; and even the Army Corps of Engineers to keep the nation's locks, dams, and coastal waterways open to barge and riverboat traffic. The game is rigged, and once again the victims are being blamed for the system's failures. Richard S. Russell, a Bright (the-brights.net), 2642 Kendall Ave Madison WI 53705-3736 608+233-5640 RichardSRussell@uwalumni.com
Ulrich Lang/Rudolf Schreiner BKDSDSCO.RVW 20031201 "Developing Secure Distributed Systems with CORBA", Ulrich Lang/Rudolf Schreiner, 2002, 1-58053-295-0, U$69.00/C$106.95 %A Ulrich Lang %A Rudolf Schreiner %C 685 Canton St., Norwood, MA 02062 %D 2002 %G 1-58053-295-0 %I Artech House/Horizon %O U$69.00/C$106.95 617-769-9750 800-225-9977 fax: +1-617-769-6334 %O http://www.amazon.com/exec/obidos/ASIN/1580532950/robsladesinterne http://www.amazon.co.uk/exec/obidos/ASIN/1580532950/robsladesinte-21 %O http://www.amazon.ca/exec/obidos/ASIN/1580532950/robsladesin03-20 %P 308 p. %T "Developing Secure Distributed Systems with CORBA" Chapter one is an introduction, but it very quickly gets into CORBA (Common Object Request Broker Architecture) jargon, and C++ API calls. The explanations could be written with more clarity for outsiders. Security is first defined, in chapter two, in terms of restricting access, but the authors are not clear about whether they are primarily concerned with integrity or confidentiality. The material then goes on to a good overview of security management basics and a very brief outline of some security concerns in the CORBA environment. The lead- in to the CORBA security architecture, in chapter three, is a lengthy discussion of the benefits of flexibility, abstraction, and simplicity: the authors then note that the CORBA architecture is not simple. MICO, an open source CORBA compliant object request broker, has a security component (MICOsec), and chapter four is dedicated mostly to installation instructions. Chapter five looks at programming CORBA level one security, using MICOsec and C++, while chapter six takes a longer look at the more complex level two requirements. CORBA security does have support for applications that do not contain any security provisions (a rather interesting concept), and these are reviewed in chapter seven. CORBA security is not widely understood, and this work can assist both those needing a conceptual idea of the system and those needing to program with it. copyright Robert M. Slade, 2003 BKDSDSCO.RVW 20031201 rslade@vcn.bc.ca slade@victoria.tc.ca rslade@sun.soci.niu.edu http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade
Please report problems with the web pages to the maintainer