Software Vulnerabilities in the Boeing 787

Boeing left its software unprotected, and researchers have analyzed it for vulnerabilities:

At the Black Hat security conference today in Las Vegas, Santamarta, a researcher for security firm IOActive, plans to present his findings, including the details of multiple serious security flaws in the code for a component of the 787 known as a Crew Information Service/Maintenance System. The CIS/MS is responsible for applications like maintenance systems and the so-called electronic flight bag, a collection of navigation documents and manuals used by pilots. Santamarta says he found a slew of memory corruption vulnerabilities in that CIS/MS, and he claims that a hacker could use those flaws as a foothold inside a restricted part of a plane’s network. An attacker could potentially pivot, Santamarta says, from the in-flight entertainment system to the CIS/MS to send commands to far more sensitive components that control the plane’s safety-critical systems, including its engine, brakes, and sensors. Boeing maintains that other security barriers in the 787’s network architecture would make that progression impossible.

Santamarta admits that he doesn’t have enough visibility into the 787’s internals to know if those security barriers are circumventable. But he says his research nonetheless represents a significant step toward showing the possibility of an actual plane-hacking technique. “We don’t have a 787 to test, so we can’t assess the impact,” Santamarta says. “We’re not saying it’s doomsday, or that we can take a plane down. But we can say: This shouldn’t happen.”

Boeing denies that there’s any problem:

In a statement, Boeing said it had investigated IOActive’s claims and concluded that they don’t represent any real threat of a cyberattack. “IOActive’s scenarios cannot affect any critical or essential airplane system and do not describe a way for remote attackers to access important 787 systems like the avionics system,” the company’s statement reads. “IOActive reviewed only one part of the 787 network using rudimentary tools, and had no access to the larger system or working environments. IOActive chose to ignore our verified results and limitations in its research, and instead made provocative statements as if they had access to and analyzed the working system. While we appreciate responsible engagement from independent cybersecurity researchers, we’re disappointed in IOActive’s irresponsible presentation.”

This being Black Hat and Las Vegas, I’ll say it this way: I would bet money that Boeing is wrong. I don’t have an opinion about whether or not it’s lying.

EDITED TO ADD (9/12): IOActive‘s paper has technical details. There is some belief that these are the same vulnerabilities that DHS discovered in 2016. And Boeing claims the attacks don’t work.

Posted on August 16, 2019 at 6:12 AM32 Comments


Simon Caldow August 16, 2019 7:41 AM

Reading between the lines, this would infer that FAA/EASA certification requires no penetration testing of an aircrafts systems before approving a new type. That sounds like “straight to the scene of the accident” to me…

Brent Longborough August 16, 2019 8:01 AM

“Boeing maintains that other security barriers in the 787’s network architecture would make that progression impossible.”

So Boeing didn’t see any benefit from “defence in depth”? Hmm…

Sam August 16, 2019 8:45 AM

@Brent – what? Boeing is basically relying on their “defense in depth”, its more like IOActive is discounting that aspect.

Dave August 16, 2019 9:01 AM

But Boeing counters that it has both “additional protection mechanisms” in the CIS/MS that would prevent its bugs from being exploited from the ODN, and another hardware device between the semi-sensitive IDN—where the CIS/MS is located—and the highly sensitive CDN. That second barrier, the company argues, allows only data to pass from one part of the network to the other, rather than the executable commands that would be necessary to affect the plane’s critical systems.

Oh, that sounds fine then. Not like we have seen this before.

Brad August 16, 2019 9:37 AM

That second barrier, the company argues, allows only data to pass from one part of the network to the other, rather than the executable commands that would be necessary to affect the plane’s critical systems.

See, last time I commented on an aviation vulnerability some other commenter retorted with the aircraft manufacturer’s claim that it was “impossible” to move laterally because certain communications to sensitive avionics components were “one way”. You “can’t” send commands only retrieve data. I always thought that was BS, and here we have another example a potentially dubious claim. Now they’re claiming well there’s two way communication sure, but it’s only “data”. Yeah, there have never been any problems in the history of computing where data ended up being interpreted as commands. Move along, nothing to see here!

Bob August 16, 2019 9:51 AM

@Sam I think it’s more of a yes and no. A “proper” response if they were pursuing defense in depth would be more like: “while legitimate concerns about the security of individual components have been brought up we’re happy to announce that our efforts to ensure security in every level of the software stack means that these concerns should be non-exploitable. However, we will be working with those that have raised these concerns in order to ensure that every component of our system is as secure as possible.”

Instead what they said implies more so a: “it should be secure enough, so we don’t need to improve.” They didn’t exactly say that, but they don’t seem terribly eager to work with these people to improve their system.

Alan August 16, 2019 10:22 AM

I really wish Boeing would just let them test against an actual 787 instead of immediately dismissing it. In the long run, it would work out way better for them, and even the short term PR would probably be a better look.

Magnus Lunde August 16, 2019 11:15 AM

I can imagine a hardware barrier that should work:

If the actual components are wired in two distinct and disjoint nets. So pneumatic pumps, electrical motors and so on are ONLY wired directly to the physical controls in the cockpit, while sensors ONLY feed data through something akin to a mini-jack, which is physically branched to connect both to the cockpit and to a plug in the board that connects to this vulnerable network.

However, I can still see some things going wrong.

For instance, this would require auto pilot, collision detection and so on to be ENTIRELY DISCONNECTED, physically, from the vulnerable network.

Are they? If so, can’t Boing just say so?

Indeed, what else would the vulnerable network need sensor data for, if not to run collision detection and so on?

Vault7 showed that CIA already has software to crash cars for assassinations, so this is not a far stretch.

Also, I note that the flight crew relies on emergency manuals for plane safety. Simply deleting or altering them, or even just crashing the system for accessing them, could be devastating.

If Boing wanted to seem trustworthy they should welcome the analysis and be eager to get to the bottom of this, instead of acting butthurt that anyone would point out a fault, which IS a fault no matter how they frame it.

Alejandro August 16, 2019 11:19 AM

Apparently Boeing’s plan is to duck, dodge and weave in order to get out of this. Personally, I don’t think that will work. Mainly, because their plan is so transparent.

They need to scrap this model entirely due to it’s design flaws, start all over again from scratch and make full restitution.

The sooner the better.

The more they fool around, the worse it’s going to be, for all of us.

Rob August 16, 2019 12:41 PM

Every once in a while I see one of these stories where the scare quote involves somebody getting out of the passenger wi-fi and into the flight systems, and I wonder how the hell this can ever be possible. I have a guest AP on my home network prevented by firewall rules from accessing any home system, but my home is not responsible for safely flinging a bunch of people through the sky in a metal can. If it were, there is no way those two concerns would share any of the same hardware.

If the network they charge us exorbitant amounts for to check our email in-flight is not strictly airgapped from the flight systems, and moreover absolutely required by the FAA to be so, I really want to know why.

jon August 16, 2019 2:51 PM

After all the deaths caused by recent Boeing software quality problems (Max 8) you’d think their PR team would understand that humility would get them a lot farther than defensiveness.

Clive Robinson August 16, 2019 3:27 PM

@ Dave,

Oh, that sounds fine then. Not like we have seen this before.

Sometimes it amazes me just how many people think “data diodes” and similar are just one way…

They would be surprised to learn how many are not truly one way for “reliability issues”…

Whilst it is fairly easy to make a true one way trafic system, the big problem is CDMA means problems the more the destination network is utilized.

Old_Fogie_Late_Bloomer August 16, 2019 4:01 PM

It seems to me that Santamarta may have independently discovered some of the vulnerabilities that the Department of Homeland Security uncovered back in 2016:

The following sounds like it could definitely be related to the CIS/MS:

The aircraft that DHS is using for its tests is a legacy Boeing 757 commercial plane purchased by the S&T branch. After his speech at the CyberSat Summit, Hickey told Avionics sister publication Defense Daily that the testing is with the aircraft on the ground at the airport in Atlantic City, New Jersey. The initial response from experts was, “’We’ve known that for years,’” and, “It’s not a big deal,” Hickey said.

But in March 2017, at a technical exchange meeting, he said seven airline pilot captains from American Airlines and Delta Air Lines in the room had no clue.

“All seven of them broke their jaw hitting the table when they said, ‘You guys have known about this for years and haven’t bothered to let us know because we depend on this stuff to be absolutely the bible,’” Hickey said.

Clive Robinson August 16, 2019 4:04 PM

@ Bruce,

I don’t have an opinion about whether or not it’s lying.

When I was a lot younger, I was taught that there were two types of lying, those where you said things you knew were not true to gain some kind of advantage. And the other was where you chose to withhold the truth to gain some kind of advantage. The latter type is quite often called “A lie of Omission”.

I now know there is a third type of lying, that is where you knowingly distort the truth you tell to change another persons Point Of View in some manner. Both this type of lying and lies of omission are now so frequently used as tools of PR, it would be hard not to conclude, that such people have in effect convinced themselves they are not lying, even though others think they are.

However what these PR and other people using these methods of lying, actually think they are doing when the commit such lies, is unknown to me, but I guess it helps them sleep at night… Even though Boeing’s poor software managment has already been the root cause of at least two aircraft crashes with multiple fatalities.

So based on what I’ve been taught is lying I would say Boeing’s managment and PR personnel are most certainly not telling the truth as most would expect.

In fact I suspect that Boeing have not bothered to investigate IOActive’s claims in anything like the depth required to make the assertions Boeing have so far made. In part, because it’s now a matter of recorded fact, that not just Boeing’s software managment and testing is deficient, we now know their security practices in that part of the company have been highly deficient as well.

So from my perspective anything Boeing senior managment or their PR spokespersons say is likely to be at best suspect, and that the safest course of action is to assume that they are if not actually lying certainly not telling the truth. Which in effect amounts to the same thing if you are putting your life on the line by stepping into one of their products.

Jeffrey Radice August 16, 2019 4:33 PM

Boeing’s professional spin doctors use sleight of hand, but the core issue remains. The “memory corruption vulnerabilities” in one system of software are highly indicative of similar vulnerabilities throughout the codebase. That these were found so easily is rather suggestive that they are not testing for these systematically (or likely other similar types of vulns): either manually, in code reviews, or with any number of SAST tools. Don’t let the deflection fool you. This has very little to do with “provocative statements” and everything to do with sloppy software development practices that put human lives at stake.

Clive Robinson August 16, 2019 5:00 PM

@ Rob,

If the network they charge us exorbitant amounts for to check our email in-flight is not strictly airgapped from the flight systems, and moreover absolutely required by the FAA to be so, I really want to know why.

The simple answer is it’s to do with shared communications into the satellite systems, which all these systems (including engine managment, navigation and stewards system) need access to…

So even if they somehow used two satellite uplinks the systems would still come together either at the satellite or on the satellite down link etc…

JasonD August 16, 2019 9:41 PM

Boeing claims they used a real 787 and tried the attacks this researcher suggested. None were successful.–/5452768/

After working with IOActive to understand its research, Boeing and its partners tested their findings in integrated environments, both in labs and on an airplane. Our extensive testing confirmed that existing defenses in the broader 787 network prevent the scenarios claimed.

Nothing to see here, assuming Boeing can be trusted.

Gunter Königsmann August 17, 2019 12:42 AM

Don’t know what would scare me more: If they believed that they use the “secure” compiler flags and have passed an audit, ergo cannot have any security problems. If they believed that a minimal approach (“for every scenario we thought of we have exactly one mitigation”) is enough. Which would mean that an aviation firm doesn’t believe in redundancies. Or of they lied to their customers basically saying “we have no idea abort security. Which means we don’t see a problem and you are safe to fly”. After all they did lie to the pilots recently causing planes to crash.

On the other hand they might be scared enough to have more airplanes grounded that that causes them to say scary things.

Another Mouse August 17, 2019 5:49 AM

I don’t know the 787 at all but older A/C quite well. There a jump from the cabin to the avionics is just impossible,as all is based on one direction Arinc 429 busses. This is a kind of serial bus with just 2 wires, ground and data (unidirectional). So penetrating into the avionics needs some hw changes at least.

I hope Boeing didnt replace all of this with ethernet…

VinnyG August 17, 2019 8:26 AM

@Brad re: “It’s only data” In my limited experience, the main purpose of collecting (reading) data in a control-oriented system is to evaluate it to condition action commands…

MarkH August 17, 2019 8:37 AM

Clive mentioned CDMA.

From my very limited knowledge, although ARINC networks used on airliners have some physical commonality with Ethernet, the management of communication is radically different.

Each network-connected system effectively has its own “time slot” budgeted for a fixed amount of data … so more like TDM than CDMA.

It would be madness to run a mission-critical realtime network by CDMA.

Where ordinary Ethernet is used for non-critical things (like passenger entertainment), the interface is made via a box functioning rather like a router. Because the PES equipment is impossible to validate for network safety, the design of the box must be shown not to harm the ARINC network, regardless of what happens on the “wild west” Ethernet side.

From any reader with hands-on experience with modern airliners, I welcome corrections of what I’m getting wrong.

Clive Robinson August 17, 2019 1:00 PM

@ MarkH,

From my very limited knowledge, although ARINC networks used on airliners have some physical commonality with Ethernet

If you are refering to ARINC 429 that’s been around since the 1970’s, it is a low capacity differential signaling serial bus with a clock rate below 100kHz and 32bit frame format.

However there are other protocols like the similar MIL-STD-1553 which originated at aproximately the same time. Whilst still in use on some satellite systems this standard is being depreciated for several reasons.

Both of these use unidirectional serial busses that use Time division multiplexing (TDM) under a master slave protocol where the controler arbitrates bus usage. TDM has some significant problems especially when it comes to response time. If you are a transducer that has just been read by the controler when your input undergoes a change of state, this can not be communicated untill the controler next reads the transducer that might be many time slots away, with the length of each time slot not fixed but dependent on what the controler is doing. It does not take much math to realise that as far as response is concerned with more than just a handfull of transducers you would actually be better off with a CSMA/CD system with random or even prioratized back off in most cases.

Also as things go the cost of these busses is inordinately high, the cable alone is regarded as a speciality item and it’s not exactly light and wiring things up in a loop fashion can end up using more cable than star fashion. As for the connectors, well you could get a quite large box of ethanet plugs for the price of just one of these nearl a half century old serial busses, and they again are heavyer than wanted these days.

Boeing however starting with the 777 developed it’s own propriatary standard which became, ARINC 629. It provides, only a moderatly increased performance over the two near half century old protocols, with an increased data speed up to around 2 Mbit/s and allows a maximum of 120 connections. Importantly though it has no master bus controler and uses very expensive propriatary hardware etc, which means few other aircraft manufactures want to know about it as it is seen as “Too little to late and for a kings ransom”. Also the lack of a defined bus master seriously calls into qiestion it’s reliability and security.

However if you look at Consumer Of The Shelf (COTS) networking it’s been around for about a half centuey as well but due to take-up is a fraction of the price for tens of thousands of times the bandwidth, very small delay time and a MAC address range that would be hard to use more than a fraction of even on a modern state of the art aircraft. Thus if you want to reduce price the various Ethernet standards look good, and not all are half duplex CSMA/CD or CDMA systems (full duplex between two nodes does not require either Multiple Access method for instance and gives higher security and stability).

AirBus for instance were never going to using either of those near half century old busses for their fly by wire systems as they have very limited capacity, slow response and limited data transfer capability as well as being eye wateringly expensive. And as for going down the Boeing route… I think most will realise that would have been a non starter even without it’s severe limitations and extraordinary cost.

What AirBus did was develop and patent Avionics Full-Duplex Switched Ethernet (AFDX), which is based on IEEE 802.3 working group standards which define the physical layer and data link layer’s media access control (MAC) of wired Ethernet, which includes CSMA/CD for multiple access.

However Boeing realising it was getting left in the dust, developed it’s own similar system “EDE” to implement a deterministic Ethernet over the standerdized core (ARINC 664 Part 7) of AirBus’s AFDX. It was first introduced on the Boeing 787 Dreamliner… However it is known to be significantly deficient in certain important areas with respect to the AirBus AFDX. It lacks the level of QoS which can prevent quite a number of securiry issues and there are I understand a number of questions over EDE’s “Real Time” abilities. Then there is the still undisclosed failings the DHS found with the system…

AirBus however were well aware of the security and other potential failures of Ethernet and went to some considerable lengths to remove them in AFDX. As mentioned they use full duplex Ethernet, which removes the possibility of (CSMA/CD and CDMA) transmission collisions. They also studied other well tested communications networks including asynchronous transfer mode (ATM) which they took several features from to eliminate several IEEE 802.3 shortcomings. One of which was the “token bucket” algorithm which on first reading appears to be designed to discard data packets. However whilst it can do this it can also be used to do “traffic shaping” which is used to prevent data packets being discarded by traffic management functions else where in a network. ATM was actually designed to bring together the benifits of “switched circuit” and “switched packet” networks thus AirBus by adding certain key features from ATM to those existing in Ethernet, and aplying certain configuration constraints, AirBus produced a high reliablity full-duplex and importantly deterministic network that not only guarantees bandwidth thus quality of service (QoS) it also gives well defined latency for Real Time activities. The resulting AirBus AFDX network can prioritize all critical traffic so that within set parameters all data packets have quaranteed delivery, jitter and latency. Thus designing high reliability and availability systems around AFDX is not just possible it is compared to other systems fairly simple.





RealFakeNews August 17, 2019 5:01 PM

As with the internet, why on earth is the in-flight entertainment system connected to critical aircraft systems???

As for Boeing’s response, what did anyone expect?

Just look at how they handled the 737 MAX. So far the only change they made is to its name, in the hope passengers don’t realize what they’re flying on.

Ari Trachtenberg August 17, 2019 11:40 PM

I don’t see that Boeing had a choice but to reply the way they did. Any modifications to their system would take years to go through proper review before they could be implemented and may effectively bankrupt the company.

Our commercial airline system are engineered to deal with natural or accidental
problems … dynamic malicious problems of the type presented by software
vulnerabilities require a reaction that is a couple orders of magnitude faster.

Clive Robinson August 18, 2019 10:30 AM

@ All,

With regards to if Boeing are “lying” or not, I pointed out above, that one aspect was PR / Marketing people bending the truth any which way they can including breaking it into little bits they can then use “Perception Modification” on, to in effect “put squirrels in peoples heads”…

I know that “Perception Modification” might sound a little “CIA MKULTRA” to people, but it realy goes on and is an active area of research. Think back to reports of the likes of Facebook paying psychologists to in effect make Social Media “more adictive”. Or taken to other levels what the likes of Cambridge Analytica sold as a service to despots, tyrants and even US politicians. Even MSM like the New York Times gets involved with doing “perception modification” for the likes of Pay-Pal (there is actually a link between the two organisations). Back a few years ago UK newspaper The Guardian was doing the same for Google. Likewise The Telegraph has done it for several corporates, to try and stay in business. As for the “Murdoch Empire” the list whilst not endless feels like it is.

Thus perhaps unsurprisingly I’m not the only person to notice this trend, but don’t be surprised to not hear about it from the MSM (Yes they do “Lies of Ommision” all the time to make stories, it’s not just Bloomberg 😉 Infact in one “Perception Modification” case, –close to many of this blog readers hearts– it’s been given the name of “Openwashing” where what are actually “Proprietary closed source” companies pretend in many ways for publicity to be “Open” in some way[1].

Two examples that has become obvious to quite a few in the tech sector, are firstly the Microsoft take over of GitHub… That as a result has now killed off many Open Source project developments using the excuse of “US Export Regulations”. Noticable to some is that “Personal Privacy in Communications” projects have been hit harder… As Microsoft are well known collaborators with the US IC and LEO entities (Skype etc), some are asking how long before Microsoft start using various techniques to start puting backdoor code[2] in peoples projects?

Secondly is how some organisations are “helping” Open Source Projects by “giving of their time”. Whilst this might be innocent behaviour by some, others are apparently “landmining” genuine Open Source projects. That is as a policy they slip in “patent covered” technology and slowly make it sufficiently prominent to become effectively vital to the project. Then the Lawyers letters go out demanding “Dane Gelt” in vast quantities.

It’s one of the reasons I’ve started shifting away from all but one or two Linux Distros, or have stopped at earlier unencumbered versions. It’s also why some of the BSD’s are becoming more prominent in stuff I do[3].

It realy does not matter who first noted that “Eternal Vigilance” was a requirment to maintain what few “Freedoms/Rights” we have. Things have become two pronged. Whilst we are fighting Governments on Rights and Freedoms, we also need to remember that large Corporates especially in the Tech sector want to decimate any freedoms or rights to not just commoditize people to other Corporates, but also to turn us by various means foul and disreputable into enforced servitude and “Rent Paying” at every level of our lives.


[2] Don’t think “code signing” will stop this, after all where do people get your key from? Yup from Github or another web site. So you get told what ever Microsoft want you to be told based on your IP address or other information. So a more cautious person would go to the developers web site to get the key… But we know the NSA had developed tricks where by their “network packets” would arive before the real packets (just play with BGP and send the legitimate traffic via China, Russia or both). As the network protocols say the first packet is the right packet, you end up with the NSA bad packet instead. Thus that developers web site is now nolonger a safe place to get the key. It’s one of the reasons I prefered CD/DVD ROM’s on the front cover of magazines, if they got the wrong signed packages and keys there was a much greater chance you would hear about it. But in many cases those compiling the CD/DVD ROMs actualy were in contact with the developers via other channels as well.

[3] For those doing “custom hardware” Linux is now not your friend for doing embedded OS etc. You will actually find that BSD is now easier to work with unless you want a fancy UI, and it’s licencing is more amenable than those used by Linux…

Petre Peter August 19, 2019 10:43 AM

Flying is the safest way to travel; even safer than trains. Boeing knows this but it seems they are reluctant to compete on safety features for a reason.

A90210 August 19, 2019 4:40 PM Weekend WSJ August 17-18

“The Four-Second Catastrophe: How Boeing Doomed the 737 MAX

At the root of the company’s miscalculation was a flawed assumption that pilots could handle any malfunction

Almost as soon as the wheels of Ethiopian Airlines Flight 302 spun free from the runway March 10, the instruments in front of Capt. Yared Getachew went haywire.

The digital displays for altitude, airspeed and other basic information showed dramatically different readings from those in front of his co-pilot. The controls in Capt. Getachew’s hands started shaking to warn him the plane was climbing too steeply and was in imminent danger of falling from the sky.

Soon, a cascade of warning tones and colored lights and mechanical voices filled the cockpit. The pilots spoke in clipped bursts.

“Command!” Capt. Getachew called out twice, trying to activate the autopilot. Twice he got a warning horn.

Another powerful automated flight-control system called MCAS abruptly pushed down the jet’s nose. A computerized voice blared: “Don’t sink! Don’t sink!”

The pilots wrestled with the controls, desperate to raise the nose of their Boeing 737 MAX. Three times Capt. Getachew instructed co-pilot Ahmed Nur Mohammed, “Pull up!”

At the same time, a loud clacking warned the preoccupied pilots that the plane was flying too fast.

Four minutes into the flight, the pilots finally touched on the source of their problems, simultaneously calling out “Left alpha vane!”…”

Jayson September 6, 2019 11:13 AM


This is nothing more than another false positive and associated poor optics. A false positive based on assumptions made due to ignorance of how aeroplane systems are designed, integrated, tested, and by drawing incorrect parallels to consumer level COTS to fill the gaps of knowledge.

While it is true some code was found on the Internet, that is more of a commercial issue, since competitors will now have an insight into the closed and proprietary nature of a portion of the aircraft system functions.

No one is going to hack or compromise any of the critical systems of an airplane – the IFE is not critical, so no one cares if it gets hacked or not.

Further information in this ~15 minute read.

Sam July 7, 2021 9:38 PM

I used to work at Boeing on the 7E7. Management there is great at talking in reassuring tones at a very high level, but they’re clueless about the complexity of the technology they’re deploying.

In the countless layers of bureaucracy that make up Boeing, there are competent engineers and incompetent engineers. Management, though, generally has no idea how engineering works, so they can’t distinguish between the two, or describe how anything actually works.

I wouldn’t take a clueless statement from Boeing management as evidence that there’s an engineering flaw (or isn’t), because that’s just what you get from Boeing management, at any level, whether the design is well-engineered or not.

As Philip J. Fry would say, “Don’t you worry about memory corruption vulnerabilities. Let our engineers worry about blank.”

Leave a comment


Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via

Sidebar photo of Bruce Schneier by Joe MacInnis.