Trojan-Infected Computer Linked To 2008 Spanair Crash 324
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)."
Its an MD82 (Score:4, Informative)
wiki link [wikipedia.org]
Beyond the translated Spanish article I can't find anything else about this idea of an alerting system being infected with malware. Typically such systems are simple, embedded and not interfaced in ways which could cause them to run software they are not meant to.
This bit from wikipedia is interesting:
The MD-80 Advanced was to incorporate the advanced flight deck of the MD-88, including a choice of reference systems, with an inertial reference system as standard fitting and optional attitude-heading equipment. It was to be equipped with an electronic flight instrument system (EFIS), an optional second flight management system (FMS), light emitting diode (LED) dot matrix electronic engine and system displays. A Honeywell windshear computer and provision for an optional traffic-alert and collision avoidance system (TCAS) were also to be included. A new interior would have a 12% increase in overhead baggage space and stowage compartment lights that come on when the door opens, as well as new video system featuring drop-down LCD monitors above.[4]
link [wikipedia.org]
Apparently this upgrade got dropped in 1991, so the system still in use must be pretty low tech.
Re:The pilots were incompetent (Score:5, Informative)
From the Wikipedia page [wikipedia.org] (emphasis mine):
"On 17 August 2009, CIAIAC released an interim report on the incident [21]. The interim report confirmed the preliminary report's conclusion that the crash was caused by an attempt to take off with the flaps and slats retracted, which constituted an improper configuration, and noted that safeguards that should have prevented the crash failed to do so. The cockpit recordings revealed that the pilots omitted the "set and check the flap/slat lever and lights" item in the After Start checklist. In the Takeoff Imminent verification checklist the copilot just repeats the flaps and slats correct values without actually checking them, as shown by the physical evidence."
Daayum.
Nothing to do with the plane (Score:5, Informative)
Whoever modded up the above post - you've missed the point. There may have been a fault in the on-board management system - or human error failing to heed a warning - but nothing in TFA suggests that malware was in any way involved on the flight deck.
Summary needs a bit of clarification (Score:5, Informative)
But, the problem that was supposed to be logged was reportedly an overheated pitot tube. That was not the cause of the crash: the report says that the pilots did not set the flaps correctly and a warning alarm did not go off. This was not related to the problem with the computer being used by mechanics.
The article appears to be trying to link two independent events: a separate problem with the plane and an error by the pilots. Or maybe it's just the broken English translation.
Re:Shit. (Score:0, Informative)
Then you are at risk of a serious incident. Not having access to the internet greatly reduces the probability of it, but it is still unacceptable for many reasons. Even more so than having another OS AND access to the Internet.
Your decission-maker is morally liable if something bad happens. And even if the probability is lowered for not having access to the Internet, the consequences if something happens will be equally serious.
Re:Complimentary 7 point Slashdot troll guide... (Score:3, Informative)
Re:Summary needs a bit of clarification (Score:5, Informative)
Spanish is my mother tongue, so maybe I can shed more light after reading the original article:
The procedures of Spanair are to log incidences right away whenever they are detected. Three accumulated incidences and the plane is grounded.
Two incidences had been found the day before the crash. One incidence was detected on the same day of the crash.
However, the technicians did not enter the incidences into the system right away, because the system was too slow (assumedly due to the malware)
The system did not trigger any alarm on the same day because the incidences had not been entered by the technicians. The plane was deemed airworthy, and then the accident happened due to the multiple causes described elsewhere.
Re:Summary needs a bit of clarification (Score:5, Informative)
The infected computer was one being used by mechanics to enter maintenance log entries. According to the article, an alert is supposed to be raised if three failures in the same part or subsystem occurred. If I understand the broken English correctly, they would have taken the plane out of service had the maintenance log entry been completed before the plane attempted to take off.
But, the problem that was supposed to be logged was reportedly an overheated pitot tube. That was not the cause of the crash: the report says that the pilots did not set the flaps correctly and a warning alarm did not go off. This was not related to the problem with the computer being used by mechanics.
The article appears to be trying to link two independent events: a separate problem with the plane and an error by the pilots. Or maybe it's just the broken English translation.
Very true - the accident appears to have been the result of a series of crew errors that lead to an improper takeoff condition:
From Wikipedia: On 17 August 2009, CIAIAC released an interim report on the incident [21]. The interim report confirmed the preliminary report's conclusion that the crash was caused by an attempt to take off with the flaps and slats retracted, which constituted an improper configuration, and noted that safeguards that should have prevented the crash failed to do so. The cockpit recordings revealed that the pilots omitted the "set and check the flap/slat lever and lights" item in the After Start checklist. In the Takeoff Imminent verification checklist the copilot just repeats the flaps and slats correct values without actually checking them, as shown by the physical evidence. All three safety barriers provided to avoid the takeoff in an inappropriate configuration were defeated: the configuration checklist, the confirm and verify checklist, and aircraft warning system (TOWS).
Had they not made a series of compounding errors the flight probably would have been uneventful; it appears the deactivated systems was not related to the crash. It may be that some other systems were improperly set - ground vs flight mode - which caused problems and may have contributed to the accident; but none are related to the maintenance computer. Should the plane have been grounded due to an early problem? Maybe; but that may not have prevented the errors that lead to the crash.
We'll never know what the pilots were thinking; but having aborted one takeoff they may have assumed, intentionally or not, that they systems were set for takeoff and did a cursory check as a result; I've seen that happen in other industries where checklists are used. You interrupt the expected course of actions and people simply pick up where they left off, without assuring the systems were properly set for operation.
Re:Swiss cheese (Score:3, Informative)
Instead of indicting everyone under the sun, let's do something to fix it instead of tossing people in jail. Many people contributed a little, like Murder on the Orient Express. In the end, the ultimate responsibility rested on the Pilot-in-Command who paid the price for his mistakes. Let's learn from it instead.
1. Revise procedures so that the PNF (Pilot-Not-Flying) visually confirms the flap & slats indicator instead of just reading it to the PF (Pilot Flying)
2. Design future systems such that the take-off config warning isn't on the same circuit breaker as the Total-Air-Temp sensor. (I'm a recreational pilot, not an engineer, so I don't know if there's a valid reason for them to be on the same circuit.) Also, have an EICAS warning when the take-off-config alarm is disabled.
3. Have the engineers remind the pilots / placard the cockpit to remind them that the take-off-config alarm is disabled.
4. Flapless take-off attempts leading to accidents are not a new thing to airplanes. Further training seems to be required, especially as the small aircraft we all initially learn in will take off without flaps.
Re:Shit. (Score:1, Informative)
It's funny because it's true:
I have some friend in IT-maintenance jobs for the government. (intalling PCs, troubleshooting, ...)
Because they had an internal firewall and everybody has a conventional phoneline, someone in the tax-office (yes, those were people who process your taxes) found he could plug in the phone into his onboard 56k-modem and do whatever he wanted online.
After tedious virus removal over the entire departments (they all thought it was a neato trick) the guy just glued 56K-modem connectors into the PCs. The virus-rush was over.
Re:Shit. (Score:1, Informative)
We had to secure a computer at a company I worked at years ago. The IT department claimed it was secure (they had put Norton AV and firewall on it) I laughed when the owner of the company told me about it. He asked if I could do better. I put the computer in a metal drawer, locked it, drilled a hole in the back for the cables to come out and handed him the key. "There, now it's secure." He thought I was kidding until I pointed out the USB ports and drive bays.
An hour later the computer melted...
Re:What operating system was used? (Score:3, Informative)
Sure, a Linux box can get rooted, but I've never seen one, and I've installed Linux on friends' computers when I got tired of reinstalling Windows for them after the thing slows to a crawl from malware. Once Linux was on it, they never got infected again.
Of course, to be victim of a trojan you have to know how to install a program ;)
Re:Shit. (Score:3, Informative)
Actually two, operational blowout preventers were called for in the regulatory specifications. Turns out the single blowout preventer had no battery juice available. The system is supposed to work, by the batteries closing the hole automatically when detection of the control monitoring software fails. But if the batteries to the sole preventer don't have the juice when needed, bad things can happen. Someone thought the costs vs. risks were negligible, so they settled for less.
Re:Shit. (Score:1, Informative)
RyanAir is planning on charging £1 per trip to te bathroom in the near future, coin-op style...
Re:Mission Critical (Score:3, Informative)
Indirectly, the maintenance mainframe's failure to alert on related system faults MAY be a factor in future mishaps, but it does not appear that the infected mainframe had anything to do with this one.
Re:Shit. (Score:3, Informative)
Let me be a bit more clear about this:
No, those OSes are not secure. Quite the opposite. Almost all of them are very primitive, and have wide-open memory models that allow anything to run, allow anything running to touch any location in memory, and don't log a thing about it. More recent versions of them may have memory partitioning and privileged-user-only modes, but don't bet on the more recent versions being used even on brand new projects.
The innate vulnerabilities to coding errors presented by this openness are alleviated by performing exhaustive (and expensive) testing of every function in the system to be sure it does what it's supposed to, and exhaustive (and expensive) testing of the system to be sure it does what's required of it, and exhaustive (and expensive) evaluation of the requirements to be sure they cover all of the safety-critical and mission-critical possiblities.
And then you still get gomers on the flight deck disabling safety alerts on a poorly maintained aircraft and executives in the airline HQ giving them a wink and a nod for it while looking all stern (or waving a bulging envelope) at regulator visits.