Bruce Schneier
Schneier on Security
A blog covering security and security technology.
« Friday Squid Blogging: Flying Squid | Main | Skeletal Identification »
August 23, 2010
Malware Contributory Cause of Air Crash
This is a first, I think:
The airline's central computer which registered technical problems on planes was infected by Trojans at the time of the fatal crash and this resulted in a failure to raise an alarm over multiple problems with the plane, according to Spanish daily El Pais (report here). The plane took off with flaps and slats retracted, something that should in any case have been picked up by the pilots during pre-flight checks or triggered an internal warning on the plane. Neither happened, with tragic consequences, according to a report by independent crash investigators.
More here.
I have long thought that the Blaster worm was a contributing cause of the 2003 blackout in the U.S. and Canada.
EDITED TO ADD (8/23): In the comments, many readers point out that there are a bunch of problems with the El Pais article this is all based on, and that we should wait for more information before drawing any conclusions.
EDITED TO ADD (8/25): Two rebuttals, both worth reading.
Posted on August 23, 2010 at 6:03 AM • 45 Comments
To receive these entries once a month by e-mail, sign up for the Crypto-Gram Newsletter.
Comments
David - spaniard • August 23, 2010 6:22 AM
Bruce,
there is a big controversy here in Spain about that article. If you carefully read 'El Pais' article, you can realize that is full of mistakes and incongruences. Blaming a trojan for the accident after two years is clearly an irresponsibility. I don't know who has started saying this FUD, but he/she should think twice before talking about something in such traumatic incident.
It is also interesting that no one from Spanair has stated anything about this
Angelilt0 • August 23, 2010 6:22 AM
I would be very sceptic about the new until we do not have more official information
Given the fact that the media in Spain are very sensationalist, specially 'El Pais,' I would wait until an official report is published.
The original new from 'El pais' is not accurate, is full of errors, technically is a disaster, etc.
The official report can be found in https://docs.google.com/fileview?id=0B0pfYzMV8pNBOGMxZTkxZWUtMDE0NC00MTA1LWIxNDUtNzlmMjNkZGViMDk3&hl=es (Spanish)
Banjoman0 • August 23, 2010 6:56 AM
I agree. I have heard that the trojans were found in a maintenance computer (consistent with the narrative quoted above) and not in any onboard system. That the trojans may have prevented this central computer from raising a red flag about excessive maintenance issues is debatable, but the idea that it obviates the responsibility of maintenance crews to talk with the pilots, or the responsibility of the pilots to pay attention to the aircraft they are operating, is completely laughable. These trojans are a feint to distract us from the human errors involved.
Jelle • August 23, 2010 7:02 AM
Assuming the article is correct; if the maintenance computer had been working fine, the plane would not have been allowed to fly. However, the cause of the crash was supposedly not a technical problem with the *plane*, but a *pilot* error - which could just as well have been made in another plane...
bob (the original bob) • August 23, 2010 7:11 AM
"..should in any case have been picked up by the pilots during pre-flight checks..."
That would not have helped. The flaps/slats are SUPPOSED to be retracted when its parked. Taxiing with flaps down is an international "I am being hijacked" indicator. Plus flaps down is just begging for a ramp rat or service vehicle to collide with them, breaking either the control surface or the person who hit them; either way delaying the flight.
OTOH, there is an entire book of checklists for every stage of flight (even in a little bugsmasher like I fly) and the most important one is "takeoff checklist" and it sure as hell lists flap settings.
That said, I have been worried for years about the growing attitude of "the computer (which has a finite set of input sources and a limited set of responses to each) knows better than the guy driving" about things like control surface deflections or power settings. If they could develop programs THAT good they would fly the plane without pilots at all, cause leaving out the human control stations would make room for probably 10 more paying pax.
But, if they cant automate railroad trains yet, they certainly cant automate planes, which move through 3x as many dimensions, have an infinitely narrower scope of movement and require much faster responses.
Plus, the more boxes you put on an aircraft to do the pilots' jobs takes the human farther out of the loop, which puts them farther behind the power curve when something does break and they have 37 seconds to figure it out and make the appropriate correction (a la the ATR 72 tailplane icing crash). And of course the more boxes there are, the more likely one is to fail.
Finally, something important like this (plus obvious others like power plant controls, traffic lights, hospital, etc) should have an "air gap" development process which never involves the internet.
Clive Robinson • August 23, 2010 7:44 AM
I think the point Bruce is trying to get across is the one that concerns me.
This the first time that I'm aware of where "malware" has been "claimed as a cause" of the failure of "infrastructure".
(see the title of this article for instance
http://www.autoevolution.com/news/...
)
The fact that this may have happened as a "lost in translation" process from an original article (in spanish that I certainly have real trouble reading) is unfortunate.
But the scary bit is the way the "usuall suspects" of APT have jumped on this, and not thought through the few available facts (which Bruce has given)
Think this through is something most people can do (see my comments on Fridays Squid page http://www.schneier.com/blog/archives/2010/08/... ).
So the long term harm these Cyber Infrastructure threat "chicken little" types cause in persuance of their short term political agenda is difficult to guess. But is in a way the subject of legend with "the boy who cried wolf".
I feel saddened that on the second anniversary of the tragedy (and the twenty fifth of Manchester British Airtours tragedy) that they realy don't show sufficient "due diligence" before they go tilting at windmills in Spain.
Preston L. Bannister • August 23, 2010 8:52 AM
Whether there was malware (or not) in a computer on the ground, the first responsibility for flying the airplane always belongs to the pilot. Configuring the aircraft for takeoff is solely the responsibility of the pilot.
Sometimes pilots make mistakes, being human, and on-board computers can warn of the more easily recognizable sorts of mistakes. This is not the responsibility of computers on the ground.
Sometimes airlines, in order to increase profits, hire poorly trained pilots, and/or they work pilots for too many hours. This puts a pilot with limited the abilities (due to inexperience, and/or fatigue) in the cockpit. In this case the chain of responsibility extends to the airline.
Focusing on malware in a ground computer is at best silly, and at worst a deliberate misdirection.
@itinsecurity • August 23, 2010 8:56 AM
A bit of FUD in this, yes.
Tech writers seem to attribute a lot of significance of this maintenance system in the chain of events.
Even if the maintenance system in question had been fully operational, it wasn't something that would've popped up warnings all over the place and alerted all the world. It would have issued an alert to the maintenance crew. However, seeing as they and the flight crew had already deliberately ignored other non-critical alerts (as per protocol) it get's a bit theoretical whether they would actually have been concerned about this at the time. Both crew and maint crew knew of problems, since they were working on it, why didn't they react?
It will be interesting to see the final report (due end of year 2010, I think) on what actually happened and what could realistically have prevented it.
The alerts issued for the plane, that caused them to return to the gate, had not been critical to safety by themselves, and they were basically ignored in the end.
What scares me the most here is that they could cut power to a critical component (alarm system), and nobody or nothing noticed.
Perhaps a design flaw?
Apparently this has happened at least twice before: Delta flight 1141 and Northwest flight 255.
Control Freak • August 23, 2010 8:58 AM
Yeah, let's ramp up the fear level.
Oh, no! The things we created now control us -- and now something is terribly wrong! The plot of hundreds, if not thousands, of sci-fi books and movies.
No one is pointing to the possible solutions. It's expensive to produce quality control systems. It takes time and careful work by a well-trained, skilled, thoughtful workforce. Yet, companies now settle for products using "consumer grade" materials designed and produced by inexperienced and under-trained people.
Control systems work is not exciting and glamorous. Those in the field don't produce splashy screens graced by images of lithe young models. They're Dilberts in fabric-covered boxes. We don't want to pay for the continuous training, salaries, and expertise of the few people who decide to stay in that profession and we gripe when bad things happen more frequently than we've come to expect.
Clive Robinson • August 23, 2010 9:24 AM
@ Bob (the original bob),
I like many others view this "entire book of checklists" into much broader catagory (pre / flight / post / maintenance) as this is the way it is usually portrayed in the press and other information outlets not specificaly directed to those in the field of endevor.
However it is somewhat scary that having such a system "learnt the hard way" (in less than a century) some pilots have for whatever reason decided to ignore it and thus become "totaly" reliant on "the computer" which is less than satisfactory...
karrde • August 23, 2010 9:31 AM
I think it must be made clear to all reporters (and news consumers) that the argument is over whether the malware was Necessary to cause the crash, under the knowledge that it was not Sufficient to cause the crash.
Of course, I probably expect too much of the poor reporters, who has likely never met the logical distinction between necessary and sufficient causes.
spaceman spiff • August 23, 2010 9:37 AM
If this reports turns out to be factual, then what is the probability that the system in question is running some version of MS Windows? And has some means of outside access and/or direct vector of infection (updates from USB or other removable media)?
BF Skinner • August 23, 2010 10:57 AM
@Clive some pilots have for whatever reason decided to ignore it and thus become "totaly" reliant on "the computer" which is less than satisfactory...
@Preston L. Bannister Whether there was malware (or not) in a computer on the ground, the first responsibility for flying the airplane always belongs to the pilot. Configuring the aircraft for takeoff is solely the responsibility of the pilot.
I don't think this is entirely fair or representative of current trends and risks.
Now I grant that crashes are more often due to human rather than aircraft failure. I think there was a recent study on this...but the pilots are being removed from their enviornment. Is the pilot responsible to make sure the maintenance on the engines or other components was completed competently?
When I was taught to fly I was told to keep a flashlight close at hand in case of an electrical failure . If the power failed I would use the flashlight to read flight instruments which were mechanical. Technology has come along way since then and the amount of automation on a basic jet liner is immense. Electronic display of flight instruments, satellite positioning systems, ground based weather/scheduling systems (and of course maintenance systems) all supported by buckets of code. The pilot operates in this mesh of technology while being further and further insulated from the functioning of their plane.
Around the time that United Flight 232 (1989) suffered a catastrophic failure across it's triple redundent hydraulic system and pinwheeled across the runway in Sioux City Iowa...there had been questions from airlines about the worth of pilots. The automation was at such a point the Airlines didn't see it worth paying premium wages for. The pilots who flew 232 and allowed 185 people to walk away from the landing (111 died) were presented as a testament to why you want very experienced (and expensive) pilots around.
Second case. Aeroperú Flight 603 "On October 2, 1996, shortly after takeoff just past midnight, the Boeing 757 airliner crew discovered that their basic flight instruments were behaving erratically and reported receiving contradictory serial emergency messages from the onboard computer, such as rudder ratio, mach speed trim, overspeed, underspeed and flying too low. The crew declared an emergency and requested an immediate return to the airport." fm the wiki article
Since they were flying at night over water they had no external visual references. They didn't know they were at sea level until the aircraft wing actually dipped into the ocean. NTSA also found there were rolling left and right as the turn and bank indicator told the pilots they were banking too far. The pilots would then correct and since the data was errouneous over correct...(there was a good Nova program on this investigation - NOVA: The Deadliest Plane Crash, Flying blind.)
Others have brought up the airlines hiring lesser skilled pilots, Quick! Whats the difference between a 18" pizza and a pilots salary? The pizza will feed a family of four.
But it's also the complexity problem.
we are using code to drive our instrumentation and acquire our data. It does a good job of enhancing what's there but when it lies? (remember Zaphod's sunglasses?). And if it can lie about the nature of reality due to a maintenance or coding error the real risk to me is that they can be made to lie deliberarately.
BF Skinner • August 23, 2010 11:05 AM
Correction: Flying blind was a national geographic channel documentary part of "Mayday: Air Disasters" not Nova.
Though for some reason I still believe Nova covered this.
Google conflated search terms and lied to me.
Michael Ash • August 23, 2010 11:32 AM
According to a Spanish-speaking friend who has been reading about this story, the real cause was that the technicians were lax in entering problems into the computer system in question. In this particular case, the plane crashed first, and only afterwards did they enter the problems they observed. At that point they discovered that the trojan was suppressing alarms. That could have been problematic, but ultimately played no role in this crash.
yahya • August 23, 2010 11:36 AM
Could a malware cause a Polish Presidential plane crash on April 10, 2010? A `Russian' worm...?
Plane Buff • August 23, 2010 12:22 PM
There's some interesting discussion about this over at airliners.net:
bob (the original bob) • August 23, 2010 12:34 PM
@bf: "difference between a 18" pizza and a pilots salary" - LOL
Also, wasnt there a "computer" component to the erroneous shootdown of the Iranian airliner by the USS Vincennes? The Aegis air defense system was in a "training" mode showing fake attacks or some such, yet the crew was thinking it was realtime info?
Nick P • August 23, 2010 1:04 PM
@ Clive Robinson
"This the first time that I'm aware of where "malware" has been "claimed as a cause" of the failure of "infrastructure"."
Not quite. There's a long history of malware attacking infrastructure and doing damage. I remember a McAffee study talking about tons of DDOS and extortion attacks on the oil and gas sector. Then, Stuxnet was hitting SCADA systems. This would just be the first time the damage was catastrophic and newsworthy.
@ BF Skinner
There are still some hiccups with the systems but I think the new systems are much better thanks to FAA regulations. Particularly, the DO-178B software requirements do measurably increase software quality. There's a similar standard to ensure hardware works properly. DO-178B is also applied to the system level for integration and the safety-critical RTOS's and middleware are helping to isolate faults. The time and space partitioning RTOS's are specifically designed to keep a problem in one partition from affecting another. I don't see this kind of event happening on a well-designed DO-178B Level A system, as their isolation mechanisms are strong.
Aircraft manufacturers complain about how the standard slows their builds, but I think if it is followed it should prevent many catastrophic failures. I also plan to use DO-178B Level B+ middleware in a design for a medium assurance, highly available thin client and possibly a routing/VPN appliance. What do you think about DO-178B?
Ralf • August 23, 2010 1:17 PM
This story is nonsense and FUD, so I really urge everyone to look into the real facts. I would really hate if this story would stay around as a myth of killer malware.
The official (interim) accident report in english is available here:
http://www.fomento.es/NR/rdonlyres/...
Bottom line:
- The pilots did not properly stick to the relevant check lists (read out the items but didn't check)
- The indicators of the flaps/slats settings were NOT faulty and indicated flaps/slats retracted. The pilots should have spotted this.
- The TOWS (take off warning system) was most likely faulty. This system gives an audible alert, if flaps/slats are retracted during take-off roll). This system is not to be relied on, but rather a last line of defense.
- It appears that malware was found on GROUND-based computers that track malfunctions. Since that's definitely an issue, it may make sense to see if there's a possible contributing factor, but there is no indication that this is the case. The TOWS is only checked during the first flight of the day and no TOWS malfunction was noted.
As a pilot, it always hurts to hear that accidents are blamed on "pilot error", although in many cases that is only a small factor. However, let me tell you that not properly following your check lists is a grave mistake that unfortunately may have cost many people their lives. Although this is a very thorough interim report, it's still important to wait for the final version.
Period. End of story.
Renato Golin • August 23, 2010 4:32 PM
This is not just a pilot error, but the whole company is at miss.
I have seen this before in many accidents, the previous pilot tell the next "the light is faulty, don't trust it", and that time, it worked.
Some companies skip maintenance cycles (due to manufacturer's own recommendations) to save money. The pilots have very little say on that and are forced to fly crap planes, putting their lives (and the passenger's) at risk.
If there was malware or not in the central computer, I doubt there's anything to do with the crash. I bet the warnings were there all the time, but they managed to ignore it for longer than they should and blamed the malware to save their jobs.
One could even risk to say that they planted the virus themselves...
Unfortunately, some things are only fixed when people die... :(
gilberto • August 23, 2010 5:06 PM
I read the original report from the spanish aviation authorities, NO MENTION that there was a virus or trojan involved
gilberto
gilberto • August 23, 2010 5:13 PM
Documents available at www.ciaiac.es in spanish and english
gilberto
Erik Nørgaard • August 23, 2010 6:19 PM
OK, I haven't read the recent El Pais article. IIRC, the problem was a combination of technical and human error:
The craft had had technical problems before start which supposedly were resolved. According to the then manual of the craft, certain checks need not be repeated after this repair, which is why the pilots did not check the flaps *again*. There was not a system failure on board to alert of a problem during pre-takeoff checks.
However, two errors was identified:
- the pilots did not check the flaps again and hence the problem could not have been identified prior to takeoff.
- the onboard systems did not alert the pilots (or could be human error, they did not see the alarm?) at takeoff that the flaps were not out.
As I understand it, even with this recent claim, the inicial analysis of the cause remains the same.
AFAIK, the manual was updated after the accident.
Clive Robinson • August 23, 2010 6:37 PM
@ BF Skinner,
"Now I grant that crashes are more often due to human rather than aircraft failure I think there was a recent study on this."
I would urge caution on such studies, as was once observed "If the pilot died it was pilot error irrespective of other evidence to the contrary, if the pilot lives they can argue their innocence and fail at the board of enquiry".
The reason for this is the same as why the answer to your question,
"Is the pilot responsible to make sure the maintenance on the engines or other components was completed competently"
Is yes, it's the solely the pilots responsability to ensure the aircraft is airworthy...
However as it's not possible for the pilot to test everything there is a mountain of maintanence etc paperwork which he supposadly can "trust"...
From what I have been able to piece together this afternoon from non news sources the following happened,
Aparently the warning system (TOWS) was inadvertently disabled by ground maintanence staff due to another fault...
And although the cockpit crew went through the checklist and read out the check for flaps, they where interupted by a radio call and did not do the associated check... Thus the flaps where left retracted and when takeoff power was applied the TOWS system normaly should have sounded a warning horn... But the cockpit crew failed to notice it had been disabled thus no warning...
However other warnings (stick shake) happened as the plane got to about a house hight off of the ground it then rotated and went in.
The airlines trojan infected central computer system would probably not have stoped this particular tragedy, unless the system had reported the inadvertant TOWS disablement (which it should have done) and the aircraft grounded (as it should have been) as the lack of TOWS was a critical fault...
So a cascade of errors which the cockpit crew had atleast two separate chances to pick up on but failed to do so.
@ Nick P,
"This would just be the first time the damage was catastrophic..."
Ahh the difference is language use, I say "failure" you say "catastrophic".
I know it sounds like hair splitting but it is not ment to be and comes from my past designing safety critical systems.
To me damage to a system or subsystem implies some loss of functionality but importantly some functionality remains.
A faliure however to me means compleate loss of function for that system or sub system which can thus "fail safe" or not depending on the design.
Thus in my view even if "damage was catastrophic" it would not of necessity mean "failure" of the system. There have been aircraft with a catastrophic power loss that have been landed and thus where not an actual "faiure" of the whole aircraft.
BF Skinner • August 24, 2010 6:14 AM
But to reapproach the topic...
@Clive "This the first time that I'm aware of where "malware" has been "claimed as a cause" of the failure of "infrastructure"."
Let's not forget the 1984 CIA boobytraped code that the Soviets purloined, used and blew up their gasline with in the biggest non-nuclear explosion etc. Certainly a case of Malware.
But my concern would be mobile code. And if, somehow, that mobile code jumped from corporate system, to maintenance system to flight systems.
As an act of deliberate sabotage it might even be difficult to detect. Like a bomb it might leave residue (there were some heroic and effective forensics done on the SST Columbia harddrives) in the computers but, unlike a bomb; No one is looking for it.
Note to the comment police. Kurt Vonnegut sez never use a semi-colon. It just says to people "i've been to college"
Shane • August 24, 2010 11:13 AM
Malware or not, the root of this is still human error/negligence. Either based on lax pre-flight checks, or the idiot sysadmin who allowed malware to infect the 'central computer' systems.
This isn't a fucking home-office web/email box, this is an airline's central computer system. Malware should have never made it that far, and it sure isn't the system's fault.
Cloudesley Shovell • August 24, 2010 2:47 PM
@ Bob (the original bob)--
You said, "Taxiing with flaps down is an international "I am being hijacked" indicator."
That has to be one of the funniest yet grossly mistaken things about aviation I have ever read.
Check out the airliners at any airport--they're all taxiing out to the runway with their flaps down. Every one of them. Without exception. Every flight.
Yrs humbly (and still chuckling),
CS
JimFive • August 24, 2010 3:59 PM
@Clive
While people may divide the checklists into pre/flight/post/maintenance what they need to realize is that "flight" begins when the pilot starts the engine.
@BF Skinner
Re: "Is the pilot responsible to make sure the maintenance on the engines or other components was completed competently? "
As I recall the regulations, the pilot is responsible for determining whether the aircraft is airworthy. So at the very least the pilot must make sure that necessary maintenance was completed (judging the competency of the maintenance is the job of the A&P mechanic who signs off on the work).
--
JimFive
Carl • August 24, 2010 8:39 PM
The trains have been automated on the Paris Metro Line 14, programmed in Ada:
"MP 1989 AUTOMATIC trains
These trains have rubber wheels. These trains are the same as the 1989 trains, but there is one big difference... there is no drivers cab - the trains are completly automatic. There is no driver or any member of staff on the trains. These trains are currently running on line 14.""
@itinsecurity • August 25, 2010 2:35 AM
Interestingly, a lot of the commenters in that airliners.net forum that someone linked to, claim to be pilots. However when you read the discussion, they are as clueless as the rest of us.
chub flounder • August 25, 2010 1:16 PM
try this for clarity:
http://www.zdnet.com/blog/bott/...
cuz that's the way john wayne woulda done it!
Pilot/security consultant's analysis of the official report here: http://news.electricalchemy.net/2010/08/... with some FUD-less insights into the role the malware may have played.
BobW • August 25, 2010 7:09 PM
Shades of "The Adolescence of P1" by Thomas Ryan. While I use this book to describe malicious worm-like behavior, computers deliberately crashing airplanes is a significant plot element. Sadly, the novel is out of print.
Keith Sketchley • August 25, 2010 10:13 PM
I am dismayed at the inaccuracies and extrapolations in the media.
There also seems to be a logical fallacy in the reporting – while the claim is that the ground maintenance monitoring computer failed to see a trend from two past occurrences, there are also claims that the mechanics did not try to enter those two until after the crash (when they now had three occurrences), which makes the computer’s functionality moot (cannot make anything of what it has not been told).
Certainly the malware infection was serious and shows the risk that the safety level was not what it should have been since the ground maintenance monitoring computer helps detect patterns thus help ensure problems are truly fixed.
But the media reporting is a mash that just confuses things – it is only useful for one thing: to raise an example of the general risk of malware in ground computers.
Curt Gee crypt-keeper • August 26, 2010 3:45 PM
I don't know if anyone saw WSJ article about Automotive industry using "WiFi" to update entertainment systems in cars. But, it talks about possibility of other uses, hmm adjust gear shifting points in transmission I guess? Please, Bruce see this one! --http://online.wsj.com/article/SB10001424052748704504204575445642013867472.html?mod=WSJ_hpp_sections_tech
Clive Robinson • August 27, 2010 5:11 AM
Just heard on the 10AM news on the radio in the UK that,
"Pasengers where in fear of crashing into the sea on an airplaine to Hong Kong when an emergency message was played. A British airways spokesman said it had been automaticaly played by the computer."
And I thought ugh hu why would the computer do that...
So a quick look at other news sourses,
http://www.thisislondon.co.uk/standard/...
http://www.telegraph.co.uk/finance/newsbysector/...
Show no mention of a BA spokes person blaiming a computer for automaticaly playing the message only that of "the pilot" erroneously pressing the button.
Further investigation shows they got the story from the UK red top The Sun (known by many as "the scum" for their reporting style),
http://www.thesun.co.uk/sol/homepage/news/...
Show just how "Chinese Whispers" build up...
Sasha van den Heetkamp • August 27, 2010 9:44 AM
Even if it is a concoction, it certainly is interesting for numerous reasons. Maybe this case could opt caution for those who design software and connect them to all sorts of complex networks beyond their control. I would not be surprised if such event will take place in the future, such as Murphy's law epigram would predict.
Clive Robinson • August 27, 2010 4:00 PM
Further to my comment above About the BA Hong Kong flight ( http://www.schneier.com/blog/archives/2010/08/... )
The London Evening Standard has put the story in this evenings paper and the BA Spokes person is quoted as saying,
"We would like to apologise to passengers on board the flight for causing them undue distress."
"Our cabin crew immediatly made an announcement following the message advising customers that it was played in error and that the flight would continue as normal."
And the most astounding part the spokesperson added,
"There is nothing indicating that it was from the pilot, it's more likely to be a computer malfunction."
So we have a (supposed) spokes person for British Airways (UK's flag carrier) saying that a computer within the 747 aircraft malfunctioned, rather than simple pilot or steward error.
Anyone else find this somewhat disquieting?
Charles Jeter • August 28, 2010 2:22 PM
In my 'rise of the machines' article I noted this mishap. With a solid Naval Aviation safety background I offered the following opinion:
[Update 8/28 12:12] Clarity on the Spanair crash should be given; the maintenance computer found partially responsible was indeed infected with malware however this was not an onboard flight computer. Rather, it was the ground crew policy and procedure which was interfered with by the malware-ridden system. The flight would have been grounded according to policy had the alarm triggered, however the pilot error was ruled the primary cause of the mishap.
So the pilot made an error, the takeoff warning system (TOWS) failed to alert the pilot to the error, and this TOWS system was problematic, which would have grounded the plane had the malware-infected system the ground crew was using been operating properly. Any of the three issues being resolved would have saved 154 people, and that does include the malware on the flight system, which would have been ruled a ‘contributing factor to the mishap’ in Naval Aviation. Others have said it’s tertiary – there is no such thing. There are primary causes and contributing causes for a mishap. All contributing causes are equally to blame because without them the mishap may have been avoided, and that includes malware.
http://blog.eset.com/2010/08/25/...
As everyone else is picking nits:
"While people may divide the checklists into pre/flight/post/maintenance what they need to realize is that "flight" begins when the pilot starts the engine."
Not quite: flight time begins when the aircraft first begins to move under it's own power, for the purpose of flight. - FAA. ICAO leaves out the "own power" bit.
Chuck • August 31, 2010 4:08 PM
@CS
Certainly you see departing planes taxiing with their flaps down. Have you seen any do so after landing? That is the time when the signal is significant. It's not so much a signal of "I am being hijacked" as it is one of "I would like some assistance dealing with the hijackers that you already know about." There are other duress signals that can be sent prior to landing.
jahman • September 16, 2010 12:30 AM
The Trojan in question was a particularly contagious version that jumped the machine-human barrier: It infected the pilot and copilot brains!
C'mon fellas! Every pilot is trained tested and re-tested on proper procedures *must follow the checklists*! And the pre-take-off checklist of all major aircraft has the three "killer items":
1. Elevator trim in take-off range,
2. Spoilers retracted, and ...
3. Flaps extended!
Its simple, its basic, pilot and co-pilot do the checklist together and no trojan nonsense is going to make the aircrafft take-off with flaps retracted.
Unless the pilots are not up to par, in which case they *will* take-off with flaps retracted and even with the "killer items" alarm buzzing loudly! Yes, it has happened, and the audio is harrowing: You can hear the alarm buzzing from the moment the pilot sets take-off power until the crash 90 seconds later. When the "pilot" hears the killer items alarm, he says: "What the hell is that"? Seems he never heard the alarm before!
Read about LAPA Flight 3142: http://en.wikipedia.org/wiki/LAPA_Flight_3142
Hear the cockpit audio: http://www.airdisaster.com/download2/nw255.shtml
Oh, and did I mention no trojan was involved?
Cheers,
- jahman.
tab • September 18, 2010 8:44 AM
@JimFive:
[As I recall the regulations, the pilot is responsible for determining whether the aircraft is airworthy. So at the very least the pilot must make sure that necessary maintenance was completed (judging the competency of the maintenance is the job of the A&P mechanic who signs off on the work).]
You are completely correct. Even in ground based systems (ie: trains and busses), there is (at least in the US) a log book that shows EVERY maintenance issue the person controlling the system AT THAT TIME has experienced. The log shows who reported it, who fixed it and what was done.
The report on this incident says that there were three flights in two days WITH DIFFERENT CREWS, so no one caught it at the aircraft level. This is a systems DESIGN failure (not malware) in that it relied on steps outside of the pilots area to ensure aircraft safety.
No matter whether it is aircraft, trains, buses or any other system, the person controlling it (in this case the pilot in charge of the aircraft) should have been told that there was a potentially unresolved problem with the aircraft (via log book), which MIGHT have prompted them to request more information from the maintenance crew before initiating the takeoff procedures.
Irrespective of that, the failure to FAITHFULLY follow the pre-takeoff and takeoff checklists was the proximate cause, with the failure in maintenance procedures and documentation as a contributing factor.
Per L • September 20, 2010 9:23 AM
So, a" central airline computer" should have had trojans? Do they really use PC:s for that kind of tasks, I don't think so. Or have anyone heard about mainframe or UNIX trojans...?
Subscribe to comments on this entry
Schneier.com is a personal website. Opinions expressed are not necessarily those of Co3 Systems, Inc.
|
| Subscribe |
Subscribe via Kindle |
| Blog Menu |
SearchPowered by DuckDuckGoBlog Home Page
Archives by Date2014 J F M
Tags  |
| Latest Book |
more books by Bruce Schneier |
|
Leave a comment