Trojan-Infected Computer Linked To 2008 Spanair Crash

An anonymous reader writes "Two years ago, Spanair flight JK-5022 crashed shortly after takeoff in Madrid, killing 154 of its 172 passengers and crew. El Pais online newspaper reports that the ground computer responsible for triggering an alarm after three failures are reported in a plane failed to do so. The computer was infected with trojans (Google translation of Spanish original)."

Comments

Complimentary 7 point Slashdot troll guide...

[vistapwns]

Here is your complimentary guide to trolling this story: 1. Pretend only windows can get infected with trojans. 2. If you can't do 1. adequately, then pretend Windows is some how easier to infect with trojans than other OSes. 3. Accuse anyone who disagrees with you of being paid off. 4. Make thoughtless absolutists statements like Windows has no security model, and is not a networking OS. 5. Mention chair throwing as proof that MS personnel are unstable, but never mention wife murdering linux developers. 6. Repeat other MS bashers without researching what they're saying. 7. Mention "640k ought to be enough for anyone" as much as possible without giving thought to the brain dead simple idea that MS had nothing to do with the addressable memory limit of the 8086. Following this guide is sure to get you modded up and liked by many other slashdotters, so be sure to follow it closely!

Swiss cheese

[Fzz]

The crash of an airliner these days is rarely due to a single cause. There's a saying in the industry that a crash occurs when the holes in the Swiss cheese happen to line up. This appears to have been the case with this particular crash.

• The direct cause was that the pilots attempted to take off without setting take-off flaps.
• They were rushing because they'd had a technical issue, and returned to the terminal after previously taxiing to the runway and completing the take-off checks. So they accidentally skipped the critical check that the flaps were deployed when they lined up to take off the second time.
• There's a take-off configuration alarm that is supposed to alert the pilots, but it wasn't working.
• It wasn't working because the engineer removed the circuit breaker that powered it, in order to turn off a stuck heater on a pitot tube that was due to a malfunctioning switch.
• This particular fault had been noted on previous flights, so should have flagged a warning on the airline's fault monitoring system.
• The fault monitoring system had a trojan.

Yup, the holes in the cheese certainly lined up that day. None of these, by itself, would have caused the crash.

Re:Shit.

[JamesP]

We run critical stuff on Windows, they don't have access to the Internet. Deal with it.

Well, no. It's you who has to deal with it.

good luck

Re:Shit.

[tibit]

Those mission-critical-designed-for OSes are, unfortunately, likely to be secure by obscurity. Something like vxWorks or QNX is not a big enough target for malware writers or blackhats, but I'm quite sure those platforms are full of holes simply because they are not very exposed. I'd say that linux, perhaps with realtime extensions, would be a somewhat better platform -- it's exposed way more, and most of the holes have been patched.

Re:Mission Critical

[DougF]

Hate to rain on the IT parade here, but the investigation revealed that the aircrew had the aircraft on "in-flight" mode, leading to erroneous indications (forcing the first abort), and then excluding the no flaps/no slats pre-takeoff configuration error warning. The crew also called for the flaps/slats settings to be proper without actually checking them. In effect, they were able to defeat three separate safety measures to prevent exactly this kind of mishap from happening.

It does not appear that an infection of the mainframe maintenance computer is anything more than a side note in this particular mishap. It may, however, be something for airline maintenance personnel to be aware of to prevent future incidents.

The real question is why the aircrew are allowed to override a weight-on-wheels (WOW) sensor, when that is primary used for troubleshooting by ground crews. Putting the aircraft into "flight" mode while on the ground requires special attention to actions/procedures (as in when a USAF F-4 shot up a maintenance truck when the WOW switch was in override and the weapons crew performed an ops check on the gun system--ops check good, BTW).