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…
On 10 Sep 2003, Tracy Weber and Charles Ornstein reported in the *Los Angeles Times* that the Martin Luther King Jr./Drew Medical Center was disconnecting a new $411,000 patient-monitoring system, after the deaths of two patients for whom alarms failed to alert nurses that urgent attention was needed in the summer of 2003. [PGN-ed] http://www.latimes.com/news/local/la-me-kingdrew10sep10,1,3521718.story
I was at a press conference on Thursday with PalmSource at One Aldwych, which is one of those hyper-modern London hotels. One of its features is a airplane-style vacuum-operated toilet system. One of the Palm execs told me that while they were staying at the hotel this system failed, and any time they wanted to use the bathroom or take a shower they had to call the reception desk and get escorted to the corporate headquarters in the building next door to use the facilities there. For a couple of *days*. It transpires that the entire plumbing system is run by a Windows-based computer system and whatever went wrong with it was so obscure that they had to get a technician from the company that supplied it on a plane down from Scotland to fix it and reboot. The Blue Screen of Sewage? [There's a "Sucker" Borne Every Evacuation! PGN]
A cart of Diebold electronic voting machines was delivered today to the common room of this Berkeley, CA boarding house, which will be a polling place on Tuesday's primary election. The machines are on a cart which is wrapped in plastic wrap (the same as the stuff we use in the kitchen). A few cable locks (bicycle locks, it seems) provide the appearance of physical security, but they aren't threaded through each machine. Moreover, someone fiddling with the cable locks, I am told, announced after less than a minute of fiddling that he had found the three-digit combination to be the same small integer repeated three times. One wonders whether paper ballots would be handled differently, how the terminals are stored between elections, what checks are done for tampering before the use of the terminals, and what physical security features are built into them.
The next generation of microprocessors will plug the gaps that have resulted in "buffer overflow" vulnerabilities, causing Microsoft to issue repeated "critical security alerts." The buffer section of computer memory stores a finite amount of data. To exploit the flaw, hackers cause more data to be sent to the buffer than it can hold, forcing it to overflow into the next chunk of buffer memory, where they then deposit their malicious code. This leaves the computer open to attack, as demonstrated by the devastating Slammer and Blaster worm invasions in 2003. "Buffer overflows are the largest class of software vulnerabilities that lead to security flaws," says the head of one security company. The new chips will be designed to block this avenue of attack, although security experts predict that determined hackers will find other ways to insert computer viruses — for example, by making a program jump to a subsection of its own code at the wrong time, perhaps to open a data port to a hacker. [*New Scientist*, 22 Feb 2004; NewsScan Daily, 23 Feb 2004] http://www.newscientist.com/news/news.jsp?id=ns99994696 [Historical reminder: In 1965, the Multics hardware (GE then Honeywell 645) provided segmented, paged, ring-structured hardware enabled the software to achieved measures of security that are not common today. The combination of hardware, the PL/I language subset, the language runtime environment, the stack discipline (non-executable, which cut way down on overflows; also, the stack grew to higher addresses, making the overflow of a buffer unlikely to clobber the return address in the stack frame), and good software engineering discipline helped prevent most buffer overflows in Multics. See Tom Van Vleck's subsequent message, as well as his Web site, multicians.org. PGN]
To make a big deal out of providing the 40-year-old feature of marking a region of memory non executable is kind of sad. Multicians look at each other and make the rubbing-sticks-together gesture. It seems to me that the marketing guys and the popular press writers don't understand the feature, the need for the feature, or what the feature will and won't accomplish. It's not magic. It fixes some common problems, leaving other problems untouched. It's not a substitute for defensive coding and proper management of storage; all it means is that if there is a mistake, it is more work for an attacker to exploit it. As Paul Karger points out, when attackers are frustrated by one measure, they don't abandon their attacks. They keep looking for other holes. A fix like this, applied by itself, will lead to a new equilibrium between attackers and defenders, maybe favoring one or the other, but the game will remain the same. Closing one open barn door is good, but it needs to be complemented by a systematic approach to enumeration of openings, and a method of closing the openings by architectural design that applies to all openings. So I was taught by my leaders on the Multics project, including Corby, Bob Morris, Jerry Saltzer, Ted Glaser, PGN, and many more.
Mike Cassidy has a column in the *San Jose Mercury News* on 24 Feb 2004 entitled "Sending e-mail can be a struggle if your name has a 4-letter word." A Scottish gentleman named Craig C*ckburn (generally pronounced Coburn) had all too difficult a time receiving his e-mail. It turns out that Mr. C*ckburn's job title is "senior IT application speci*list", which also has problems due to the word "speci*list" containing the substring "ci*lis" (when used as a proper noun, a Vi*gra competitor). Not new, but increasingly painful for many people. http://www.mercurynews.com/mld/mercurynews/business/8026783.htm Drew Dean, SRI International PS: How many spam filters will barf on this message? Or will PGN edit it? [Indeed. I took mercy on Drew's message and have tried to avoid the expected filters. Note other words such as "multiraci*alism", "soci*lism", "commerci*lism", and even "commerci*lise" (British), also get trashed, not to mention words in other languages. (The asterisks above are easily interpreted as the letter "o" or "a".) *@#$%*! <expletive deleted> PGN]
I don't remember seeing a posting about the suggested anti-captcha technique that was discussed recently on slashdot. A "captcha" is the (horrible) name used to describe the distorted graphics referred to by Thomas Harrington in RISKS-23.29. The (completely brilliant) idea is that every time spammers have to deal with such an image they bring it up on the screen of someone who is looking for free porn and pretend that they are doing a check. The user will respond and the answer gets forwarded back up the line. The /. discussion is at http://yro.slashdot.org/article.pl?sid=04/01/28/1344207&mode=flat, the original Boing-Boing posting is at http://boingboing.net/2004_01_01_archive.html#107525288693964966 Very hard to beat human ingenuity.
[Adapted from alt.fan.cecil-adams (by PGN, who adds that Mark contributed two similar items to RISKS-20.62, with a follow-up by Chris Smith in RISKS-20.63)] Phil Jern" <pjern1@comcast.net>: Somewhere around here I have driving directions that I printed out a few years ago that showed 4,900-odd miles for a trip from New Jersey to Atlanta that included 2 borders crossings in and out of Canada. Bill Kinkaid <billkinkaid@telus.net> The transit system here has a trip planner feature on their Web site (translink.bc.ca). You key in where you want to start, where you want to wind up and when, and it tells you which buses to take and when to get them. A few times in off-hour periods (say Sunday morning) it's given me some very bizarre routings where I can look at the map and say "I get on this bus here and get off it there, just tell me when". Telling me to go from Marpole to Coquitlam via South Delta and Surrey Centre, f'rinstance. Mike Brandt <MyLastName@syr.edu> 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.
Lawsuits filed yesterday by AOL and Earthlink accuse individuals and companies of running spam networks. The AOL suit alleges a conspiracy between three Floridians and two Americans living in Thailand to route mortgage-scam solicitations to AOL customers and to defeat AOL's spam filters through a company called Connor-Miller Software Inc. Earthlink is accusing 16 individuals and companies in Florida, California, Tennessee and Michigan of operating a multi-state spam operation that has sent more than a quarter of a billion e-mail messages promoting herbal supplements, Vi*gra and adult dating services and of using stolen identity documents to open Earthlink Internet accounts that were used to transmit the spam. The attorney who represents the Florida defendants in the AOL lawsuit argues that his clients are innocent of spamming: "They set up a network, just like AOL is a network." [*The Washington Post*, 18 Feb 2004; NewsScan Daily, 19 Feb 2004] http://www.washingtonpost.com/wp-dyn/articles/A52951-2004Feb18.html
"According to airline-security documents obtained by this magazine, the name Osama bin Laden was punched into the computer by an airline official and, remarkably, that name was cleared at the security checkpoint all passengers must pass through before being issued a boarding pass. " http://www.wnd.com/news/article.asp?ARTICLE_ID=37167 Seems like a very general RISK. Some Turing machines just don't halt if they don't find the right name.
Are you familiar with the MS Java Virtual Machine (MSJVM) issue? After September 30th 2004, Microsoft will no longer be able to support this technology. As a result, customers who have the MSJVM installed after this date will be vulnerable to potential attacks that will attempt to exploit this technology. This problem is compounded by the fact that Microsoft will no longer be able to provide software updates or patches to the MSJVM. This issue is not just a concern for organizations that use Java, but will also impact anyone who has the MSJVM installed. More alarming, many organizations aren't even aware that they have MSJVM installed. [...] Ferdinand John Reinke, Consultant, 3 Tyne Court, Kendall Park, NJ 08824
Sometime in the late Sixties when my wife and I were living on Arbor Road in Menlo Park (not far from SRI), I was standing outside close to my landlord's garage when a lumbering four-engine jet liner passed overhead, possibly a little lower than usual. As it passed overhead, the garage door began to open (it had one of the earlier remote openers). After the plane passed, I went over and closed the door. When I asked about it to other, more knowledgeable people, I was told that the aircraft transponder was the culprit, and the phenomenon was not unknown in the Bay area.
We had a house with a 1970-ish vintage garage door opener. Many of these used frequencies that were "shared" with certain aviation uses. Whenever our house was in the approach path to Boston/Logan the door would get triggered easily two to three times a day. When the jets were not being approach-routed over us, it rarely happened — only once that I remember. I simply disabled the remote receiver. Using a single frequency with no keying as a trigger is like using a one-pin lock, or a 1 character password. I don't think that needs any further explanation in the RISKs forum.
Cases of garage doors opening uncommanded through radio-frequency interference are not urban legends, although I don't know specifically about Sputnik. In 1981, I briefly owned a house on Arlington Avenue in Kensington, CA, with an automatic door. I slept often in the room over the garage. When there was a storm in the Bay Area, SFO sometimes used Rwy 19 for landings, instead of the usual 27L/R. The initial approach was radar vectors, and many aircraft used to fly over the Berkeley Hills. I recall that a number of times when aircraft flew over in the early morning, I heard the garage door open. (It piqued both my curiosity and my sense of security, so I remember going to some effort to figure out possible correlations. The aircraft were the only one that I recall. Police radios could have been another - the police station was just up the road and cars used Arlington Avenue all the time. But I recall ruling that out.) That was the only time of which I am aware at which the door opened uncommanded. I don't know when the garage door was installed. The house was some 20-30 years old then, as I recall. I didn't know much about avionics at the time, so I didn't confirm it through technical details. I seem to recall mentioning something about this in Risks at some point. An urban legend with which I am directly familiar concerns mobile phones on gas station forecourts igniting fuel fires. I wrote about it in "An Example of Everyday Technical Risk Analysis". I analysed the principles on which at least one authority seemed to base its regulatory stance, and pointed out that they were very different from a technical risk analysis. For example, the UK regulators based their official position on the fact that mobile phones are RF devices, and there were regulations governing use of RF devices in the presence of flammable substance, although a correspondent at HSE suggested that the possibility of external short circuits, caused say when someone drops a phone while using it, would be a natural concern (I pointed out that this was precluded by the physical design of phones that I had looked at). There is a postscript. My sister reported to me in 2002 that local gas stations put up notices saying that due to then-recent incidents of phone use setting off fires, mobile phone use was "not permitted". She asked the station attendant, and got no precise information. I inquired at the UK Health and Safety Executive, and Simon Brown told me that the more recent reports had been investigated and HSE had concluded that there was no substance to them. Then, end of 2003, there were reports of "exploding" mobile phones. The New Scientist was interested (although I do not know what if anything they published). Nokia had issued a statement about it, in which they said that some third-party replacement batteries had been shown to be defective. I saw a German public television program about it. It interviewed a man to whom it had happened (as his car was passing under the mail Amsterdam-Köln train line at Dinslaken), showed pictures of his phone, showed his hospital admittance record (his arm/hand was mildly burnt), interviewed labs who had investigated such incidents, and showed lab technicians provoking such an explosion. Pretty substantial stuff, no legend. It can happen. Apparently, some third-party replacement battery providers do not have adequate quality control and the short circuit protection mechanisms on the batteries they sell may be as ineffective as the batteries are defective. A battery which internally short-circuits can explode in exactly this way. The program explicitly recommended not using inexpensive batteries from manufacturers/suppliers that were not well-known (I recall it stopped short of advising people only to use original equipment, although some interviewees recommended that.) Of course, this may happen irrespective of whether the phone is in use, or even of whether it is switched on, although I imagine both situations raise the chances that a defective battery will internally short-circuit. So it may well be that there are now good grounds for the adage "don't use your phone on gas station forecourts", but based on the possibility of internal shorts, rather than on their status as RF devices, or on the possibility of external shorts. And better to keep it away from the fumes altogether; not in your pocket or handbag, but in the car with the windows shut. If you have a non-original battery, that is. A colleague pointed out that car batteries are in principle susceptible to the same process, and there are plenty of inexpensive car batteries around, but no one is recommending or requiring that drivers remove or disconnect their car batteries before driving on to a forecourt. Of course, if they did, they couldn't...... Peter B. Ladkin, Professor of Computer Networks and Distributed Systems, Faculty of Technology, University of Bielefeld, 33594 Bielefeld, Germany
I flat-out don't believe the sputnik connection — the signal strength from orbit would have been extremely low. I haven't been able to find hard numbers, but here are some back of the (SMTP?) envelope calculations. Sputnik's perigee was 215 km (sources given below). Assume that a garage door opener's range is 21.5 m; if the satellite has comparable transmission efficiency and power and an (assumed) inverse square signal drop-off, we're dealing with a 10^-8 difference in power. Of course, Sputnik's transmitter was more powerful. I haven't been able to find any data on that, but we can bound it. Sputnik massed 83 kg. Assume that its entire mass was batteries — clearly, that's an overestimate — and assume that a vintage 1957 garage door transmitter had 83 grams of battery (probably too low). That gives a 10^3 improvement in maximum transmitter power. We can be very generous and assume a 10^2 factor for better batteries, better transmitters, etc., but we're still left with a signal strength deficit of 10^3. Sure, Sputnik had better antennas than the garage door opener, but the receiving antennas are constant. I don't see how this adds up. I should add that battery weight and power capacity was a major concern for the designers; furthermore, the antennas were omnidirectional. I may be off-base here, and I'll let people with more knowledge of radio calculate further — but to me, this just doesn't add up. Sources: http://www.hq.nasa.gov/office/pao/History/sputnik/14.html http://www.hq.nasa.gov/office/pao/History/sputnik/russ3.html http://nssdc.gsfc.nasa.gov/database/MasterCatalog?sc=1957-001B http://nssdc.gsfc.nasa.gov/nmc/tmp/1957-001B-traj.html Steve Bellovin, http://www.research.att.com/~smb
I have had a couple of experiences with radio car remotes and have also
recently been doing some research with older style IR remotes...
Firstly, the radio remotes... on a recent business trip i got a call from my
wife in which she described a situation when she got locked out of her car
as the radio remote had stopped working. she could unlock the door with the
physical key, but the remote had also disabled the ignition system so she
could not start the car. she was at a shopping centre, it was early evening,
getting dark, and she had 4 children (not all mine, i should point out! :)
she had just picked up from school and was desperate to get home... when she
called the garage they said it would take two hours to get out to
her. clearly this was unacceptable in the circumstances, so they came up
with another solution... the solution was to tell her the procedure for
resetting the key. having reset the key, she then followed another procedure
to resychronise the car. she did this and it all worked fine. when she
described the procedure to me, it was clear that the process was completely
insecure as it did not require physical access to the car (i.e. no ignition
key or door key sequence was required). as it happened, a few days later, a
friend was giving me a lift to the railway station and on the way he had to
drop off a rental car. as we left it on the forecourt (it was late and the
place was closed), i noticed he was using an identical remote to the one for
my wife's car. i had mine with me so we decided to experiment... and yes,
you are probably way ahead of me here... after performing the sequence, a
dozen or so cars on the forecourt happily chunked their locks open and
flashed their indicators to show that they had been reset! it would appear
that sending a 'base' code from a freshly reset key caused the receivers on
the cars to also reset and synchronise to my key. i didn't try starting any
of them, as ThatWouldBeBad(tm), but being able to open the doors is risky
enough.
This caused me to wonder just how simple those codes were, and how hard they
would be to brute force. not being an electronics/radio whizz, i was
slightly stumped on how to intercept and analyse the signals, so i decided
to first have a go at something simpler, for which such tools already
existed, and which i suspect uses similar underlying protocols - i.e. infra
red. the tool i used was LIRC (http://www.lirc.org/), which includes a nice
graphical utility to show you the 'shape' of the signal. zapping it with my
garage door opener showed that they were using an 8 bit code (plus stop bits
etc.), and the particular code for my garage door was 0xE3. lirc also has a
learn facility, which produces config files in human readable form. the
config for my learned remote looked like this:
begin codes
E3 0x00000000000000e3
it was then a simple task to write a script which spat out the other 255
possible codes:
00 0x0000000000000000
01 0x0000000000000001
02 0x0000000000000002
etc.
and another simple script to send every possible code. running the script
successfully popped the garage door not only when it hit the expected 'e3'
code, but also on another one (apparently the garage operators had installed
a second parallel system as they could no longer get spare remotes for the
old one). total time to try every code was under a minute.
i have since used the same technique to discover 'hidden' menus on TVs
(particularly useful in hotels with pay per view :), and suspect that there
are lots of other similar applications out there waiting to be discovered...
the risk here is that because the code is 'invisible' there is a tendency to
make it simple. i have seen the same mistake in network connected security
devices such as proximity card readers for door controls - the card itself
is secure, but the command that ultimately gets sent over the wire to the
locking mechanism is a simple ascii string, such as "O" for open.
btw, if anyone has any ideas how i could convert the radio remote
signals to something i could analyse/replicate, please get in touch... i
have scanners/transceivers etc., but am completely clueless when it
comes to non digital stuff... :P
Adam Laurie, A.L. Digital Ltd., The Stores, 2 Bath Road, London W4 1LT UK
+44 (20) 8742 0755 http://www.thebunker.net http://www.aldigital.co.uk
Please report problems with the web pages to the maintainer