"Hack" has a variety of definitions, from reading private data off a non-critical system, to disrupting or confusing an avionics mode, to taking control of the plane and locking out pilots. This complicates the discussion of how likely planes are to be "hacked".
In general, the recent consensus seems to be that under some definitions of "hack", this certainly is possible, even without insider knowledge. There's some reports of successful hacks out there, though since the details are confidential it's hard to tell what researchers accomplished or their method of attack. Both researchers and plane manufacturers seem to agree that taking control of an airplane for more than a few seconds would be extremely difficult, but not impossible, and that's even with insider knowledge or prolonged access the plane.
Current policy guidance by the FAA can be found in PS-AIR-21.16-02. I've heard that the FAA will eventually recognize DO-326 as a means of compliance.
I'm going to provide some information on safety and integrity measures that are standard in the industry and make hacking avionics difficult. In particular, hacking avionics is a type of safety-critical embedded device hacking, not server or personal computer hacking. Safety critical embedded devices have a much smaller attack surface and many more mitigation methods in place, as outlined below.
Threat model and differences from computers
The threats you face on planes are very different from servers and laptops. Especially for the most critical systems like displays and autopilots, datatypes are strict, messaging is scheduled, processing time is limited, and strings are rarely used. To accomplish most traditional attacks, you would have to break these protocols. This is similar to other kinds of embedded programming where the software is so inflexible that the attack surface is small.
Some things that definitely help attackers here include physical access to the software update process, being able to work with the plane for several days, insider knowledge, simple RF equipment, or ability to hijack satellite communications to the plane. If your attacker has some of those the threat is much more serious.
Availability
Is it possible to mess with the availability of aircraft systems? Yes, if you can manipulate the right signals. You could, for example, make the flight control computer think a sensor has gone bad. You could throw off a lot of sensors with powerful enough radio signals. A bug in 787 NG display software once led to all displays going black. Also, most flight computers use off-the-shelf processors with lots of weird behaviors, and especially if an exploit lets you execute arbitrary assembly code, you could exploit some of these to take the avionics system offline.
However, availability isn't as big of a concern as integrity of the avionics. Most people are really concerned about a hacker taking complete control of the plane, not forcing the pilot to fly by hand.
Partitioning
Different functions, especially ones at different safety levels, are by regulation insulated from each other. Although aircraft have historically had dedicated hardware for each component, nowadays much of this software is run on shared LRU computers (this is called an IMA architecture). But despite sharing hardware, the software processes are strictly insulated from each other and it is proved during certification that no processor faults, error conditions, overflows, etc. could transfer from one process to another, especially not a higher level process. Yes, signals pass between partitions, but any signals passing from a lower safety level to a higher level are individually justified to ensure they won't cause safety issues.
In order for an exploit to have catastrophic effect, it would have to get around these by either by 1) working directly with level-A hardware and processes 2) finding a poor assumption about the impact of a lower-level signal. These poor assumptions exist, but they're rare.
See DO-297 and DO-178C for more information on this partitioning.
Testing
Many hacks in personal computers happen because of inadequate testing that lets exceptions and faults into the system. Level A software is tested far more comprehensively than most apps or PC software. Every line is tested for MC-DC coverage (not exhaustive, but every decision has to be exercised as both True and False). Structural coverage is also evaluated to make sure unintended interactions don't occur. If faults do occur, the RTOS is designed to take care of these faults predictably and reliably.
Software updates
Ok, say you can't find a way to execute arbitrary code, can you mess up the software update process? This initially seems viable, especially given the new tendency to update avionics firmware over networks. There are several issues here.
- Most aircraft are not directly connected to the internet for avionics updates. So you'd have to get access to the local network for updates and then also get access to the planes using this network.
- Most software updates use a high-fidelity integrity check, for which you'd need an incredibly difficult hash collision. Some update processes don't have high fidelity checks, but if this is the case they must qualify to authorities that their update process is stable and error-proof. There are flaws that could be exploited, as the issue found during the A400M Seville crash showed. So only option would be to forge the CRC as well for the update and/or to find an exploit in a qualified loading process.
- Network based updates also keep track of the version numbers and may keep track of the integrity checks for the software. So you can't exactly force an update from version 13 to a hacked v. 13.1 without someone noticing.
- Currently supply chain attacks are becoming more and more frequent. While I'm sure a supply chain attack might be feasible, regulations such as DO-330 tool qualification and DO-178 configuration control have protected against inadvertent changes during software builds for years already. Tested and reviewed versions of code are under careful control and compared against the final versions, software build environments are locked down and qualified, and lists of included libraries are documented and approved. You'd have to find a blind spot in these processes to attack the software supply chain.
- Software updates (not navigational database updates) are performed infrequently, maybe once every three years if that, greatly mitigating the opportunity to hack a software load. Interlocks are in place to prevent reloading the software when not desired. This infrequency also leads to greater scrutiny of the entire process.
For more analysis of safety measures to prevent corrupt software or databases from being uploaded, I'd suggest you consult the standards for this process: DO-200A, Chapter 5 of FAA Order 8110.49,and FAA AC 20-153.
Manual and Automatic Disconnect
Usually the autopilot and other software is managed by another system which has interlocks and disengage logic. These have safety standards and tests written to make sure they work reliably, including a requirement for a software-free method of disengaging autopilot. This make it very tricky to find an exploit here without, say, already being able to execute arbitrary code.
Even if this disengagement software doesn't work, pilots have circuit breakers and can disable the entire avionics system, then fly the airplane by hand. See BigHomie's answer for a discussion of how feasible it is to hack this (answer: not very).
In theory, this should work, but in certain situations the plane could be put in an unsafe situation before the pilot could regain control. As the 737 Max incidents showed, sudden pitch down when close to the ground can be difficult to recover from, even if you can manually disengage the autopilot or manually disengage the trim system.
Note: I'm not an expert in avionics or embedded device security. Hacking tends to be about thinking outside the box, so let me know if anything I assume here is inaccurate or if I miss anything.
