747's are big flying Unix hosts | Hacker News Reader

747's are big flying Unix hosts

plus.google.com

141 pointsferrouswheel28 comments

Here's a nice shot of a Lufthansa in-flight entertainment system crashing and rebooting: http://www.flickr.com/photos/tims/3062736303/in/photostream/

It's doing a TFTP download of an image from a local server (all using martian IP addresses) and booting WinCE.

I find the OP story a bit hard to believe though. When I lived in Toulouse I talked to folks at Airbus about telemetry and I'm near certain that there was plenty of downlinking of data possible from the Trent 900 engines from the QUICK Technology for Engine Health Management and GE has for years provided real-time engine data download via ACARS.

What would be worrying is a connection on the same network between entertainment and controls of any sort. I'd like to see a better sourced story on this, though.

However, back when there was a flap about the Dreamliner networking the FAA gave a long response: http://cryptome.info/faa010208.htm

In it there's the following argument from Airbus:

"AIRBUS Comment (b): Airbus stated that in the sentence ``The design shall prevent all inadvertent or malicious changes to, and all adverse impacts * * *'', the wording ``shall prevent ALL'' can be interpreted as a zero allowance. According to the commenter, demonstration of compliance with such a requirement during the entire life cycle of the aircraft is quite impossible because security threats evolve very rapidly. The only possible solution to such a requirement would be to physically segregate the Passenger Information and Entertainment Domain from the other domains. This would mean, for example, no shared resources like SATCOM (satellite communications), and no network connections. Airbus maintained that such a solution is not technically and operationally viable, saying that a minimum of communications is always necessary."

That appears to allow a network connection between flight and passenger systems. Frankly, I find that idea terrifying.

Rolls-Royce has a unique engine monitoring program - generally the airline leases the engines and they are owned, monitored and serviced by RR.

When I worked on the ground based GRID computing system for their initial system 10years ago the 4 engines on a 747 logged about 1Gb of data locally during a 10hr flight onto hard drives that were removed and copied locally on landing. The grid system was so that all the data didn't need to be shipped back to HQ unless it was needed - all the queries could be farmed out to all the places the engine had landed over it's life.

Now MUCH more data is captured and the engines have their own dedicated satelite link back to RR where there is a vast data center that can pull up second-second measurements of every parameter of an engine for it's 20-25 year life.

There is also a complex system that automatically spots any abnormalities - not just out of 'normal' spec, but looking at the history of that particular engine and other engines on that particular route/flight configuration - but I didn't work on that!

Do the engines downlink that telemetry in real-time, or is it still a function that occurs at the airport?

They downlink enough live that the monitoring center knows of a problem in time to have a service/inspection booked before the crew even notice anything.

I don't know how much extra they store on board.

This reminds me - not long ago I was on a trans-Atlantic flight and I was mindlessly poking around a touchscreeen of an in-flight entertainment system. A right-click menu poped up, a typical browser one. It had a SaveAs option, so I went on, looked around and the file system had typical *nix structure with /usr, /root, etc. Then they started the take-off prep and rebooted the while thing. So it gave me a minute or so. Once it was back up, I killed an hour trying to reproduce the menu popup, but couldn't.

So next time you find yourselves on the plane, bored - keep this in mind, try and reproduce :)

The user systems are usually very much different than the flight control systems. In the plane I worked on, all flight control systems ran on VxWorks and hardly used networking for anything. The majority of the communication between systems happened on a 1553 bus (http://en.wikipedia.org/wiki/MIL-STD-1553) which had pre-defined messages on a redundant bus (as shown in the wiki article).

The amount of oversight a avionics system must go through when writing code for it is unfathomable for a modern software engineer. I know it sounds "cool" to hack into an avionics system from the in flight entertainment, but the likelihood of that being possible is somewhere around zero if the plane got approved by the FAA to be in the air.

I was astonished when so many people on the HN thread discussing the viruses on "the Predator system" couldn't distinguish between flight critical software and everything else. Lots of comments along the lines of "what do they expect, letting Windows fly an airplane" and so on. There seems to be similiar confusion here.

Can you explain further? I am pretty sure the Predator drones do not feature in-flight entertainment, so unlike the plane + entertainment system in this article, the infected computer systems must be related to flight operations.

The infected computer systems were ground side, not the aircraft themselves.

Exactly. This is sort of a stretch of a metaphor here, but consider the predator having a server system that provides an API. The ground station is just a client putting out requests to that API. The ground station computers had the virus. That whole series of articles in the press was kind of stupid. If I use github, have a virus on my computer, it doesn't mean that github has a virus on their computers.

But that virus might steal the password for my github account. Or even delete one of my repositories.

And by deleting a repository I mean firing a Hellfire missile.

Yes, in this case though the virus was apparently a keylogger on a system that isn't (supposed to be) connected to the internet. So while it may have gathered information on what the operators typed in, it wasn't getting any magic passwords. Most of that (if done properly) would involve some secret keys that operators don't directly access.

With the Predator, it was more or less a flight- vs ground-software distinction, as my sibling commenter says. But even with the inflight entertainment system, where everything's in flight, there are separate computer systems (meaning, CPU's, software loads, operating systems, power busses, communications networks, air supplies for cooling - the whole nine yards) for the flight critical software (flight-critical meaning that an error or malfunction could cause the plane to be unable to fly) and the in-flight entertainment center or any other system of lesser criticality.

Even with UAV's, it's not just a flight-vs-ground distinction either. For example, any drone that's being used for reconnaissance is going to keep a big imagery database on board, simply because there's not enough satellite bandwidth to stream lots of data back to the ground while it's on the air. That server could be running Unix or Windows or whatever, and probably is, because the UAV designers will have gone to a lot of trouble to make sure it can't interfere with any flight critical software.

So does it matter if it was a ground control computer that was infected and took over/blocked control of the drone - rather than an attack on the onboard system that did the same?

It's an interesting question. In my opinion, it's probably more serious to have the ground station compromised than the onboard software. The Predator is just a drone and the onboard software is going to be pretty dumb, so even if an attacker were able to take it over completely, it couldn't actually do much besides crash the plane or launch its missiles. (That sounds serious, but it really isn't. If you're using a drone in the first place, it's safe to assume it's somewhere where you don't have many friendly forces to begin with. That might change if the US keeps turning into a police state, but that's another discussion.)

If an attacker compromises the ground station software, on the other hand, he gets to try to snoop on whatever intelligence information comes down from the network that computer is on. Things like lists of likely targets for the operator to watch for, or anticipated positions of friendly units in the area, and so on. You get the idea.

Previously [1] discussed.

[1] - http://news.ycombinator.com/item?id=3037906

https://www.infosecisland.com/blogview/16696-FACT-CHECK-SCAD... https://infosecisland.com/blogview/16770-SCADA-Air-Gaps-Do-N...

I tried to submit this and the followup article a while ago, but the domain was blacklisted by pg so the stories get autokilled.

I've actually seen Linux kernel panics on a lot of video systems on planes too. I suspect there are a lot of *nix os's on various parts of the planes.

This probably shows how much I travel though :-P

As a pedantic observation, it is far more likely you observed the normal Linux boot-up process, which sometimes hangs due to a sub-process waiting on a network event or fsck.

It would surprise me if such a device had a kernel panic.

Me too, considering how hard it is to trigger a kernel panic. The first and only times I ever saw them were when I was building my own kernel modules.

No. It had the words "Kernel Panic" on the screen for a while and then it booted.

It's not inconceivable that the in-flight entertainment system would use a bunch of specialised hardware with "homemade" drivers, all capable of panicing the kernel.

When I lived with a former Airbus engineer, he explained that these systems were running 80486 processors due to their relability (in the sense that nothing unexplainable would ever happen). That being said, he also told stories of how the complexity caused software bugs to manifest themselves that often disappeared before their causes were determined.

I am always horrified imagining that planes run on Windows. Very glad to learn that this is a wrong assumption.

No only nuclear submarines

And Ticonderoga-class warships...

http://en.wikipedia.org/wiki/USS_Yorktown_(CG-48)

Connecting SCADA to a typical IP network is all the rage these days.

Better hope your SCADA engineers don't believe in security by obscurity or design by "That'll never happen".

Bruce Schneier's post today, http://www.schneier.com/blog/archives/2011/11/remotely_openi... , is about SCADA networked prisons being on the Internet. Sometimes linked by guards wanting to browse at work, sometimes by the contractors that set it up for monitoring.

Reply on news.ycombinator.com