There was a veritable plethora of Euro related gaffes just before the final changeover. A short overview of what has happened: * A housing society in Eindhoven (The Netherlands) has sent out bills for next month's rent in Euro's. But the amount on it is the same as last month's rent, which was in guilders, a 2.2x increase. The society has declared that anyone who paid the incorrect amount will be fully refunded and will get a corrected bill later. * A branch of ING bank in Blerick inadvertently inserted the wrong cassette into an ATM, which began to give out Euro bills instead of Guilders. This was illegal before January 1st, 2002. The bank has traced the bills and all but 10 euro have already been returned. * Rabobank has made an error in it's daily processing of 300,000 automatic transfers. Instead of transferring guilders, the transfers were made in Euro's, again 2.2x what should have been transferred. The bank hopes to have corrected the mistake before 6pm tonight (Due to the Euro changeover, no banking activity will take place in any of the Euro countries on monday). * (Just somewhat related:) Two companies thought they were being really smart by putting Eurobills in Christmas gifts for their employees. They have been ordered by the Dutch central bank to recover all those bills or face charges.
The Euro troubles keep coming in. Even though banks have had four to five years to prepare for the introduction of the Euro, things still go wrong. Yesterday and today over 200 smaller Dutch post offices have had to remain closed because of computer problems relating to the Euro changeover. It is still unclear whether the situation will finally be resolved tomorrow.
About 51,000 customers who withdrew money from their ING Bank account on 1 & 2 Jan 2002 (through an ATM) have had the wrong amount debited from their account. The bank hasn't yet given an explanation for the error other than to suspect that it was related to the high stress their systems were under during the first few days of the new year. The amounts debited from customer accounts was a hundred times what they withdrew from the ATMs. This got some people into trouble when their balance went negative and they could no longer use their bank PIN card to pay with in shops. ING Bank corrected the error yesterday. On a related note, my wife withdrew Euros from an ATM yesterday and the printed receipt came up blank. My guess is that the ink ribbon on the embedded matrix printer ran out. Bank personnel are working like crazy to feed the machines with Euro bills and simply forget to check the printer. If her bank makes a mistake similar to the one ING made, she would have a hard time proving that she didn't withdraw 10000 Euro.
The European Central Bank is working with technology partners on a hush-hush project to embed radio frequency identification tags into the very fibers of euro bank notes by 2005. Intended to foil counterfeiters, the project is developing as Europe prepares for a massive changeover to the euro, and would create an instant mass market for RFID chips, which have long sought profitable application. http://www.eetimes.com/story/OEG20011219S0016 I hardly know where to begin even thinking about the RISKS involved. [Those who are Europeein' may need a Eurologist to detect bogus chips. PGN]
Apparently (from the postings on comp.protocols.time.ntp) some TruTime GPS units suddenly jumped 1024 weeks into future sometime around New Year's Day 2002. [GPS units have jumped 1024 weeks into the past before (R-18.24, R-20.07). Back to the future is a nice twist. PGN]
An empty plane took off by itself and flew 20 miles before crashing in California's rural Napa County. The two-seater Aeronica Champion had a starter system requiring the pilot to get out and hand-crank the engine. [*Wall Street Journal*, 28 Dec 2001]
According to today's Globe, AOL's spam filters rejected e-mail sent by Harvard's admissions department to anxious applicants. The interesting thing is that "AOL officials could not explain" why their servers identified these e-mail messages as spam. No explanation, no responsibility, apparently no indication of anything that Harvard could do to avoid the problem in the future. Just one of those things, like the weather. Despite jokes, USPS "snail mail" is very highly reliable. Those of us who have used e-mail for years are aware that it is much less reliable; for example, Verizon DSL's mail server slowed to a crawl for several months last year, and during that time period less than half of e-mail I sent from another account to test it were actually received. Antispam filters decrease this reliability further. The facile name "e-mail" was helpful in the eighties as a characterization of a form of electronic communication. However, there is a risk that the name may mislead people into assuming that it is comparable in reliability to postal mail. Let us hope that organizations do not begin use e-mail for communications more important than university admissions letters, in the name of "security" (and cost reduction). [The AOL Harvard problem was noted by quite a few RISKS readers. TNX]
> Mind you, that "drivers ignoring signals" is another example of RISKy > behaviour. Perhaps we need a parallel forum: FORUM ON RISKS TO THE PUBLIC FROM THE USE OF HUMANS IN TECHNOLOGY. While research on human safety factors is widespread, comments in this forum often treat human-based systems as the baseline and assume that automation can only create risks. Comments often fail to consider improvements in safety from automation, much less more widely ramified benefits such as improved health resulting from our ability to transfer resources to health care. What would happen in a forum devoted to asking the opposite question? That is, "what are the risks or benefits of introducing human actors into a given system?". At least, considering the question can provide some needed balance. It's a way of considering the RISK of rejecting change. Edward Reid [Not ANOTHER forum! From the very beginning, RISKS has discussed risks due to people as well as risks to people due to technology (which typically are due to people anyway!). There's nothing new there. PGN]
Two top companies have issued new statements acknowledging security flaws in their products: Microsoft (Windows XP) and Oracle (the 9i application server, which the company had insisted was "unbreakable." Resulting from a vulnerability called "buffer overflow," both problems could have allowed network vandals to take over a user's computer from a remote location. Microsoft and Oracle have released software patches to close the security holes, and a Microsoft executive says: "Although we've made significant strides in the quality of the software, the software is still being written by people and it's imperfect. There are mistakes. This is a mistake." (San Jose Mercury News 21 Dec 2001; NewsScan Daily, 21 December 2001) http://www.siliconvalley.com/docs/news/svfront/secur122101.htm
I'm no fan of lawyers or litigation, but it's high time that someone defined "buffer overflow" as being equal to "gross criminal negligence". Unlike many other software problems, this problem has had a known cure since at least PL/I in the 1960's, where it was called an "array bounds exception". In my early programming days, I spent quite a number of unpaid overtime nights debugging "array bounds exceptions" from "core dumps" to avoid the even worse problems which would result from not checking the array bounds. I then spent several years of my life inventing "real-time garbage collection", so that no software -- including embedded systems software -- would ever again have to be without such basic software error checks. During the subsequent 25 years I have seen the incredible havoc wreaked upon the world by "buffer overflows" and their cousins, and continue to be amazed by the complete idiots who run the world's largest software organizations, and who hire the bulk of the computer science Ph.D.'s. These people _know_ better, but they don't care! I asked the CEO of a high-tech company whose products are used by a large fraction of you about this issue and why no one was willing to spend any money or effort to fix these problems, and his response was that "the records of our customer service department show very few complaints about software crashes due to buffer overflows and the like". Of course not, you idiot! The software developers turned off all the checks so they wouldn't be bugged by the customer service department! The C language (invented by Bell Labs -- the people who were supposed to be building products with five 9's of reliability -- 99.999%) then taught two entire generations of programmers to ignore buffer overflows, and nearly every other exceptional condition, as well. A famous paper in the Communications of the ACM found that nearly every Unix command (all written in C) could be made to fail (sometimes in spectacular ways) if given random characters ("line noise") as input. And this after Unix became the de facto standard for workstations and had been in extensive commercial use for at least 10 years. The lauded "Microsoft programming tests" of the 1980's were designed to weed out anyone who was careful enough to check for buffer overflows, because they obviously didn't understand and appreciate the intricacies of the C language. I'm sorry to be politically incorrect, but for the ACM to then laud "C" and its inventors as a major advance in computer science has to rank right up there with Chamberlain's appeasement of Hitler. If I remove a stop sign and someone is killed in a car accident at that intersection, I can be sued and perhaps go to jail for contributing to that accident. If I lock an exit door in a crowded theater or restaurant that subsequently burns, I face lawsuits and jail time. If I remove or disable the fire extinguishers in a public building, I again face lawsuits and jail time. If I remove the shrouding from a gear train or a belt in a factory, I (and my company) face huge OSHA fines and lawsuits. If I remove array bounds checks from my software, I will get a raise and additional stock options due to the improved "performance" and decreased number of calls from customer service. I will also be promoted, so I can then make sure that none of my reports will check array bounds, either. The most basic safeguards found in "professional engineering" are cavalierly and routinely ignored in the software field. Software people would never drive to the office if building engineers and automotive engineers were as cavalier about buildings and autos as the software "engineer" is about his software. I have been told that one of the reasons for the longevity of the Roman bridges is that their designers had to stand under them when they were first used. It may be time to put a similar discipline into the software field. If buffer overflows are ever controlled, it won't be due to mere crashes, but due to their making systems vulnerable to hackers. Software crashes due to mere incompetence apparently don't raise any eyebrows, because no one wants to fault the incompetent programmer (and his incompetent boss). So we have to conjure up "bad guys" as "boogie men" in (hopefully) far-distant lands who "hack our systems", rather than noticing that in pointing one finger at the hacker, we still have three fingers pointed at ourselves. I know that it is my fate to be killed in a (real) crash due to a buffer overflow software bug. I feel like some of the NASA engineers before the Challenger disaster. I'm tired of being right. Let's stop the madness and fix the problem -- it's far worse, and caused far more damage than any Y2K bug, and yet the solution is far easier. Cassandra, aka Henry Baker <email@example.com>
Henry, Please remember that an expressive programming language that prevents you from doing bad things would with very high probability be misused even by very good programmers and especially by programmers who eschew discipline; and use of a badly designed programming language can result in excellent programs if done wisely and carefully. Besides, buffer overflows are just one symptom. There are still lots of lessons to be learned from an historical examination of Fortran, Pascal, Euclid, Ada, PL/I, C, C++, Java, etc. Perhaps in defense of Ken Thompson and Dennis Ritchie, C (and Unix, for that matter) was created not for masses of incompetent programmers, but for Ken and Dennis and a few immediate colleagues. That it is being used by so many people is not the fault of Ken and Dennis. So, as usual in RISKS cases, blame needs to be much more widely distributed than it first appears. And pursuing Henry's name the blame game, whom should we blame for Microsoft systems used unwisely in life- and mission-critical applications? OS developers? Application programmers? Programming language developers? Users? The U.S. Navy? Remember the unchecked divide-by-zero in an application that left the U.S.S. Yorktown missile cruiser dead in the water for 2.75 hours (RISKS-19.88 to 94). The shrinkwrap might disclaim liability for critical uses, but that does not stop fools from rushing in. Nothing in the foregoing to the contrary notwithstanding, it would be very helpful if designers of modern programming languages, operating systems, and application software would more judiciously observe the principles that we have known and loved lo these many years (and that some of us have even practiced!). Take a look at my most recent report, on principles and their potential misapplication, for DARPA's Composable High-Assurance Trustworthy Systems (CHATS) program, now on my Web site: http://www.csl.sri.com/neumann/chats2.html
We're all aware that many companies have buried their heads in the sand on the security issues involved with moving to high-tech solutions in the name of convenience, among other things. When we're talking about on-line sales, educational applications, news media, and the like, the repercussions of such are usually not critical to human life, and therefore the trade-off is made. However, I've just encountered something that is, well, disconcerting at best. Earlier today as I sat unattended in an examination room for a half hour waiting on the doctor to show up, I carefully studied the new computer systems they had installed in each patient room. Computers that access ALL patient records on a centralized server located elsewhere in the building, all hooked up using a Windows 2000 domain on an ethernet based LAN. Computers that contained accessible CD and floppy drives and that could be rebooted at the will of the patient. Computers hooked up to a hot LAN jack (oh for my trusty laptop instead of that Time magazine...) Big mistake #1 - the classic insider problem. Once the doctor arrived and we got comfy, I started asking him about the computer system. (I just can't keep my big mouth shut.) Oh he was SO proud of their new fangled system. So I asked the obvious question - what would prevent me from accessing someone else's records while I sat here unattended for a half hour waiting for you to show up? With a big grin on his face, he said "Lots of people ask that question. We have security here; let me show you." Big mistake #2 - social engineering. Then he proceeded to show me that the system is locked until a password is entered. Of course, he said, if someone stole the password, then they could get in, but passwords are changed every 3 months. And, he continued, that's as secure as you can get unless you use retinal scans. (HUH?) I know all about this stuff, for you see "my dear", I have a masters degree in medical information technology, and I'm in charge of the computer systems at XXXX hospital. OK. Time to fess up. Doc, I do this for a living, and you've got a real problem here. 1, Have you thought about the fact that you have a machine physically in this room that anyone could reboot and install trojan software on? A: Well that's an issue. 2. Have you thought about the fact that there's a live network connection in this room and anyone could plug in and have instant access to your network? A: You can really do that??? There's a guy that brings his laptop in here all the time. 3. I assume you are using NTFS (yes), have you locked down the file system and set the security policies properly? You do understand that it is wide open out of the box. A: I don't know what was done when the computers were set up. 4. Have you thought beyond just the patient privacy issue to the issue of unauthorized modification of patient records? What are you doing to prevent this? What could someone do if they modified someone else's records? Make them very ill? Possibly kill them? A: That's a big concern. (well, duh?) Then there was a big discussion about access to their prescription fax system that could allow people to illegally obtain medication. I didn't bother to ask whether or not they were in any way connected to the Internet. They either have that or modems to fax out the prescriptions. At least he said he'd talk to his vendor to see how they have addressed the other issues. Perhaps they have addressed some of these things and the doctor I was chatting with simply didn't know. I'm not trying to come down on these doctors as I'm sure they have very good intentions. I personally think having the medical records on-line is a good idea in the long term as it can speed access to records and enable remote and collaborative diagnoses, potentially saving lives. But I'm not convinced that today we can properly secure these systems to protect the lives they are intended to help save. (Other opinions are welcome.) And with the state of medical malpractice lawsuits and insurance, what could a breach in a computer system that affects patient health do to the medical industry if it becomes reliant on computer systems for storage/retrieval of all patient records? A couple of things. First, I'm not up on the state of cyber security in medical applications. I was wondering if anyone out there is up on these things or if anyone else has seen stuff like this. Second, if a breach in the computer system was made and someone was mistreated as a result, who could be held liable? The doctors for sure. What about the vendor that sold and/or set up the system for them? Does "due diligence" enter in? If so, what is "due diligence" in cyber security for medical applications? Third, does anyone know if the use of computers for these purposes in a physician's office changes the cost of malpractice insurance? Is this just too new and not yet addressed by the insurance industry? Is there any set of criteria for "certification" of the system for medical insurance purposes, possibly similar to that required by the FDIC for the banking industry? If so, is the criteria really of any value?? [This is reproduced here from an internal e-mail group, with Laura's permission. A subsequent response noted the relative benignness of past incidents and the lack of vendor interest in good security -- grounds that we have been over many times here. However, Laura seemed hopeful that the possibility of unauthorized modification of patient data by anyone at all might stimulate some greater concerns. PGN]
Please report problems with the web pages to the maintainer