As an enormous operational improvement, the 1,790 slot machines in Las Vegas's Treasure Island Casino can now be reprogrammed in about 20 seconds from the back-office computer. Previously this was an expensive manual operation that required replacing the chip and the glass display in each machine. Now it is even possible to have different displays for different customers, e.g., changing between "older players and regulars" during the day and a different crowd at night ("younger tourists and people with bigger budgets". (Slot machines generate more than $7B revenue annually in Nevada.) Casinos are also experimenting with chips having digital tags that can be used to profile bettors, and wireless devices that would enable players to gamble while gamboling (e.g., in swimming pools!). [Source: Article by Matt Richtel, Prefer Oranges to Cherries? Done! *The New York Times*, 12 Apr 2006, C1,C4; PGN-ed] There are various risks of interest to RISKS. Regulators are concerned that machines might be "invaded by outsiders", while bettors are concerned that casinos could be intentionally manipulating the odds — for example, giving preferential treatment to high rollers. Internal and external manipulation are clearly potential issues, which of course could be exacerbated by compromisible wireless security. By Nevada law, odds cannot be manipulated while someone is playing, although with four-minute timeouts before and afterward, machines may be reprogrammed on the fly. If it were still April Fools' Day, I might suggest that the slot machines could be reprogrammable for use as voting machines on election day. That way you could have instant payoff if you vote the right way.
Scott Cooper, a computer forensics expert, discovered that a "1" digit had been deleted from a 20-page digital contract in Microsoft Word. His work discovered when the document had been changed and by whom, and resulted in his client receiving the originally contracted 15% share instead of the altered 5% share in his sold company, that is $96M instead of $32M. [Source: Eric A. Taub, *The New York Times*, 5 Apr 2006; PGN-ed] http://www.nytimes.com/2006/04/05/technology/techspecial4/05forensic.html
A Malaysian man said he nearly fainted when he received a $218 trillion phone bill and was ordered to pay up within 10 days or face prosecution. Yahaya Wahab said he disconnected his late father's phone line in January after he died and settled the 84 ringgit ($23) bill, the *New Straits Times* reported. But Telekom Malaysia later sent him a 806,400,000,000,000.01 ringgit ($218 trillion) bill for recent telephone calls ... [more]. [Source: Associated Press, 10 Apr 2006] An interesting one this. Unless this got misprinted somewhere, they must have gone to 64-bit arithmetic to issue bills this big. If they have implemented it as fixed point arithmetic and sucked up about 7 bits for the fraction, that would leave about 56 bits in signed arithmetic to play with which according to my trusty Linux version of bc would allow them to issue a bill up to:- 72,057,594,037,927,936 ringgits. or around $2 quadrillion. Of course they could have gone to arbitrary precision arithmetic in the hope of making a fast googleplex or two. The guy is actually lucky because at least its obviously stupid. It could have equally well been an erroneous number which was vaguely reasonable but expensive and because the computer says it, it must as we all know, be right.
In August 2005, the computer systems used by US Customs failed for about five hours (RISKS-24.02). Documents obtained through a freedom of information request by *WiReD* actually point to a virus being the culprit. The main issue being that a security patch was not deployed (on purpose), but once the virus threat was found, the patch was pushed out to the systems. One sentence in the story  jumped out at me, though: > Publicly, officials initially attributed the failure to a virus, but later > reversed themselves and claimed the incident was a routine system failure. I'm curious to know why "system failure" is considered "routine". While it is prudent to plan for things breaking (redundancy, backups, etc.), and it will inevitably happen in many cases (especially in physical systems), should it ever be considered "routine"?  http://www.wired.com/news/technology/0,70642-0.html
A blunder by New South Wales police has led to a database of e-mail passwords being available on the Internet for as many as 800 people, including those of the anti-terrorism chief and hundreds of journalists. The database appears to have been taken offline within the past month, but is still accessible [e.g., mirrored elsewhere] through Google. [Source: *Sydney Morning Herald*, 5 Apr 2005; PGN-ed] http://www.smh.com.au/news/technology/police-secret-password-blunder/2006/04/05/1143916566038.html It is not clear why a police server would hold passwords of police and journalists simply so they can receive police news releases. And if it does hold passwords, are they the same passwords as the people use to access their own e-mail accounts. (Human nature being what it is, some surely do.) Mike Martin, Sydney, email@example.com
A swarm of D-Link products prod my NTP server despite the fact that they have never gotten an answer from it. I have spent nearly half a year trying to get D-Link to act responsibly and cover my costs but so far to no avail. You can read my side of the story here: http://people.freebsd.org/~phk/dlink/ A feature of modern fast-cycle product development and manufacturing is that a million defective products can be spread all over the market before anybody can get a chance to point out the defects. In this case, the failure is relatively benign, and if D-Link covers the expenses it has cost me, no serious harm has come of it. But considering the lousy quality of software in these low-end devices, it is a safe bet that at least one or two of these products can be subverted as agents for a DoS attack. In fact, only a few years ago, the NTP client component of NetGear devices did act as a DoS attack on University of Wisconsin, as some of you probably remember: http://www.cs.wisc.edu/~plonka/netgear-sntp/ If risk to life and limb is involved, product recalls seems to happen automatically because the manufacturer fears litigation. The auto industry, Intels P5 divide instruction, hot and exploding lithium batteries, hot or flaming switchmode power supplies. The list goes on and on. But unless a legal risk of significant magnitude is present, the vendor, like in this case D-Link, will not even reply to the complaint. Here in Denmark buildings in which many people may be present, sports arenas, theaters and similar, must meet a higher standard in the building code than a regular house. To my na´ve mind, it would make a lot of sense if there were a legal requirement for a higher standard of product review and testing for high volume products in general, and legal liability should scale with at least log(number_of_units_sold). Poul-Henning Kamp phk@FreeBSD.ORG FreeBSD committer BSD since 4.3-tahoe TCP/IP since RFC 956 UNIX since Zilog Zeus 3.20
Hmmm, http://www.havenco.com/: "The Principality of Sealand is a former World War II anti-aircraft military fortress in the North Sea. Only authorized persons directly involved in the HavenCo project are permitted to land on the island. The Sealand Government is ideal for Web business, as there are no direct reporting or registration requirements." "Tamper-resistant computing hardware, designed to protect customer transactions from all possible attackers, including HavenCo and its staff ... unmatched security, including 12" thick concrete walls, 24x7 armed security, and miles of empty sea between you and any threat." Dan says: Probably hard to get spare parts to there during a storm though. [PGN wonders whether there is remote access for maintenance purposes?]
The Greek newspaper *Eleftherotypia* in an article on April 5th 2006 , describes an interesting incident where classified Greek military documents became available on the Internet. According to the article, an unnamed individual found on the Internet a number of military documents containing names of military units, details of mobilization procedures, and names and phone numbers of military officers. He notified the special forces chief of staff, and apparently thereafter all units that had active Internet connections were instructed to disconnect their machines from the network. Yet the individual could still access the files for hours, until he shut down his Internet connection. Military sources explained that the incident occurred when an armed forces technician, while fixing a military unit's computer, copied the files to his laptop in order to burn them to a CD for backup purposes. He then forgot to remove them from his laptop's hard disk, and the files became exposed when he connected his laptop to the Internet through a private non-firewalled connection. The article's terminology doesn't clarify whether the files were shared on the Internet through Windows file shares or through a peer-to-peer file sharing program. I would classify this story as a plain inept security management (what was a private laptop doing in an IT installation with classified documents?) were there not for the fact that the technician could conceivably be trying to do his job battling against other security measures. I can well imagine hat the damaged computer was lacking a CD-ROM burner and a network connection as a (half-baked) security precaution.  http://www.enet.gr/online/online_text/c=110,id=20584664 (in Greek) Diomidis Spinellis - http://www.spinellis.gr/
It's interesting that at the same time I was reading the recent postings about Excel's non-obvious behaviour, I ran into an unexpected Internet Explorer behaviour when copy/pasting. I was visiting a Web page that has text only. It provides a list of on-line or webcast courses that one might be interested in taking. I needed to make a list of the courses I had taken. Given that I had taken most of the courses, I highlighted the whole page and copy/pasted it into an Outlook e-mail I was composing, figuring all I needed to do was to delete the entries for the courses I had not taken. I was quite surprised to see that more text was pasted than I thought I had copied. Some of the text was just repetition of what was already there. I blamed that on the copy process picking up both link destinations (HTML href) as well as the text itself. However, I also noticed that the set of courses was much longer than what I could see on the page. I quickly ran a "view source" on the page to see that the list is indeed much longer than what is visible, with some entries marked not to be displayed: <tr height=0 style='display:none'> So, IE actually copies all the text (presumably because it wants to be able to copy and paste the HTML) and since I pasted into a text-only document, it converted the copied HTML to text with the result that I am not getting what I was seeing on the Web page. A non-intuitive result. Presumably, if I had pasted into a location that was not text-only, I would have ended up with the HTML... I wonder how many sites use this technique to hide some critical information temporarily...
PGN: "The new supposedly self-correcting software had passed all of its tests on the previous Sunday, but evidently the testing was incomplete. " What would _complete_ testing look like? [Martyn, Many thanks for your good sense of humo(u)r. Knowing that testing is NEVER complete in the larger sense, this was clearly a cynical comment on my part, leaving the reader to ponder whether * the test requirements were incomplete (undoubtedly) * the testing against those requirements was incomplete (most likely) * the testing methodology was inherently incomplete (certainly) * and so on. PGN]
Rob Slade complains that the word "rootkit" is being misused to describe cloaking software. I believe that that usage is, in fact, historically correct, as counter-intuitive as that may be. Certainly, it had that meaning 5 years ago; see CERT Advisory CA-2001-05 (http://www.cert.org/advisories/CA-2001-05.html). Wikipedia's description of the origin of the word agrees, but that's a very large can of worms I don't feel like opening now... Asking Google 'define rootkit' yields both meanings, as does the Jargon File. But the last word may be in an article on a Symantec effort to standardize the definition (http://www.computerpartner.nl/article.php?news=int&id=2353): But while efforts like the one Symantec is proposing may help professionals in the field, they will do nothing to alter popular usage, said Alan Paller, director of research with the SANS Institute, a training organization for computer security professionals. "I don't think you can stop the public and the marketing people from using words any way they choose," he said. "So even if there were a standard definition of a rootkit, it wouldn't change the use of the term." Steven M. Bellovin, http://www.cs.columbia.edu/~smb [And so it goes with many other terms: * "Virus" is used generically somewhat like "Kleenex" and "Xerox". * "Intrusion detection" typically applies to insiders and network denials of service that require no intrusion. * ...
An online poll asking Washingtonians to pick their favorite design for the state's quarter coin was suspended, after the balloting was hijacked by computer programs whose automated scripts pushed the tally past 1 million votes over the weekend. [Source: Associated Press item, seen in *The Seattle Times*, 12 Apr 2006; PGN-ed] http://seattletimes.nwsource.com/html/localnews/2002923164_webquarter10.html Peter H Gregory, Concur Technologies http://www.concur.com 1-425-702-8808
An attempt to hold a campus election for the student council at the University of Wisconsin failed *again* due to "significant software errors", according to the University's Division of Information Technology (DoIT) group. According to their news release, "DoIT detected a disparity between the number of student votes cast and the number of votes confirmed in the online election database." No root cause was indicated in a DoIT news release and plans are being made now to run a paper-based election. While the problem-struck online election system will "not be used again," there exists concern that the next attempt will suffer low turnout because of these computer snafus. Also, I noticed the local newspaper (the *Wisconsin State Journal*) did not offer an article on this event compared to the first time it occurred the previous week. Given that this newspaper is bored with this matter, voters can't be far behind. The risks? Loss of respect for computer-based voting systems, reduced voter turnout due to these repeated problems, and continued delays in electing the next student council. News from the University of Wisconsin's Division of Information Technology: "DoIT Information on ASM Election Issues" <http://www.doit.wisc.edu/news/story.asp?filename=649>
Dallman Ross (RISKS-24.23) wrote about the possibility of "Joe-jobbing" someone via the email-to-fax services that only authenticate the e-mail "from" address when sending (expensive) faxes. The risks /appear to be/ mitigated such that real financial damage to a target is impractical, but the devil is in the details as I've just confirmed in examination of a large fax/voicemail service: * This service (and JFax as well) once offered concerned customers (me) the option to place a text password inline at the top of the email body, eg: <password="SendMyFax007">. However, I noticed the password string sometimes leaked into the sent message, and its absence didn't always prevent a message going out. This "feature" doesn't seem to be publicly documented and was never user- configurable. I don't know if it's still available. * The service under study this morning seems to update its authentications after a huge delay, if at all. I removed all references to an account's formerly authorized email address via the web page at 8:14am and replaced it with another. At 9:17am the service is still sending faxes received from the deleted e-mail address. So, even removing a compromised address doesn't stop the attack immediately. Inexplicably, it's referencing a "free trial account" now (the account was started as a free trial years ago). But it's charging the faxes against a real account, and logging them there. * The services top-up a debit balance held at the service, then run it down before charging the credit card again. If you keep a low refill amount, this would throttle an attack, but the victim remains dependent on the company to "do the right thing" to reimburse. * There is no way to stop faxes going out, and no way to remove stored credit card data or to stop the auto-charging of same. Attempts to erase credit card details yield a "you have entered an invalid credit card number" error. The service's contract requires that it be allowed to store credit cards and auto-charge both fixed monthly fees and per-use fees. * The company cannot be easily reached by telephone, even in an emergency. * The service allows account holders to disable notification of sent faxes. Presumably large account holders (those topping up with $100 or $250 per occurrence) thus wouldn't learn about an attack quickly. These accounts would presumably be the most in-demand. * The service allows broadcast faxing on approved accounts, the fax equivalent of a spam relay. I discussed these risks in 2002 with an architect of JFax, who is also a principal at another fax service. His (anonymized) comments below shed some light on their reasoning. He, and JFax before, considered this design necessary and reasonable given the limitations of both technology and customers. He's troublingly confident about the utility of "tracing an email back to where it came from" as a means of solving the problem. "Yes, we've been through this one about a thousand times in the past. When we started (the service) back in 1996, we used to make the sender place their customer ID and password in the subject line of the email. We lost a lot of business because most folks could never figure out how to send a fax. We do send a confirmation to your email address every time a fax is sent on your behalf, so if someone is scamming your account, you should know fairly quickly. Please inform us immediately and we'll credit your account and trace the mail trail back to find out where the email came from. This is a small risk that we have to face in order to do business in our market. Fortunately it hasn't been too big a problem (stolen credit cards seems to be a much more real issue for us to deal with). In my dealings with J2 (JFax)... I learned that they really hadn't had any issues with this type of issue either. We'll keep our eyes open though."
> I suspect that's what happened in this case, and it's a very good reason to > use a real credit card instead of a debit card. When you use a credit card, the bank takes a cut of the transaction which mostly goes straight to their bottom line. When you use s debit card, their cut is much smaller. So it is in the financial interests of the bank if things happen to be arranged so that debit card transactions are risky, so that people continue to give (valid) advice such as the above. After all, its the customer's whether to use a credit card or a debit card, and it doesn't cost the *customer* anything to use a credit card. The bank's gain is the merchant's loss: but the merchant can't afford not to accept credit cards. I'm not suggesting a great conspiracy on the bank's part: just a slight disinclination to fix issues (such as the above) which are financially beneficial to the bank. In other words: a definite conflict of interest! firstname.lastname@example.org http://www.cse.dmu.ac.uk/~mward/
What Eric Ferguson has completely forgotten about is these huge looming things we call mountains out here in the mid western US. They're pretty solid, and descending into, or failing to ascend over, one of these is most always fatal. I would completely refuse to be on an airplane with such an unsafe system in place. If it were to falsely believe there was a depressurization event while climbing out of say, Missoula, MT here, you'd certainly die. Lots of mountains to crash into. A better solution would be some clearer warning signs as well as better training. It might not be a bad idea to have some form of mandatory hypoxia training though I have no idea how that could be done. ANY system that impedes the pilots ability to control the airplane significantly for the sake of what the system designer thinks to be 'safety' will quite likely be far less safe than the original failure mode. Humans are most usually far smarter than these systems.
I can attest to the accuracy of the comments made about Time of Useful Consciousness. I have experienced hypoxia first-hand. I trained as a pilot in the (UK) Royal Air Force. It may have changed in the last 25 years, but back then one of the first things we did in training was to sit in a chamber with an instructor to experience: 1) an explosive decompression from 12000 ft to (I think) 24000 ft 2) hypoxia The idea is that you 'know your enemy' and can react properly if it happens for real. I can tell you that hypoxia is very insidious and the effects are a lot like being very drunk, but it happens very quickly. You are sat in the chamber as a group after the explosive decompression, wearing an oxygen mask. 'One at a time they make you take your mask off and do exercises with pen and paper. You think you're doing fine and the effects haven't started yet, then the instructor puts the mask back on and you look at the complete garbage you have scrawled on the paper. The first third of the page is OK, then it gets worse and worse - first in accuracy, then the handwriting looks like some thing a three year old would do, then there is a line off the edge of the page where you lost it completely (which is when they put your mask back on). You experience it yourself and you get to see 9 other people go through it too. It's a very valuable lesson and one that ought to be taught to all pilots who fly planes that can exceed 12000 amsl. [We have already received over a dozen messages on the Helios situation, from which this and the preceding one have been sampled. PGN]
Please report problems with the web pages to the maintainer