Slashdot Mirror

A former Boeing computer expert said yesterday that the company ordered him to play down his discovery of a software flaw in a critical control unit that could have triggered last May's fatal crash of a Lauda Air Boeing 767. Darrell Smith, a computer software engineer employed as a troubleshooter by Boeing in 1989 and 1990, said in an interview with the P-I that he warned the company last year of problems with software that runs the "proximity switch electronics unit" (PSEU) on Boeing's 747 and 767 jetliners.

It is possible to write software with those constraints.

With all due respect, no, it isn't. I recommend the RISKs forum as essential reading for anyone working in technology.

For a problem of the complexity of electronic voting, it would be a lot cheaper to run paper ballots for the next hundred years or so than it would be to write provably correct distributed voting software (and hardware; there's no point verifying the software if you haven't verified the hardware it's running on, network protocols it's using to communicate, etc).

I agree on the paper ballots point, but when trying to understand a complex system, one must see how the system is behaving and not be distracted by how the system should be behaving.

I find it very curious that despite the simplicity of 'paper ballot' voting and the known problems with electronic voting, the system (our democratically elected government) still insists on favoring DRE's over paper ballots. Clearly there is a systemic behavior here we are failing to account for.

Which explains, if I can be forgiven, why I tend to jump hard on anyone who suggests that electronic balloting is good, or is feasible, or can be made feasible, or amounts to anything other than a distraction from the truth.

It's not about cheap, or convenient, or promoting economic concerns, or little-old-ladies fumbling with technology they can't understand. Electronic balloting has the potential to interfere with our ability to self-govern. And for that reason alone it should be beyond consideration.

It interferes with our number one objective: we must retake the cockpit.

There's an excellent summary on Risks.

I assume that the parent was modded "funny" as a piss-take. Maybe it was meant that way, maybe it's conspiratorial ramblings, but the OP's scepticism is not entirely baseless if this British case is anything to go by. (More here and here). For those willing to dismiss analysis of that case as fringe ramblings, note that it was reported across the world and the subject of several documentaries.

The exact same thing happened in Minnesota 12 years ago on the primary Internet link at the time. IIRC, in the Minnesota incident, diversified paths were implemented on seperate fibers. Unfortunately, the seperate fibers were in the same bundle.

• User Friendly
• Cryptome
• RISKS Digest
• Stupid Security
• This Is Broken
• Popular Wireless
• Tribe
• Slashdot main page
• Ask Slashdot
• Worse Than Failure (formerly known as the Daily WTF)
• Fantasyland

Of these entries, RISKS, Cryptome, Slashdot, Ask Slashdot, Worse Than Failure, and the Sidebar WTF section of Worse than Failure are all also subscribed in my RSS feed reader, along with BBC News, the Public Daily Brief and some select search terms in Google News.

You mean like the reputed triggering of a fire suppression system thanks to a cell phone?

As found on comp.risks http://catless.ncl.ac.uk/Risks/21.20.html#subj3

The register's article is still available, seems to be expired elsewhere.
http://www.theregister.co.uk/2001/01/11/mobile_pho ne_brings_down_slovenian/

When I first read the headline, it reminded me of a story that I saw on the RISKS list (and if anyone can find the exact link please do so) In summary (and from memory only) it was:

1/ A security company was contracted to do a pentration test of a bank.
2/ The employees found out, so were being aware of typical social engineering type situations
3/ The security company loaded up some special USB keys that had had key logger and other software on them
4/ 15 to 20 of said keys were scattered around the door of the bank prior to opening hours
5/ With 3 days something like 75% of the keys had phoned home and were reporting that they were connected to computers inside the bank.

After reading this scenario I realised that if I saw a stray USB key I would just plug it in to see what was on it - and I would have fallen for the same trap as the bank employees

Another scenario I heard of (also on RISKS I think) was to go to the front desk of a company, ask to use the bathroom (or toilet for the rest of us), and leave a CD in a prominant location that was clearly labelled with something like "Staff reductions". It wouldn't take very long before that CD was inserted into someones computer at that company.

The first polymorphic computer was built much earlier than
that by RW (later TRW). I do not know when, but UCSB had one
in 1974, when I was a student there.

  Quote from:

http://catless.ncl.ac.uk/Risks/9.80.html#subj8.1

"The conceptual design of this Polymorphic Computer, as they called it, was
attributed to Sy Ramo, who had earlier helped lead Hughes Aircraft and
Ramo-Wooldridge (later called TRW) to fame and fortune. The architecture of
this new machine was an interesting bad idea. The basic idea was to use many
small computers instead of one big one, so that the system could be scaled to
meet various needs simply by adjusting the number of processors. The problem
was that these units were rather loosely coupled and each computer had a
ridiculously small memory -- just 1K words. Each processor could also
sequentially access a 1K buffer. Consequently it was very awkward to program
and had extremely poor performance."

I'm a frequent flyer who would prefer not to fly in any plane thus equipped.

This type of system is a perennial topic on comp.risks & is certainly not a panacea. It is not clear whether the system is any improvement, or whether it merely increases risk; and I don't trust Boeing to decide for us.

How long until the "Blue Screen of Death" (BSOD) has a somewhat more ominous (and literal) meaning?

Obviously, this was caused by the fact that the Yorktown's control software was of a really bad design.

You are mistaken. Safeguards were intentionally disabled.

The truth is that a server app corrupted it's data, a client app tried to use that bad data, and the client app failed to control equipment. Can happen with any OS. Add to this the fact that the ship was a test platform not an operational ship and they were trying to break things.

"Others insist that NT was not the culprit. According to Lieutenant Commander Roderick Fraser, who was the chief engineer on board the ship at the time of the incident, the fault was with certain applications that were developed by CAE Electronics in Leesburg, Va. As Harvey McKelvey, former director of navy programs for CAE, admits, "If you want to put a stick in anybody's eye, it should be in ours." But McKelvey adds that the crash would not have happened if the navy had been using a production version of the CAE software, which he asserts has safeguards to prevent the type of failure that occurred."

http://www.sciam.com/1998/1198issue/1198techbus2.h tml

"McKelvey writes that the failure, "was not the result of any system software or design deficiency but rather a decision to allow the ship to manipulate the software to stimulate [sic] machinery casualties for training purposes and the 'tuning' of propulsion machinery operating parameters. In the usual shipboard installation, this capability is not allowed.""

http://catless.ncl.ac.uk/Risks/20.37.html#subj1

When F16s crossed the equator, the computer would roll the aircraft 180 degrees and fly inverted:

http://catless.ncl.ac.uk/Risks/3.44.html

I've heard of a software glitch causing a crash before, but this is ridiculous.

Not really - read the Risks-Forum Digest, especially the earlier years, and you'll find that software quite often causes physical harm.

The name of it escapes me right now, but I did take a class where we reviewed certain classic software failures. (A good class for me since I'd already read about them :).

If you'd like to read a few, check out:
Therac-25 (Race conditions, software lockouts in lieu of hardware)
London Ambulance Service (Poor software design and design process)
Ariane 5 (Cutbacks on testing procedures, inappropriate software re-use, variable overflows, flight hardware allowed to generate error output)

then there's the Denver airport baggage system, the Mars Climate Orbiter, etc.

In general, you may want to read the Risks Digest, where stuff like this happens every month!

The name of it escapes me right now, but I did take a class where we reviewed certain classic software failures. (A good class for me since I'd already read about them :).

If you'd like to read a few, check out:
Therac-25 (Race conditions, software lockouts in lieu of hardware)
London Ambulance Service (Poor software design and design process)
Ariane 5 (Cutbacks on testing procedures, inappropriate software re-use, variable overflows, flight hardware allowed to generate error output)

then there's the Denver airport baggage system, the Mars Climate Orbiter, etc.

In general, you may want to read the Risks Digest, where stuff like this happens every month!

• The Great Capacitor Scare of 2003
• Leaking Capacitors Muck Up Motherboards
• Illicit Leaky Capacitors Killing Motherboards

It's not a service I want since I consider buying things that I wasn't specifically hunting for to be a very bad thing. Also, dataleaks.

The Mars Rovers turn out not to be bug free either.. Despite 'quality' programming and surely a lot of testing, their software has bugs. See this Risks Digest article. If their interrupt problems had taken out the communications link permananetly or they had not, largely by luck apparently, left tools on board that allowed them to debug and fix the problem on the fly, or they'd made the wrong itsy-bitsy mistake patching code over a 90 million mile data link. the software folks would have been bums, not heros.

The RISKS digest carried this news a few years ago.

It's been long known that;

1. some providers can download arbitrary software to some phones
2. a phone can be running that software while appearing not to be making a call

The potential for abuse is obvious.

I gave up my mobile phone about a month ago now. I read through a full list of the ways in which the British State monitors me. When you read them all at once, it has quite an impact. The simple question I have is this: I am completely innocent. I have commited no crimes and am not suspected of committing any crimes.

SO WHY AM I BEING WATCHED?

What do you mean? It is been in cars and other vehicles (all modern airplanes) for years. We rely on embedded microprocessors and microcontrollers for most of our day, in engine management systems, braking, in car safety, fly-by-wire, etc. etc. etc. And its not just a couple of if-then-elses. There is some serious code out there. And it works. Most of the time.

Have a look at the Risks Digest if you want to find out how far things have gone.

The fake PIN would work against trojan ATMs. I've seen more than one story on the news where fraudsters install a fake, free-standing ATM in a public shopping area (mall). It reads the cards and PINs, and maybe dispenses cash (or some sort of error message). The "service technicians" later remove the machine with all the recorded info. for cloning the cards.

Sources for the above:

Pensioners shortchanged of 'float'

Ariane casting problem (float -> 16 bit int)

Sources for the above:

Pensioners shortchanged of 'float'

Ariane casting problem (float -> 16 bit int)

yeah, laptops could implement this in the keyboard controller. Or even the USB hub could do it.

you have to trust the pc vendors, as they have nothing to gain, and everything to lose, in lawsuits and lost sales. But what if their government comes along and says 'add this back door'. They'd comply.

Case in point: Lotus notes put a back door in export versions of notes:
http://catless.ncl.ac.uk/Risks/19.52.html#subj1

they sent messages with 64 bit encryption (!), but 24 bits of the key was hidden in the message, where the NSA knew to look, or otherwise given to them. You only had 40 bit keys, which upset the swedish government.

Moral: You cant trust closed source apps any more than closed source hardware.

And in Risks Digest on July 20!

Anyone who has to build something that will be used by someone else should be subscribed to the Risks-Forum digest.

It's titled, "Forum On Risks To The Public In Computers And Related Systems", and relates a lot of computer and general engineering related risks. Risks that either wind up killing or seriously injuring people. It's been going since 1985, and is a good read just to open your mind to what might happen.

As so many headlines on Fark read, "What could possibly go wrong?". This should always be the first thought for any engineer when they are tasked to do something.

Indeed, it's been demonstrated that even the suggestion of surveillance is effective to control our actions to some degree. Consider then what effects actual surveillance has.

"IT staff usually enjoy unrivaled access to the deepest details of an organization's structure, and all too often, some submit to the urge to use that knowledge for nefarious purposes.

At least we can count on the police to put a stop to this.

http://catless.ncl.ac.uk/Risks/21.58.html#subj5

[According to the third Detroit Free Press story, a cop who stalked a woman
using his access to police databases was "suspended for a day without pay."
That'll teach 'em! --Declan] [FROM POLITECH]

> Date: Sat, 04 Aug 2001 02:08:36
> From: "Ed Walker"
> Subject: Michigan cops abusing database

> www.governing.com/news had a link to a freep article that may be of
> interest to politechnicals. The first two links are the story, and the
> third is an account of a truly creepy cop stalking someone he met while on
> duty.

> Michigan Newspaper: Police Abuse Database Police throughout Michigan,
> entrusted with the personal and confidential information in a state law
> enforcement database, have used it to stalk women, threaten motorists and
> settle scores. Over the past five years, more than 90 Michigan police
> officers, dispatchers, federal agents and security guards have abused the
> Law Enforcement Information Network, according to a Detroit Free Press
> examination of LEIN records and police reports. More: Detroit Free Press
> http://www.freep.com/news/mich/lein31_20010731.htm
> http://www.freep.com/news/mich/lein1_20010801.htm
> http://www.freep.com/news/mich/amber31_20010731.ht m

Hey man, at least he's not Dan Quayle! Dan Quayle quotes are the best! http://homepages.cs.ncl.ac.uk/chris.holt/home.info rmal/bar/corsair.afdq/quayle.quotes/

From comp.risks:

NASA managers decided on Thursday to skip a launch pad test of the shuttle
    Discovery's redesigned fuel tank because of the risk the test itself could
    damage the tank. The test would have entailed filling the shuttle's fuel
    tank with cryogenic propellants and testing its systems. The fuel tank has
    been the focus of NASA's shuttle safety upgrades since the 2003 Columbia
    accident. [Source: Irene Klotz, NASA to skip shuttle tank test ahead of
    July launch Reuters, 5 May 2006; PGN-ed]

BOEING 737 PROBLEMS REACH FRESH HEIGHTS

Autopilot computer systems on Boeing 737s have been hit by a problem which has caused aircraft to change height without warning. It is believed that full details of the problem have been requested by the investigators into the crash of the British Midland 737 on the M1 motorway in January. One theory is that the crew were misled by cockpit instruments. Risks Digest

"Autopilot computer systems on Boeing 737s have been hit by a problem which has caused aircraft to change height without warning. It is believed that full details of the problem have been requested by the investigators into the crash of the British Midland 737 on the M1 motorway in January. One theory is that the crew were misled by cockpit instruments.

Six incidents have been recorded by British Airways on its aircraft but the company says there has never been any danger because the crews have always checked the autopilot actions against other cockpit instruments.

The problem occurs after a pilot enters a new height to the autopilot. The system displays the instruction, but under certain circumstances the aircraft moves to a different height and the autopilot then displays the new reading.

One senior British Airways captain says the autopilot seems to use instructions entered earlier, even as long ago as the previous flight.

British Airways has called the problem "random memory initiation" and says it is caused by unexpected electromagnetic conditions such as lightning, strong radar signals, or an electrical power surge. Boeing says it has no evidence of any accidents occurring because of the problems.(source: Risks Digest

China Airlines A300 Disaster

China Airlines A300 crashed at Japan's Nagoya airport, killing 264 of 271 people on board. The most likely cause of the crash was not solely the fault of software, but the confused interactions between software and human, in this case between the 26-year old copilot of the plane who was attempting to land the plane and the autopilot of the plane.

Two minutes before the plane was about to land, the autopilot of the plane went into take-off/go-around for reasons the investigation could not determine. In effect, this caused the autopilot to attempt to control the plane in a way that was directly opposite to what the human pilot was attempting to control.

(Source)

Part of this work was done by colleagues of mine at the Institute for Research into Environmental Sustainability part of Newcastle University, UK.

The BBC report on this several month old story is here!

Quick, in 10 seconds, how do you say "Our operative in Munich was tailed, so we switched to our Spanish connection. Either Ahmed or Siddiq, I'm not sure, but he has to know that if the transfer happened less than a month ago to not try to clear the funds."

This from the Risks forum, back in 1991:

http://catless.ncl.ac.uk/Risks/11.71.html#subj2.1

From the article:

"There has been plenty of discussion about SB266 requiring all communication equipment to provide the plaintext to the government on demand. Well, I've decided if they want plaintext, give them plaintext. I've written a program that will convert any file into strings from a context-free grammar. The bits are recovered by parsing. To test it's viability, I created two grammars and a program to do the work."

"The first converts any file into the radio commentary of a baseball game between two teams, The Blogs and the Whappers. Could something as American as baseball be hiding something?..." A very interesting read.

Actually, your steering wheel analogy isn't correct. In the early 90's, then-Swedish automaker SAAB built a prototype car based on a fly-by-wire joystick concept. They found in testing that drivers had greater control with their joystick than they did with a traditional steering wheel. It was also safer in a crash, due to the advantages it offered in airbag placement. The system never went into production as it was determined that it would be far too difficult to convince the general public of these advantages.

possibly this one
http://catless.ncl.ac.uk/Risks/8.77.html#subj6

They do afer all specialize in some pretty high end hardware such as tamperproof encryption modules. If it were any other manufacturer I'm not sure I'd "buy it".

Heh. I know the guys who do the IBM 4758 and PCIXCC cards and they aren't involved with the fingerprint scanner on the notebooks.
IBM is a big company.

Although not IBM specific, here's a few links about the falibility of fingerprint scanners, the last one is tragically funny.

http://www.schneier.com/crypto-gram-0205.html#5
http://catless.ncl.ac.uk/Risks/22.37.html#subj4.1
http://www.schneier.com/crypto-gram-0205.html#5
http://news.bbc.co.uk/2/hi/asia-pacific/4396831.st m

This is predated by Ken Thompson's paper [Turing award lecture, Reflections on Trusting Trust, CACM 27, 8, August 1984] wherein the concept of an invisible virus was proposed -- the actual virus was (to be) buried in the object code of the C compiler for Unix; its object was that IF it were compiling the source code of the login module it would insert a little piece of code that allowed it's creator always to log on (the War Games "backdoor"); IF it were compiling the source code of the C compiler itself it would merely copy itself at the appropriate place. In both cases there was no sign of the virus in the source code nor presumably in the listing generated by the compiler;...
http://catless.ncl.ac.uk/Risks/6.3.html

That comment isn't so funny when you think about it.

Prisons provide cheap work programs to businesses so that they can keep the prisoners busy. Some of these programs involves things like processing credit card orders and doing data entry.

This particular link is from 1991, but it was one of the first that popped up in Google. AFAIK, it still goes on in various prisons.

That may be it, but then again its history of unintended disclosures might scare off a few lawyers.

Sorry. You CAN tap fiber essentially without detection. Plessey came up with the technology over 25 years ago. No splice needed in the cable. Cut back the jacket, attach tap (which "slightly" bends the fiber), and you're watching photons which "leak" through the fiber. "Insertion" loss for a single tap is in the "noise" and normal fluctuation levels of the transmitter/receiver pair. I suspect the tap has been improved over the past quarter century. See http://catless.ncl.ac.uk/Risks/5.67.html#subj3

Babbage+Lovelace probably come closest to being the inventors of IT, and were recognised as such in particular by Turing, but they never saw the actual machine running in their lifetimes. At any rate, there are many more candidates, contributors and contenders for this honor than one usually learns at school or from the news media...

Here is one very interesting article by an author not to be confused with the interviewer (as they are bearing almost the same last name): Randell, From Analytical Engine to Electronic Digital Computer, http://www.cs.ncl.ac.uk/research/pubs/articles/pap ers/398.pdf

> Biometric passports and most other applications that need secure tokens utilize smart cards.

Except for the ones which really are planed to use RFIDs.

Here's some homework for you:
http://www.schneier.com/blog/archives/2005/08/rfid _passport_s_1.html
http://www.theregister.co.uk/2006/01/30/burnham_rf id_evasions/
http://catless.ncl.ac.uk/Risks/22.98.html#subj7.1
http://catless.ncl.ac.uk/Risks/23.87.html#subj5.1

> Biometric passports and most other applications that need secure tokens utilize smart cards.

Except for the ones which really are planed to use RFIDs.

Here's some homework for you:
http://www.schneier.com/blog/archives/2005/08/rfid _passport_s_1.html
http://www.theregister.co.uk/2006/01/30/burnham_rf id_evasions/
http://catless.ncl.ac.uk/Risks/22.98.html#subj7.1
http://catless.ncl.ac.uk/Risks/23.87.html#subj5.1

I would suggest looking at this:
http://www.csr.ncl.ac.uk/vdm/

"Each of the pair of solid-fuel boosters was made from four separate segments that bolted end-to-end-to-end together, and flame escaping from one of the interfaces was what destroyed the shuttle"

"Although the obvious solution of making the boosters of one long segment (instead of four short ones) was later suggested, long solid fuel boosters have problems with safe propellant loading, with transport"
http://www.msnbc.msn.com/id/11031097/

The decision to make the boosters in segments was a political one and not a technological one. The fact is that the booster rockets had to be made in the home state of the 'powerful Republican senator` in order to get approval for the budget. At the time there was a lot of complaint about the excessive spending on space flight. The managers at NASA were told to come up with a cost effective solution that would allow cheaper routine missions with a reusable vehicle. With hindsight it is easy to see that the technology could not deliver.

Regarding 'the obvious solution .. was later suggested` this is incorrect. The engineers repeatedly reported problems with the infamous O-rings. Their objections were repeatedly ignored by the management. Why Oberg would propagate this distortion at this time is curious to say the least. After all he is a reporter at the prestigious MSNBC.

The facts are that Roger Boisjoly, the engineer with Morton Thiokol protested against the launch. Here is an extract from a memo he wrote in July 1985 *seven* months before the disaster. Later on Roger was forced out of MTI. No one at NASA or Morton Thiokol has ever been heald accountable for the shuttle disaster and the loss of seven lives.

"This letter is written to insure that management is fully aware of the seriousness of the current O-ring erosion problem in the SRM joints from an engineering standpoint"

"It is my honest and very real fear that if we do not take immediate action to dedicate a team to solve the problem with the field joint having the number one priority, then we stand in jeopardy of losing a flight along with all the launch pad facilities"

http://onlineethics.org/moral/boisjoly/MTImemo1.ht ml

'Don't launch.' .. 'Don't launch.' Roger Boisjoly,

"I felt I really did all I could to stop the launch." Roger Boisjoly,

http://catless.ncl.ac.uk/Risks/5.78.html

"Approximately one month after my testimony to the House Committee, I could no longer endure the hostile environment at MTI,"

http://onlineethics.org/essays/shuttle/post-dis.ht ml

That said, here's some documentation for that claim, some of which include suggestions for how to easily bypass such systems, perhaps one of them will work for you, although I don't recommend the first one:

Malaysia car thieves steal finger

DHS and UK ID card biometric vendor in false ID lawsuit

Unsupervised biometric scanners more toys than serious security

Impact of Artificial Gummy Fingers on Fingerprint Systems