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…
Improper maintenance and inadequate operator training are being blamed for the death of the rider of the Big Thunder Mountain Railroad roller coaster at Disneyland on 5 Sep 2003. The lead car lost its rear-wheel assembly and hit the tunnel roof, causing the following passenger car to go underneath it. The train had just been returned to service after routine maintenance three days earlier. Unusual noises were noted on the first 12 trips of the day, and operators had planned to take the train off line after the 13th ride — which never finished. Subsequent analysis showed that two screws had not been properly tightened. [PGN-ed from cnn.com] http://www.cnn.com/2003/US/West/11/26/disneyland.accident.ap/index.html
"The Burlington Northern and Santa Fe Railway Company (BNSF) has found a novel use for Wi-Fi. It has started using the wireless networking technology to control trains remotely. BNSF locomotives carry freight across the continental US. However, it is using wireless technology to move units around its rail yards.... (Drivers) operate a control panel that mirrors what they'd see if they were sitting in the cab. Their instructions are relayed to each loco via the 'industrial strength' WLAN." Given Wi-Fi's security problems, this novel use of 802.11 certainly gives a new meaning to the word "loco"! [Source: *The Register*, Nov 20 2003] http://www.theregister.co.uk/content/69/34101.html Lars Kongshem, 2220 Taylor St. Suite D, San Francisco, CA 94133 1-415.606.5277 lars.kongshem@kongshem.com + http://www.kongshem.com [Of course, if they were carrying fruit, it would be PLUM LOCO. PGN]
A 15 Sep 2003 lightning strike in Chester County, Pennsylvania, shut down a pair of nuclear reactors 36 miles away at the Peach Bottom Atomic Power Station. Early that morning, lightning struck a PECO power line in East Bradford Township, near West Chester. A circuit breaker failed to isolate the damaged power line, cutting off electricity to more than 100,000 PECO customers and three PECO/Exelon plants — Peach Bottom, Conowingo (Md.) Hydroelectric Station and Muddy Run Pumped Storage Facility in Holtwood. ... At least two complications occurred at Peach Bottom as the reactors were shutting down, according to a preliminary report issued by the NRC. One of four emergency generators failed, and a safety relief valve used to control steam pressure initially stuck open. The NRC has decided to penalize Exelon because the September shutdown was the fourth at Unit 2 in less than a year. The reactor tripped off unexpectedly 21 Dec 2002, when a computer failure caused steam isolation valves to close. On 21 Apr, the valves closed and shut the reactor again because of instrument problems on an air line. The unit also was down from 22 Jul to 1 Aug because of generator problems. [Source: Article by Rebecca J. Ritzel, (Lancaster) *Intelligencer Journal*, date not available, but prior to 19 Nov, anticipating a public meeting of Nuclear Regulatory Commission officials; PGN-ed, but URL no longer valid.] http://www.yorkdispatch.com
[The obvious RISKS — when mandated by law, that a terrorist would be unaware of the need to disable the system; and that no cracker would ever find out the needed signal and shut down a truck for 'fun'; and that no GPS or other systems failure might cause a truck to be shut down incorrectly by law enforcement — are probably obvious to any RISKS reader.] Satellite Security Systems (S3), in cooperation with the California Highway Patrol (CHP) and InterState Oil Company, dramatically demonstrated the first wireless remote shutdown of a fully loaded moving petrochemical tanker truck. From S3's headquarters in San Diego (530 miles away), "satellite communications were used to disable the truck in seconds, proving S3's GlobalGuard and FleetGuard a viable solution to the challenge of controlling rogue hazardous waste vehicles that could pose a threat to homeland security." While the California state government may be voting as early as January on Assembly Bill (AB) 575 (requiring truck disabling devices, global positioning or other "location reporting systems" on hazardous material haulers), the CHP has been tasked with researching various technologies to support these regulatory initiatives. [PGN-ed from *SpaceDaily*, 4 Nov 2003] http://www.spacedaily.com/news/gps-03zn.html
The Associated Press reports: First Microsoft set out to put a computer in every home. Now the software giant hopes to put one in every vehicle, too. "We'd like to have one of our operating systems in every car on Earth," said Dick Brass, the vice-president of Microsoft's automotive business unit. "It's a lofty goal." Cars with the Microsoft software will speak up when it's time for an oil change. They'll warn drivers about wrecks on the road ahead and scout alternative routes. They will pay freeway tolls automatically. The software running their brakes will upgrade itself wirelessly. I can see it now. "A security update is available for your braking system. Press okay to begin installation." Apparently the RISKS are not obvious to everyone.
InformIT, 13 Nov 2003: What Bill Gates Says About Security "You don't need perfect code to avoid security problems. There are things we're doing that are making code closer to perfect, in terms of tools and security audits and things like that. But there are two other techniques: one is called firewalling, and the other is called keeping the software up to date. None of these problems (viruses and worms) happened to people who did either one of those things. If you had your firewall set up the right way * when I say firewall I include scanning E-mail and scanning file transfer — you wouldn't have had a problem. "But did we have the tools that made that easy and automatic and that you could really audit that you had done it? No. Microsoft in particular and the industry in general didn't have it. "The second is just the updating thing. Anybody who kept their software up to date didn't run into any of those problems, because the fixes preceded the exploit. Now the times between when the vulnerability was published and when somebody has exploited it, those have been going down, but in every case at this stage we've had the fix out before the exploit.".... "Actually, all the forms of Unix (as well as Linux) have had more vulnerabilities per line of code. They don't propagate as much because they're not as dense as our system is, so the things that prevent the propagation are particularly important for our world." http://www.informit.com/content/index.asp ?product_id=3D%7BEF1DDC0F-F7BB-47F2-A1AC-00FCB4BCCC39%7D&111603
Commenting on a complaint from a Mr Arthur Purdey about a large gas bill, a spokesman for North Westgas said, "We agree it was rather high for the time of year. It's possible Mr Purdey has been charged for the gas used up during the explosion that destroyed his house." (*The Daily Telegraph*)
Sources: John Leyden, 6 Nov 2003, The Register, http://www.theregister.co.uk/content/7/33831.html Sara Arnott, 5 Nov 2003, http://www.computing.co.uk/News/1147382 Also http://www.femail.co.uk/pages/standard/article.html ?in_article_id=201440&in_page_id=2 Britain's Ministry of Defence squandered 118 million pounds on a computer system that was axed before ever being used. The Defence Stores Management Solution was designed to modernise the MoD's inventories of equipment. (Hardware valued at 12.2 million pounds was salvaged and not included in the 118M figure.) The system had been expected to save 650 million pounds in its first ten years. A report on the collapse of the project (begun in 1999) was released in mid-November. Reasons given included "developments in defence logistics" had rendered the project obsolete, but also indicated management weaknesses at every level: "The MoD had no framework to assess and manage deliverability once projects were launched; the DLO lacked effective change management support and co-ordination; and the BCP suffered from poor financial governance, weak benefits management, poor communications and a failure to establish an effective programme management organisation. ... The review also noted weaknesses in the scrutiny and approvals process. Although BCP projects, including the DSMS, did not meet the Department's requirements in important areas — especially on affordability and benefits management — the projects were not rejected,"
The Supreme Court will hear oral arguments today over whether the federal government should reimburse individuals whose sensitive data was disclosed illegally, even if no harm can be proven. The Privacy Act of 1974 prohibits the government from disclosing private information intentionally, without the individual's consent, and provides for a $1,000 minimum fine if the individual is "adversely affected." In the case, known as Doe v. Chao, the Department of Labor distributed the Social Security number of a coal miner who was appealing for black lung benefits. Since 1969, the Labor Department has used miners' Social Security numbers as their case numbers on documents shared with coal companies, insurance companies and lawyers for all sides. Those documents also were published in court filings that later ended up in legal databases. [Ryan Singel, wired.com, 3 Dec 2003; PGN-ed] http://www.wired.com/news/privacy/0,1848,61439,00.html
According to this BBC article, a hairdresser called Ronnie Campbell received e-mails apparently intended for a Member of Parliament (MP), called Ronnie Campbell. Usual RISKS apply. http://news.bbc.co.uk/1/hi/uk/3267221.stm
FYI — In Tinseltown, bus 'slaves' must go to the end of the line... This gives a whole new meaning to 'PC' language. Please update your cable labels. Los Angeles officials have asked that manufacturers, suppliers, and contractors stop using the terms "master" and "slave" on computer equipment, saying such terms are unacceptable and offensive — after someone had filed a discrimination complaint with LA County's Office of Affirmative Action Compliance. "Based on the cultural diversity and sensitivity of Los Angeles County, this is not an acceptable identification label," Joe Sandoval, division manager of purchasing and contract services, said in a memo sent to County vendors. [PGN-ed from Reuters item] http://www.cnn.com/2003/TECH/ptech/11/26/master.term.reut
I work at a large institution which shall remain nameless. I was recently involved in the evaluation of a product from a company which I will call Company X. The product consists of a Linux server that is sealed in a way that it is impossible to open the box without leaving evidence of tampering. During the course of the normal operation of the product it was installed behind our firewall, and it made copies of sensitive data accessible on our intranet. The loan agreement stipulated that before the box could be returned, our sensitive data had to be deleted from the disks. The box had a built-in "self-destruct" feature that was supposed to accomplish this. Unfortunately, self-destruct was a little too thorough: it not only erased all the data, but it erased the operating system as well, leaving the box unbootable. The problem with this is no doubt immediately obvious to long-time Risks readers: if the box is unbootable then we have no way of verifying that the data is in fact gone. For all we know, self-destruct only erases the boot sector. I raised this objection with representatives of Company X. They suggested that instead of running self-destruct that I use the standard Web-based control interface to erase the data. No, this wouldn't work either, I explained, because again there is no way to verify that the data has actually been erased. For all we know, the only thing that is actually erased is a symlink. They suggested "running a big magnet over the box." Same problem of course. I pointed out that the only way for us to verify that the data was in fact gone would be to examine the disk, which meant one way or another obtaining either root or physical access. They refused to allow this because (they said) they were concerned about us stealing the software. We went back and forth about this literally for months, and I was astonished how hard it was for people to grasp the concept that just because you can't see the data through an HTTP interface doesn't mean it's not there. We finally arrived at the following compromise: Company X would send a representative to our site where the rep would witness the invocation of the self-destruct feature, after which we would open the box, remove the disks, and install them on another machine where they could be examined and/or further wiped. The big day finally arrived, and we ran self-destruct according to the directions. Oddly, there was no indication when the process was finished. We waited five minutes (the prescribed amount of time). At that point the company rep said he wanted to log in to the machine to make sure that it had worked properly. I was shocked, shocked! to discover that in fact self-destruct seemed to have done absolutely nothing. All the files were still there, both our data and those of Company X. At that point the rep typed "rm -rf /". He then proceeded to open the box, take out the disk (turned out there was only one), and give it to me. He then took the box (sans disk) with him and left. This story is fraught with subtle ironies, not least of which is the amount of trouble Company X went through to prevent us from stealing their software, only to leave it with us in a pretty easily recoverable form (to say nothing of the fact that in the interim we had actually purchased the product, so if we wanted to open it up and steal their software nothing would have prevented us from doing so). But the most worrisome aspect of this story is that apparently, among many dozens of customers who evaluated the product, I was the only one to raise any security concerns. Company X's attitude throughout the whole affair was, essentially, "Gee, we never thought of that. No one else ever complained." (And Company X has a reputation for technical savvy.) So I'm off to go through Company X's dumpsters. I expect to be able to retire off what I find there.
A man in East St. Louis got his middle finger stuck in a payphone's coin-return slot. Fortunately, this also meant that when he realized he needed to call 911, there was a payphone conveniently... *at hand*. Eventually the phone was removed and taken, with the victim, to a hospital emergency room where doctors managed to pry them apart. See e.g. <http://www.guardian.co.uk/uslatest/story/0,1282,-3402400,00.html>. [This is known as giving him the finger back. An overzealous knee-jerk response to this episode might be to get rid of the few payphones that remain. PGN]
The text below was send to me by Auke Jilderda. The original e-mail is from the debian mailing list. This is a very readable and interesting case description of an intrusion of a software repository. The Debian Project http://www.debian.org/ Debian Investigation Report press@debian.org December 2nd, 2003 Debian Investigation Report after Server Compromises The Debian administration team and security experts are finally able to pinpoint the method used to break-in into four project machines. However, the person who did this has not yet been uncovered. The package archives were not altered by the intruder. The Debian administration and security teams have checked these archives (security, us, non-us) quite early on in the investigation and re-installation process. That's why the project was able to open up the security archive again and confirm that the stable update (3.0r2) wasn't compromised. [Truncated for RISKS. See <http://www.debian.org/> for the complete report. PGN]
A more accurate subject would be "Risks of updating Internet-insecure computers via the Internet". Rex Black had a computer that was not secure to connect to the Internet. So he connected to the Internet in order to download patches secure the computer; what's wrong with this picture ? Browsing through my router logs, I see approximately 3 hits per minute on port 135 today, i.e. approximately one every 20 seconds. The Blaster patch is 918576 bytes, which would take 3 minutes to download on a v90 dialup. A 33.6 dialup will take approximately 4 minutes. During this timespan he would get 9 to 12 hits on port 135, and be COM-promised (sorry) long before the download was complete. This is prime example of why he needed yet another computer, preferably with a different enough OS that it is not vulnerable at the same moment. I downloaded the Blaster patch from Microsoft's website using Mozilla Firebird on a linux Machine. A Mac running Safari would probably have worked just as well. The patch is small enough to fit on a floppy and could have been moved to the laptop that way. Even if the patch was too large for a floppy, he could've used another computer to check Norton's and/or Microsoft's website, and find out which ports to block to temporarily protect himself whilst downloading the patch. So much for criticism, what solution do I offer? I suggest a "safe mode" Internet connection option be available for these situations. It would require stateful firewalling that would, by default, reject *ANY* packets from IP addresses and ports that the machine had not initiated a connection with. Actually, it wouldn't be a bad idea for the average home user 100% of the time. The only holes normally necessary to allow in the firewall would be for... * NETBEUI for other *LOCAL* machines; *NOT* including machines on the Internet side of the connection * Active-mode mode FTP initiates a second connection back to the client. Stateful firewalling can handle this. Other exceptions would be to allow file-sharing over a VPN. If the user feels *REALLY* confident and adventurous, allow external connections for P2P applications.
I just received an e-mail from quickbooks that my credit card information
was soon to expire and I should immediately call a toll-free number to
renew it. A quick look at the headers made me immediatly suspicious:
Received: from mta1.primary.ddc.dartmail.net ([146.82.220.34])
by **my machine** with esmtp (Exim 3.35 #1 (Debian))
id 1ALnfP-0005xu-00
for <**me**>; Mon, 17 Nov 2003 10:00:03 -0800
X-MID: <Kilauea73191-16006-99081021-3@flonetwork.com>
Date: Mon, 17 Nov 2003 13:01:21 -0500 (EST)
Message-Id: <Kilauea73191-16006-99081021-3@flonetwork.com>
From: QuickBooks Payroll Services
<quickbookspayrollservices@offers.quickbooks.com>
To: **me**
Subject: QuickBooks Critical Notice - Credit Card Expiration Reminder
Note the two relays, and how the From: line doesn't match the Message-Id.
Both flonetwork.com an ddartmail.net are aliases for doubleclick.net which
made me even more suspicious. In the body of the e-mail was a toll-free
number that doesn't appear anywhere on www.quickbooks.com.
It turns out this was legitimate e-mail, but given the number of scams how
many people would really pay attention if it wasn't? And how many spam
filters would have kicked it out due to the problems noted?
I would be greatly interested to learn if this installer referenced by the unknown submitter is the same "Netopsystems FEAD Recomposer" which is used to package Adobe Acrobat Reader version 6. There are a nontrivial number of reports (both on the web and on USENET) of the installer failing to work on many Windows 2000 machines, usually with the same "hourglass then nothing apparently has happened" symptoms, but has also various other reported issues, such as leaking memory and creating CPU loops sufficient to require hardware resets of the computers running the installer, in addition to more trivial assumptions like listing Windows 2000 as supported but only actually supporting Service Pack 2 of Windows 2000. If it is this same installer, this would be extremely interesting for use as an installer for a security clearance application submitter for the US. The FEAD system is published by Netopsystems AG, Berlin, Germany. http://www.netopsystems.com/site/english/fead_e.html [Added in archive: The program in question is reportedly called the Electronic Personnel Security Questionnaire (EPSQ). PGN]
One other response, that I have used to some good effect, is to find the hoax details on an urban legends website (I personally recommend <http://www.snopes.com/>) and reply-to-all with the URL. It may not stop them all (there are none so blind as those who will not see), but it does help some. At least one person wrote me back, thanking me for pointing them to the site.
Matt Davis at Cambridge has posted a response to this:
"Aoccdrnig to a rscheearch at Cmabrigde Uinervtisy, it deosn't
mttaer in waht oredr the ltteers in a wrod are, ..."
See http://www.mrc-cbu.cam.ac.uk/~matt.davis/Cmabrigde/
where Davis says, "I've written this page, to try to explain the science
behind this meme. There are elements of truth in this, but also some things
which scientists studying the psychology of language (psycholinguists) know
to be incorrect. ... To my knowledge, there's no-one in Cambridge UK who is
currently doing research on this topic."
The page also includes samples in many other languages.
I would like to announce the availability of a new and free resource to the software security community, the SC-L e-mail discussion forum. The moderated forum is open to the public. The group's purpose is, "to further the state of the practice of developing secure software, by providing a free and open, objectively moderated, forum for the discussion of issues related to secure coding practices throughout a software development lifecycle process (including architecture, requirements and specifications, design, implementation, deployment, and operations)." (The complete text of the group's charter, including its acceptable and unacceptable usage policies, can be found at http://www.securecoding.org/list/charter.php.) To subscribe to the list, simply connect to http://www.securecoding.org/list and follow the directions on the form. Submissions should be sent (by subscribers only) to sc-l@securecoding.org. Ken van Wyk, Moderator, SC-L mailing list ken@securecoding.org
Please report problems with the web pages to the maintainer