Track them down
Track the writers of these trojans down and charge them with manslaughter too. If they live in the eastern block or China, have them disappear.
Malware may have been a contributory cause of a fatal Spanair crash that killed 154 people two years ago. Spanair flight number JK 5022 crashed with 172 on board moments after taking off from Madrid's Barajas Airport on a scheduled flight to Las Palmas on 20 August 2008. Just 18 survived the crash and subsequent fire aboard …
To me, allowing for the differences in Spanish legal process, it sounds like the Spanish are looking at the two people to see whether they were "negligent" in performing their duty and if so whether there is grounds to charge them (after all despite the central computer issues - there was problems with the plane they seem to have missed). I would hope the same sort of investigation would happen in UK
Relatives of the victims were on TV yesterday stating quite clearly that they wasn't settling for any goddamn money (you can call that typically spanish too, I'm sure many others would settle for a handful of dimes). So now they REALLY have to find someone to judge/trial and I maybe they're trying to get Windows to be their scapegoat.
Spanish and any other nationish do the best they can, I doubt anybody intended to get 154 people killed. If the original poster was taking the piss about that then I sincerely wish him the worst available.
1 Microsoft Way
Redmond, WA 98052-8300
When are companies gonna stop using a windows operating system for this kind of tasks! It's not fit for these kinds of duties.
The airplanes embedded systems of course work fine until they upload data to "the airlines central computer" running Microsoft Windows. This pc like any other Windows pc is riddled with viruses and malware.
It's also time to make Microsoft apply proven scientific safety measures in their operating system. It's a disgrace that the most used OS is not secure only because the maker refuses to implement those security standards! Now even Intel -by buying MCafee- takes it upon their tasks to protect users from Windows and the US government needs special Cyber Warfare regulation to take out Windows botnets! It's the world upside down.
I really hope Microsoft get's suit over this.
What makes you think it was a Windows system? I use Windows, OS-X (on my girl friend's computer), and Ubuntu. All have had malware issues. The OS-X being the worst, as my girl friend suffers from the delusion that "Mac's can't get viruses" and "all crashes are due to Flash even when the only thing running is Excel", and so refuses to put anti-virus on the POS.
really it would not had matter what OS they were using wether be MS or MAC or LINUX including anu open source OS that is out there. if malware writers decide to use single or multiplaform deliverysystem it eventually get delivered. so suing MS over this is useless. as for anit virii monitoring the best cure is prevention but even then it is impossible to prevent infection as any IT proffesional worth their weight in caffeine will tell you.
but what can be done is this find the authors of the malware and after proven guilty execute them very painfully say like making them die and be revived for each death until they are ready to go to great beyond. it is not as to be cruel but to set world wide example that even writing that crap iand thinking about it is way too dangerous.
I think the point of this article, if you read it, is that a mechanic or other person who had *direct* access to the computer may have planted the trojan. Whether the trojan was installed in the airplane's computer or the airport's central computer system doesn't matter. The person had direct access to the network, possibly with the credentials required to propagate the malware through the system.
If someone has direct, possibly privileged, access to a computer, how do expect the OS to fend off whatever the user is trying to plant?
"I really hope Microsoft get's suit over this." - If it really was the mechanic or supervisor who installed the trojan, Microsoft has nothing to do with it, so no, they won't get sued.
Microsoft probably has some of the securest OS around given that they have had 10 years of near constant onslaught to deal with. And they are getting better both in programming practice and design.
I use Windows 7 and BSD at work and OSX at home.
I would make an educated guess that the potential to find flaws in Windows might be 25% or less.
Whereas in OSX this quantity could well be 75% or more.
Microsoft also do a good job of fixing flaws found monthly.
It can only get better.
If market uptake of the OSX platform advances to where it becomes of interest to malware writers, you can expect it to get worse long before it gets better.
You are such an idiot for writing that.
Do you read the register?
"Good job at fixing flaws"? Well yes probably. However "if they did a good job at the start, they wouldn't need to fix the flaws so often", could also be said?
And 15 years of being crap makes them so very good at fixing stuff.
You may not be an idiot, but you may be very ignorant of what "secure" is.
If I park my car in my garage and don't lock the doors, it is more secure than leaving it in a downtown parking lot with a cell phone on the dash.
Security is not an absolute state of something, it is relative to the environment, to the number and sophistication of those who see a target.
Windows is targeted MUCH more often, making it less secure even with fewer security holes (which is arguable in itself).
You conceded this yourself with the remark about OSX, except you are wrong that things can only get better because they keep increasing the complexity of the code, and that with no real competitive need to keep the software quality high. Their interest is as expected, to sell the product, not to make it the best it can be beyond what effects sales. You can't blame them for that, if only they had not tried to have a captive market so in mission critical uses like an airplane, there were competitive solutions contending for the same TCO for the airline.
Some operating systems simply should not be used in mission-critical tasks, and that probably includes Linux as well. A system like QNX, Tandem, etc. should be used instead and leave it closed. The level of attention to detail needed for such tasks (think nuclear power stations) needs a completely different category of OS
Read. They were running Windows. Not on the plane of course. Those usually have three separate independent embedded (non-windows) systems for fail over purposes.
The plane should however, never have been allowed to take off.
And that decision was made by the central computer of the airline. This computer should have told the planners that the plane was not ready for duty. Maybe it should have been sent to maintenance. Unfortunately, that central computer was running Windows with all the viruses and malware that comes along with that. So the plane never got flagged for maintenance.
Horrible. And hopefully a wakeup call!
"They were running Windows. Not on the plane of course. Those usually have three separate independent embedded (non-windows) systems for fail over purposes.
The plane should however, never have been allowed to take off.
And that decision was made by the central computer of the airline."
From reading the article the pilots should have actually picked up issues and aborted the take-off. A bug-ridden control system is one thing, two complacent pilots in control is another.
In fact, this totally applies this time. Windows has never been designed to run in stuff requiring real-time responses, and as a matter of fact, plain vanilla Linux isn't designed for that either. Fortunately, this might give a good warning to those idiots who insist on putting Desktop OSen in real-time hardware.
Many flights are planned on laptops, which are provided by the company and that are used in flight in the cockpit. Stories were in the press a few years ago about security procedures intended to prevent passengers from bringing destructive items dressed up as working laptops, but which some over-zealous security types were also trying to apply to flight crew, unaware that the items in question contained flight plans, crew manifests, schedules etc.
http://www.usatoday.com/travel/flights/2009-11-18-laptops-ban-pilots_N.htm - dealing with one flight, but shows another pilot using a laptop and mentions one airline's policy.
So, if these are networked on the ground to download various items, potentially there is a way for Trojan-infested devices to get into the cockpit.
It's more likely that the Trojans were introduced in the scheduled service updates.
This is ridiculous - not only does the plane have its own self redundancy in its control systems the pilots should have gone through preflights and such. Not to mention the ground crews.
I'd be very interested to find out what the suspected cause of this crash is - because I get the feeling its something utterly stupid - and the PHB's are blaming anything they can get their hands on because they would be covered in lawsuits if it came out.
Modern avionics systems have at least three different computer control circuits built into them which are self monitoring - not to mention other safeguards - I find it hard to believe that a groundside computer running windows of all things would be responsible for the *entire* maintenance and troubleshooting of an airlines fleet...
Fail is just piling up in this one..
The article mentions the cause of crash - they took off in the middle of summer without flaps and slats set. As aa result they could not achieve enough lift to get off the ground, and quickly ran out of runway, when they did try and lift off, they veered off to the side and crashed.
I believe from reading elsewhere that the horn which should alert pilots to an incorrect takeoff config had been disabled, therefore they were not alerted to the fact they had not lowered the flaps + slats. Having said that, their own checks should have picked this up, but in this case they didnt, and the backup system was disabled.
....there was a fault causing the air temperature probe for the autothrust system to read high. This fault was what caused the crew to return the aircraft to the stand. It was part of the power distribution panel that had a failed relay.
The high temperature reading (it affected the automatic thrust calculation for takeoff) was isolated by tripping a circuit breaker but while this masked the fault and allowed the thrust to be set manually, it did not cure the fault itself. The same fault also led to the takeoff configuration warning system thinking that it was in the air and hence when the power was advanced with the flaps and slats not selected it did not sound an alarm as it should have done.
The crew had retracted the flaps on the way back to the stand, but they did not re-run the before take off checklist and hence did not re-select the flaps and slats.
...was that they had a fault that effectively disabled their configuration warning so that when the thrust was increased to take off power the computer monitoring the flap positions did not sound an alarm.
The flaps were not re-extended because the check list for take off was not restarted on their second departure from the gate, hence they thought they had already extended the flaps and slats and did not remember retracting them due to all the interruptions from the maintenance engineers while they tried to get the apparent fault (auto thrust calculation not working) fixed.
Exactly right. The aircrew had the aircraft in "flight" mode, causing the first abort, and negating the warning horn for the flaps/slats. Then, the aircrew stated that the flap/slats were in the correct position, without checking the actual location of the flaps/slats on the wings. The aircrew successfully defeated three safety measures and then killed themselves (and their passengers).
The infection of the maintenance computer system has zip-all to do with this crash. It MAY have an impact in future mishaps, and should be investigated to determine what, if anything, needs to be done.
"Um, don't run windows on critical systems on an airplane? (semi-serious)"
I'm not semi-serious! Running Windows for something like this is madness, absolute madness. Normally for critical systems in something like an airplane (i.e. *actually* critical, not "mission critical" like "oh my E-Mail is mission critical"...), they don't even consider Linux reliable enough, and it's FAR more reliable than Windows. There are specialized OSes for this kind of thing, like Green Hills Integrity OS.
"Just reading this it looks as though the safety of the plane depended on a central computer. Surely a plane has a log book that pilots should look at."
RTFA please. There were 2 faults logged the previous day, apparently they wait until 3 faults before not permitting a plane to take off.
In my view though, there were 2 causes for this: 1) Pilot error, since they didn't check the flaps. 2) Gross negligence on McDonald Douglas' part. They can try to blame the maintenance guys if they want. I'd assume some PC got a trojan, then in transferred to a diagnostic "box" they plug into the plane periodicially, then from there to the plane. But when going from a "PC" to a tool or embedded system, one should simply not have to worry about trojans and viruses -- as a tool or embedded system they don't need the flexibility of a full PC so they should not run random executables. The on-plane computer should absolutely never haphazzardly run executables, it should be running a high-reliability real time OS. The diagnostic box should be running something more reliable too, and really the PC should too, but they are at least not flight critical.
It wasn't the plane's computer which had the malware. It was the *airline's* fault logging computer which had the problems and didn't flag up that there were now 3 faults logged.
Nothing to do with the plane's systems. And, I'd imagine that for something as critical as the flaps there would be an independent warning system which would have worked even with a total computer failure - even your car's mechanical systems function if the on-board electronics fail.
As somebody pointed out, read it again. It wasn't the airliner (that is plane's) central computer that was infected, but one of the Airline's. That is the central system the company used to track faults.
I'd be absolutely amazed if a critical flight control or logging system on the actual 'plane was infected. Such systems run bespoke, highly redundant hardware and software systems. General purpose operating systems, like Windows, are singularly unsuited (and unlicensed) for such use. Just about the only place you might find Windows running in a plane is (possibly) on the passenger entertainment systems which will be completely separate from the flight control systems.
@Henry Wertz 1
Your presumed second cause is misplaced. Nothing in the article summary ("RTFA please") suggests that there was any fault (much less trojan) in the _jet's_ on-board computer systems. Rereading carefully, the fault is placed with the _airline's_ central computer system that logs jet incidents:
"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"
The excerpt contains no reference to any possible infection scenario via plug-ins from maintenance diagnostic boxes. (Not that it's impossible--a speculated concern with latest on-board flight control systems entirely dependent upon computer controls--but it's not the infection mechanism described.)
If *you* RTFA, you'll see that the computer that was infected was not on the plane, but was the airline's central maintenance computer. It didn't flag cumulative previous faults logged on the plane. There is no suggestion that the onboard computer was infected, just that the onboard wetware didn't do the pre-flight checks properly.
Very scary, on the second anniversary of the accident a spanair plane going from Las palmas to Madrid (ie the same route in the opposite direction) had an engine explode in flight. Fortunately they managed to get to madrid on one engine.
Maintenance is obviously where a lot of cost cutting has gone on at Spanair, think I'll be paying a few extra euros to fly with someone else in future.
Wasn't Spanair owned by SAS at the time? a few years ago when the Q400 was having lots of gear collapses, all the aircraft with failures (or signs of imminant failures) were owned and maintained by SAS, no other operator's aircraft were affected. IIRC it was eventually found that SAS were not maintaining them properly (though they still junked the Q400 fleet and tried to blame the manufacturer)
"Modern avionics systems have at least three different computer control circuits built into them which are self monitoring - not to mention other safeguards - I find it hard to believe that a groundside computer running windows of all things would be responsible for the *entire* maintenance and troubleshooting of an airlines fleet..."
The aircraft itself certainly wasn't running Windows, but I certainly expect that the maintenance system does. Big fail there, folks.
I *do* hope that Lloyds increases their premiums enough that the PHBs see that getting serious about security (start with chucking Windows) is less expensive than the increased premiums. That's all the PHBs understand, so this is the way to get them to improve both safety and security.
it is clear from the number of SCADA-affecting viruses and trojans (Conficker comes to mind) that a change in tactics is called for, in the form of an international declaration that writing or distributing any malicious software targeted at these systems is classed as information terrorism.
At the very least it would free up more resources to deal with this threat, which has the potential to cause massive loss of life (think power grid shutdowns, etc) and cause untold long term harm to the fabric of society.
I'd also like to see the RIPA Act extended to increase the penalty where the "key" being withheld has to do with the control of botnets, to life without parole.
Its AC, Jim but not as we know it
should be to keep those systems *OFF* the Internet. Period. Oh, it's convenient, yes. Security is inconvenient, *good* security is fscking inconvenient, and so a decision to do something like making SCADA systems accessible from anywhere "because it's convenient" should be shot down because of those three words alone.
A proposal to run such a system on Windows should be chucked out too. Including the proposer, and preferrably from the board-room floor of the main office.
Actually, i'd not be surprised if the claim WERE false. However, by pushing it anyway any government(s) would be able to label malware writers as domestic terrorists. Then perhaps they could really being out the big guns to track people down. I suppose if one is losing the fight, bring on the heat.
"There are specialized OSes for this kind of thing, like Green Hills Integrity OS."
Correct. And the Intel(WindRiver) equivalent. And maybe others. And for some relatively lightweight things, maybe no real OS at all, except maybe a scheduler. But so what, it's not immediately relevant here, once you've read the article.
What the article actually says is that a central maintenance/logging computer - at HQ, on the ground - was infected. So the picture is not quite as bad as you thought, although if people died as a result, it is clearly bad enough, and will hopefully cause some serious thinking in various IT departments. (But I'm not holding my breath, because most IT departments are clueless).
"Modern avionics systems have at least three different computer control circuits built into them which are self monitoring"
Maybe so. But supposing they are all based on identical requirements and all run identical software and there ends up being a common mode failure - a failure in the design or build process, rather than a random component failure?
Or suppose some management genius has said we don't need to test this stuff in the actual target environment, we'll instrument the source and only test that - after all, it's so much quicker and cheaper testing on a PC with a different processor and different compiler. Actually building it with the real tools into the expensive target system and driving that through the relevant sequence of tests takes ages and costs a fortune.
Supposing the compiler (be it Green Hills or something else, maybe something gcc-related, maybe Gnat perhaps?) has an off day and the not-quite-correct compilation results end up on the aircraft, untested? [Ada compilers can be validated but that doesn't guarantee they always produce correct code]. In the current regulatory environment this is not a theoretical possibility, it is a near certainty in the next few years.
"Surely a plane has a log book that pilots should look at."
That would seem very sensible, but actually I'm not sure it happens. There has been a massive move towards getting rid of paper in the cockpit (see, for example, "Electronic Flight Bags", which replace a whole load of paper documents). An article describing Boeing's EFB is at
Page 2 has a picture of it, and one item on the display says "LOGBOOK", and logbooks are also mentioned in the description. So maybe it replaces paper logbooks? Anyone know the current status of paper logbooks on modern commercial aircraft?
It gets worse. Page 8 seems to say their EFB runs both WIndows and a DO178B-certified (look it up) Linux. Go read the PDF (it's a reprint of a magazine article so may not be 100% correct, though it was written by a Boeing employee), see if it makes sense to you. Then contact your MP, or the CAA, or whoever, and tell them how worried you are about the way things appear to be going in the industry.
Air travel looks less and less attractive year by year, and not just because of the ridiculous "security theatre" at the airports.
the trojan-infected computer was in the airline's maintenance centre, not aboard the plane. But some airlines actually do run Windows aboard airplanes; a Lufthansa crewbeing once told me that their in-flight entertainment systems were running on NT 4.0 at the time. Of course, that system is not connected in any way with the flight control logic, which typically runs on a proprietary RTOS.
Time for a beer or three.
Years and years ago, for a thesis I wrote the software for a concept cockpit display which would show certain in-flight hazards... on windows 3.11 (for workgroups). At the time we were "eagerly" awaiting windows 98 as it was supposed to be the greatest thing coming. I did a lot of searching around on the internet at the time on a Mac, using the Lycos (how cool, a spider that doesn't make a web) search engine. This tells you pretty much which time I'm talking about.
Anyways, after we presented all our research, and did a demonstration and simulation of said display, one person in the jury of our dissertation asked me what would be next step for me with the software...
I told him that apart from some kind of strict code review, it might be a good idea to port the software to a stable platform for use in an aircraft. Like Unix. Not Windows.
They all kind of smirked at me, asking me "why? A lot of avionics software is running on Windows right now".
I had no reply to that as my jaw was on the floor. Never felt the same way flying after that one.
You might want to have a closer look at the avionics bay in any major airliner and check the server-racks.
This one was a jury penal consisting of NASA (they have a civil aviation research branch), FAA, MIT, and NTSB mind you.
I've also seen a trend of the management doing anything and everything to avoid making it look like a pilot has screwed up, if at all possible.
As an aircraft maintainer, I see numerous examples of pilot idiocy in small things, and sometimes not so small things, and get reamed out if I write up the crew idiocy in the maintenance logs, rather than something generic and bland about how the fault went away after testing it (for the 47th time, even when the recurring fault is expressly caused by crew doing something stupid...)
The reporting of malware as the cause of a crash seems to be a LARGE stretch to me, considering just how redundant the systems are on these planes.
I haven't worked a MD-82, but still, for it to have passed FAA airframe certification as a commercial aircraft, as well as whatever the EU certifying authority requires, I can't imagine that it's running anything that would have any flavor of Windows on it, nor that there weren't indications and warnings available to them.
More likely, I suspect that there were faults with the warning system, and it was disabled, or just ignored due to repeated false alerts, even when it was reporting critical info at that point.
It wouldn't be the first time such has happened, and likely not the last either.
Helicopter for the obvious attempt at sweeping the whole mess under the carpet and shuffling a couple of easy patsies off to pave the way...
People are quick to blame pilots in such cases - they have forgotten to set the flaps for take off.
But these pilots were on the same plane as the passengers, they would not have intentionally been cavalier about the plane configuration as it affected them as much as the rest of the pax. They would also not just forget that the flaps need to be set - that's a basic flight issue, you just don't forget that planes need high-lift devices for t/o and landing.
But with all that the pilots still failed to set the flaps, they failed to catch this in their pre-take off check lists, the aircraft automation failed to warn the pilots about that, the pre-flight checks failed to identify that the aurual warning has been turned off by maintenance, the company procedures allowed the critical systems in the head office to be infected with malware and so on and so forth. There is never one single reason behind such a catastrophic event and the pilots cannot be blamed for this.
Pilots are human and they behave as humans - they miss things when they become distracted or overloaded or placed in a situation which has deviated from routine for whatever reason. Humans in the cockpit need a backup in the automation and organisational systems. When those systems fail the "naked" human on the front-end will likely fail as well.
Is the standard aircraft avionics (IE the fire by wire stuff) is written to. It's a US standard so US mfg aircraft *must* adhere to it.
It's equivalent has been adopted world wide.
As others have pointed out it would be *very* strange that the actual *embedded* systems were infected. *Why* someone would write something which killed the warning from central maintenance logging the plane had 2 faults already would be a bigger question.
As would *why* the warning hooter was switched off (or disabled, which implies some kind of sabotage).
And of course lastly WTF the pilot and co-pilot didn't notice *anything* wrong with their aircraft handling.
The complaint is that the system that logs pilot comments should have flagged up a problem requiring more extensive investigation after the third note was entered.
So, the pilots tried to take off without flaps etc and no warning sounded. People are saying "What idiot tried to do that?"
We have no idea what the logged errors were. Maybe the previous post-flight comments were along the lines of "the flight check warning klaxon appears to be broken", or "the command to set flaps had to be repeated four times before the system responded correctly", or "the flap position indicator appears to require recalibration"
Hence the importance of the logging system.
I misread the article, and i'm relieved. MD wasn't crazy then 8-).
As for "information terrorism". Phbbbt. I don't like this trend to call everything "terrorism". Terrorism is terrorism and everything else isn't. If whoever wrote these trojans were tracked down they'd be in big big trouble already, probably manslaughter even, but they were not terrorists. Terrorism laws are strict, and it's far too easy to fall into a police state by labelling more and more things terrorism until jaywalking as "terrorism by obstructing flow of commerce". I do think someone should get some competent infosec guys together to track down some of these guys so though, especially the bank trojan ans scareware ones.
We never know why they ran Windows and not Linux but why wasn't the system's check, I am sure they must of had some virus software. Obvious there is many failures within the maintenance of this plane but again I have to agree Linux should be ran on system were lives can be affected.
Windows systems are made to make money that is the bottom line
If some numbnut secures steel bars to a truck with bungee cords instead of ratchet straps, does everyone rail about how incompetent the makers of bungee cords are, for making bungie cords too stretchy? No; that's absurd. It seems that the basic level of coherent thought required to come to that conclusion is sorely lacking in the IT field.
Any safety-critical system needs to be running qnx or a similar hardened rtos. And even running on an insecure os, any such software should watchdog itself to prevent these failures. Windows has plenty of failings, but blaming microsoft for this is just absurd.
Absolutely. Also, assuming for a moment that the story is largely correct, and a malware-infection is to blame for this (something most commenters seem to agree with), I am utterly puzzled by the fanbois of various denominations frothing at the mouth at the chance to bash Windows.
Clearly, blame has to be laid at the door of the coders of the malware, rather than the operating system? This is something I find sorely lacking throughout this discussion. Fact is that all operating systems have bugs, but that doesn't give anybody permission to hack them, or absolve them from the consequences of their actions. The problem is the juvenile mindset of some programmers, who consider it an achievement to wreck systems with scant regard to what they are used for.
Unless programmers develop a sense of morality and ethics, and start to think about the possible consequences of their actions, nothing will change.
Indeed, and if anyone bothers to read the WIndows EULA they would see that WIndows should not be used for mission-critical uses, or words to that effect. If developers are then too f'ng lazy to learn or develop on a mission-critical OS, then they are the ones to be shot. A safety management system for an airline, although not interfacting directly with an aircraft, is still mission critical and should not be sitting on Windows. Full stop / period !
Unless there were some other factors that the article failed to mention, the primary cause of the crash has to be put down to the failure of both captain and first officer to set flaps for takeoff (normally 11 degrees for the MD80, but wind and loading could change this). This should have been done quite early in the taxi to the runway phase AND the setting (amongst others) checked prior to engaging takeoff thrust.
Anyway should some trojan code somehow manage to find its way into the onboard flight management computer, probably the worst thing that would happen is that the flight gets diverted VIA GRA (beacon GRA in Southern Italy would be the most likely for a European flight)
I am an airline pilot, so please let me add something to the debate.
No-one runs laptop-based Maintenance Manuals, as these manuals are what the regulators audit regularly and/or use to prosecute licensed pilots/engineers if things go wrong. If they were electronic, they could be tampered with to cover things up, so they won't allow this.
The story is that this aircraft had a huge history of slat/flap problems that the central maintenance computer should have picked up and alerted the engineer controllers to bring it into the hangar and rectify. It did not and here is where the Trojans/OS issue is brought up.
The end result was that the pilots were trying to keep to schedule (long day, close to limits for duty time, etc) when the flaps would not extend. So they taxied back to the stand (more delay) for the engineer to rectify it. He over-rode some of the protections (and warnings) to get the job done, it appears. In their rush to recover the delay, the pilots forgot to run the flaps for take-off, there was no warning any more, people died.
So yes the ultimate blame lies with the pilots, but then the pilots are usually the last line of defence against systemic problems with the operation - an operation in this case possibly affected by Trojans! The Trojans didn't directly cause the crash, but crashes are usually caused by many little errors/conflicts and they were one part of that.
Just so you can enjoy your next flights, aircraft do not run Windows or similar commercial ("non-critical" OSes)
A 'Trojan' steals stuff with as little interference as possible. Much more likely scenarios are screw-you-up malware or botched security or 'blame something else for our lack of sysadmin competence'. However as we don't know the link between the nature of the faults and the causes of the accident (and at first sight it seems peculiar) it is difficult to 'put the blame on malware'.
Some people here seem to think that critical decisions on aircraft are made by three independent computers taking a majority vote. I understand that principle, I just don't believe that triple modular redundancy (TMR), with or without independent designs, happens in reality at the level of aircraft computer systems, and I wonder where these people get their information.
Two of three voting can and does happen at aircraft sensor level but even that can have problems.
A far more realistic scenario is two identical control systems built with completely identical electronics and with completely identical software (based on completely identical requirements specifications). Now, do you see any fundamental problems with that? Some people might, but as it's lives that are at stake, rather than (say) secure financial transactions, it doesn't get much coverage.
Temporarily ignoring the issue of a common mode fault in requirements or implementation or electronics... These systems self check by simply talking to each other and saying "are you sure?" If only one says "I'm not sure", it is marked as failed and the other one takes over till end of flight. If both say "I'm not sure" then either they change to "limp home safely mode" till end of flight if possible, or there is a bigger problem.
Find me an example of a modern TMR system on a modern commercial aircraft and I'll happily be proved wrong (for that specific case). But you won't generally find TMR on (for example) a FADEC (full authority digital engine control) system. The cost-benefit analysis done by the beancounters says it's too expensive.
But the chances of two things failing independently at the same time are negligible aren't they?
Well, I guess it depends what you mean by negligible, actually. Go read about the AF447 crash a couple of years ago. A commercial aircraft on a transatlantic flight, with three airspeed sensors (Pitot rubes) from two different vendors, as was (still is?) industry standard practice. By design, if there is a disagreement between sensors, the flight control systems trust the majority (*this* is the level at which the two of three redundancy applies, if it applies at all).
On AF447, the two same-design sensors from the same vendor failed at the same time in the same way and produced the same erroneous results. The flight control system trusted the failed sensors and their identically erroneous results. Over two hundred people died as a result.
So these are not hypothetical possibilities, these are real matters of life and death.
Incidentally, there's a nice new nuclear reactor being built at Olkiluoto in Finland. European nuclear regulatory policy for the last ten years or so has been that there must be a control system for routine control of the reactor, and a separate independent one for safety shutdown of the reactor. Sensible enough, right? Well one of the many reasons Olkiluoto is disastrously late and over budget is that the suppliers Areva, despite knowing of this regulatory policy, proposed a single integrated system for control and shutdow, and are stuck in discussions with the regulators on whether that's acceptable or not. You'd have thought the policy would have been a stong hint, wouldn't you.
Incidentally that's the same Areva that has been using Siemens' WinCC SCADA package, the one whose vulnerabilities you may have read about here in the last few weeks (though you may not have noticed the WinCC name). Do you think they might have been proposing WinCC? How would you know? Would you be happy if they were?
Pinto syndrome. It wasn't just for cars, and it hasn't gone away. Spread the word.
Re the reactor - computerised safety shudown?
What ever happened to a big fucking lever on the wall - held up by some latch and safety wire, that when pulled dropped the moderator rods into the core or the piles out of it?
Fuck the remote control and all the bullshit - I am pulling the plug from the wall - cause OFF means OFF, not standby or hibernation or some other fucking crap.
Lots of yelling and bitching about Windows again which is a big yawn, if indeed the airlines "central computer" was actually running windows). But the problem here isn't Windows, it's the folks maintaining the systems who are to blame. Why weren't they ensuring the highest levels of platform hygiene in such a critical system. i.e. patching and ongoing detection.
We run a load of Windows and Unix boxes, these machines are internet facing and so baring their arses to all sorts of break in attempts 24hrs a day.
Over the past five years we've had two machine hijackings, neither of these were on the Windows platform. The machines involved were running Linux and the cause was that the boxes weren't being patched correctly. This is human error, not the fault of the OS.
Yes MS have had a lot to answer for over the past 15 years, but since 2003-2004 they've pulled their finger out and Windows 2003 and 2008 are pretty secure operating systems and as a hoster I should know.
It truly grips my shit when I see some of the ill-informed crap spewed by some of the anti-Windows league. Sorry guys, go get a real job running a real platform that has to weather the endless storms of saboteurs trying to breach your security before opening your mouths with all that crap.
"The airline's central computer which registered technical problems on planes was infected by Trojans"
What? Windows on a airplane? As far as I know, the licence agreement explicitly prohibiths anything like that. In bold letters.
Who is the idiot who runs an airplane with standard PCs running XP?
"It truly grips my shit when I see some of the ill-informed crap spewed by some of the anti-Windows league. Sorry guys, go get a real job running a real platform that has to weather the endless storms of saboteurs trying to breach your security before opening your mouths with all that crap."
I dunno MS Fan Boi - Ill informed? Which BSOD are you not looking at today?
IF MS made secure, sane software, that wasn't just hastily repackaged money making cash cows, same soap, different package, then perhaps there would not be millions of insanely angry and frustrated NON MS fan bois.
10 different versions of the OS, and only the professional version +, has the tools to fix the problems in it, that come with the OS, while the home users get forced to eat shit.
Ubuntu = one standardised OS for all.
MS ARE a corrupt and deceitful company run by a corrupt and deceitful management.
Platform agnostic actually.
We run Windows and Linux, we've had more compromises due to insufficient patching on the Linux environments because our Windows admins make bloody sure those boxes are locked down/patched timeously, Linux folks live in this complacent world of "can't happen here"...sadly it does...and that's the facts of the matter from our experience.
FYI: I haven't had a BSOD on any of our 300 or so Windows boxes for five years now. When we did get them they were usually caused by hardware or third party driver issues.
Personally I run Ubuntu, OSX and Windows in the house so can hardly be considered a 'fanboi' of anything, except my Android phone.
Your whiny utterances about MS and their corruption/deceit just sounds like the noise of a 15 yr old boy living in his basement spending too much time reading slashdot. How about checking out the Oracle/Google spat about Java, now there's a couple of companies that smell strongly of deceit and corruption.
Anyway, stop being a twat and try getting a real job managing and securing 60 racks of internet facing kit then you'll maybe learn a thing or two before criticising.
..is always involved (check it out - the 'holes' can line up). But in this case, the failure of any feasible system to detect that two arguing pilots have tried to take off fully-loaded, without checklists, slats, and flaps, and with the warnings of same curiously disabled, does seem to make the 'Trojan' holes rather minor.
Ask yourself this.
Why was the Airline's computer in a position to *have* a trojan. Surely any computer that is responsible for running systems that can put people's lives at risk should have all possible entry points for a trojan locked down.
What I mean is it should be on a private (ie not accessible to the internet) network and have all all ports and all removable drives disabled or removed. Also any rights to run *anything* apart from the software used for monitoring the other systems should be removed from everyone apart from the administrator. The Administrator account (which should use a non-standard name, not "Administrator") should have a suitably strong password. You also may need a good virus checker (updated regularly from a secure internal server), but get the access restrictions tight enough and the need for a virus checker goes down massively.
Remember than *any* os can be compromised by a trojanm be it Windows, Linux, OSX or something Unix based. They all have flaws, and the threat from those flaws can be reduced massively (if not eliminated) by following the above advice.
First and foremost the pilots didn't set the flaps prior to takeoff. They were not following procedure and they were not paying attention, a bad combination in a cockpit.
Second, the plane had numerous minor mechanicals that included a disabled warning system. None of them would have prevented the plane from flying if the pilots had not committed error number 1 above. Nevertheless the properly functioning systems would have caught the problem and prevented the crash.
Third, the screwed up central computer that should have caught on to the grocery list of minor mechanicals on that plane and grounded it until they were repaired. That brings up an interesting question, who or what is the final arbiter of the plane's airworthiness, usually it is the pilot. Did the crew know the full list of mechanical issues? Did they know the alarm's were disabled? Did they decide to fly anyway? What about the maintenance crew at the airport? Did they have the information or were they solely dependent on what the mainframe told them? At this point it gets to be a mess of reporting, company policy and trojan-riddled computers.
But in the end the pilots forgot to extend the flaps on takeoff which is as fundamental & possibly lethal a mistake as one could make in a cockpit.
It wasn't 'tin wiskers" that caused the Toyota crashes it was driver error/incompetence/stupidity/lack of skills.
It could be the same issue or a mechanical issue with this airplane crash. It's extemely unlikely malware was the true cause of the crash but if people can escape accountability, then they will try any theory.
Can't things like flap actuators etc be checked visually without relying on computers etc?
Actually, maybe that's not a fair question.
If (as TRT ponders) there was an *intermittent* fault with the flaps, an initial visual check may have said "all OK", and yet a later flap-setting request may have failed. In which case why wouldn't the earlier-noted intermittent flap fault be reason to ground the plane immediately?
Lots of questions, not many answers (and a post submitted on Saturday still awaiting moderation?)
The malware infection happened on the central airline server which was logging fault tickets. This is not a mission-critical system.
Sure, after the fact we can find that since this was the third issue on that plane, the plane would have been pulled. That's absolute coincidence though, and has zero relevance to the crash. But no - umpteen idiots jump on the "don't use Windows on a critical system" bandwagon.
The cause of the crash was massive pilot incompetence, pure and simple. It was compounded by an equipment failure which didn't warn them how totally stupid they were being.
Blaming this for a failure where the pilots were massively incompetent is totally missing the point.
Fail for the pilots. Fail for the company who's not maintained their planes properly. And MAJOR FAIL for the "don't use Windows on a critical system" f***ing morons.
How does a watchdog help in general ? Surely a basic watchdog only helps in a failure mode where the computer system is basically unresponsive for some reason (or had you something else in mind)?
Watchdogs in general are for the nice simple brainless failure modes e.g. where a component such as a power supply fails and the watchdog consequently says "better switch the standby into master". Yes you can use the same hardware mechanism to cause a transfer of control if the software decides all is not well, but how does it define "all is not well"?
Watchdogs in general are token gestures, cosmetic offerings, often promoted and accepted by people in positions of authority who don't understand (or prefer not to think about) the actual more troublesome failure modes in modern safety-related computer systems.
Watchdogs are relics of the time when hardware was unreliable and software was simple. Those days are long gone (though hardware does still break), but industry practice hasn't necessarily caught up yet with the level of complexity in many modern software systems in planes, trains, automobiles, etc.
How does a watchdog help in (for example) the failure modes where the system requirements or design or autocoder or compiler or config manager or whatever got something slightly but catastrophically wrong, and nobody noticed till it was too late?
Thanks for the insight on what actually happened.
Can you (or anyone else in the know) expand on the difference between "maintenance manual" (which you say must be paper for anti-tamper reasons) and a "logbook" (which the earlier Boeing reference seems to say can be part of an "electronic flight bag", which can in principle be an ordinary laptop?).
Google seems to think that the term "maintenance manual" is mostly used (by Boeing) for what UK car owners might call the "Haynes manual" of how and when to maintain things - a fixed document, mostly unchanging. The fault and service history is presumably frequently updated and therefore in a different document?
Manual is what the mechanics read when they maintain and fix the thing, logbook is where the pilots log flights and any special events occurred during them.
(Not an airline pilot but a night-rated private one myself.)
Nice to see someone actually understand a bit about these incidents. Indeed it's a grave pilot error to attempt take-off with flaps retracted but that does happen. If the take-off configuration warning isn't operational then there's nothing to tell the pilot that something's wrong until rotation, and by that time it may already be too late (going to fast to stop, too slow to fly with clean wing). The ground roll doesn't "feel" any different.
To anyone who like me normally only reads the most recent page of posts:
The "most recent page of posts" doesn't necessarily contain the most recent posts.
Because of this insanity, you may have missed out on some very relevant info on any multi-page topic e.g. here you may have missed the important posts from Brian Morrison, which El Reg's crappy forum software hides on the first page.
Because of this feature, readers wishing to reply to an "old" post and wanting their contribution to actually get read may prefer to ignore the "reply" button and instead just tack the post on at the end of the thread, quoting where necessary.
I think you're asking for an un-threaded view, so that each post regardless of whether it's a reply to another or a "new" one appears in strict chronological order.
Noted. In the immediate term, while far from ideal, the (Atom) feed for each forum does provide that.
there is no single root cause of the problem. There were MULTIPLE points of failure:
- air service crews
- IT staff
- IT planners (Windows is a real-time system, and as a lowly help desk worker I help support it in my work environment but it shouldn't be in the control tower.)
All of them are equally guilty of killing 174 people.
I like computers - I like it when they work.
I however do not like them in aircraft - as the PRIMARY means of controlling it and staying in the air.
I like HARD mechanical systems - like hydraulics, "open valve, close valve, open valve, close valve, open valve, close valve" like what the retard Homer Simpson enjoys.
I also do not like aircraft that are designed to be 99.9999% efficient - and ONE little thing goes astray and they become like a dart in a pub fight.
An infectable operating system on the aircraft?
Using Microsoft ANYTHING on a fucking aircraft?
Yeah Yeah - lets just reboot and run a 10 scans for spyware and malware and trojans and christmas tree lights and what ever else the fuck runs on Windows.
Lets just hope the wings don't break off at Mach 1.2, for an aircraft that was designed to run at Mach 0.9... as we spear towards the ground from 30,000 feet.
You fuck up the lives of millions of people - Hang them - Straight out.
Tell me, o wise one, was it the Linux OS that was needing patching, or was it perhaps PHP or SQL or some Adobe software or whatever? Not saying the Linux OS never needs patching, that would be silly. But I too watch vulnerabilities and patches for both Linux and Windows. And I see a lot more failures for the Windows OS than I do for the Linux OS.
Oh, right. Privilege escalation meaning you already needed to be a locally authenticated user. And how many other Linux OS exploits were there allowing remote code execution (ie on *your* system) by unauthenticated users?
How many of that class of exploit has Windows had? How many does Windows *still* get?
How many authenticated users would there be on a typical Web-facing system of the kind you were talking about, o wise one? If users aren't authenticated to log on locally, how many remotely-accesible exposures are there in the Linux OS (excluding PHP, SQL, etc).
Sorry, Bill loses, on web-facing systems and elsewhere, on security and on reliability and elsewhere. Not my words, ask the folks who run real Internet-facing systems, as polled by Netcraft.
http://news.netcraft.com/archives/2010/08/11/most-reliable-hosting-company-sites-in-july-2010.html (top ten: all running *nix/BSD apart from one still running Windows Server 2003 at number 5)
http://news.netcraft.com/archives/2010/08/11/august-2010-web-server-survey-4.html (Apache with twice as many servers as Microsoft).
Ahem. Someone is lying.
From my now dusty memory of commercial avionics there are 18 fiery hoops to be leapt through to make flight critical software. None of them begin with 'insert tour off your windows/linux/solaris dvd into a dvd drive.
It is not likely to be true that the as intended design was to override needed maintenance. Lots of engineers earn their pay calculating the impact of maintenance and maint intervals on the probability of Aunt Millie getting killed in a crash.
Those calcualtions assume warning sytems, pre flight checks of critical components.
That are checked on every takeoff. They are commanded up. And down. Except in Spain. Now someone wants to blame the erp system at least until they can make their getaway.
Biting the hand that feeds IT © 1998–2019