Could a vendor plant back-door code in a network device? That’s a question that’s been asked many times, especially recently. The answer is obviously “Yes!” so the more relevant question might be “Is there anything that could be done, realistically, about that?” That’s a harder question to answer, but we may now need to think about answering it, or deciding it can’t be answered.
I’m not going to get into the politics of this. Everyone knows that Huawei has been accused of having the potential, or intentions, of slipping in a back-door trap that could allow them to intercept traffic or bring down a network. Most know that the US has been accused of similar things. Believe what you like, and defend what you must. We’ll focus on the latter here.
A “backdoor” is a way to gain access to software, either loaded or embedded, for the purpose of something unauthorized. Programmers have been accused of building backdoors into their code for reasons ranging from spying or theft to holding a client hostage against non-payment. Backdoors are designed to go undetected, but the level of subterfuge needed to achieve that depends on how much effort is taken to uncover the hack.
The simplest backdoors were things like administrative passwords that were built in and hidden, so someone could log on with full access rights. This sort of thing can usually be spotted by code analysis, especially if source code is available. If we assumed that somebody wanted to do something truly sinister and not get caught, it’s unlikely they’d use that approach.
The more sophisticated approach to creating a backdoor involves creating something that happens in normal software due to poor programming practices. Buffer overflow is the classic example. Programs read information into memory space called “buffers”. If the message that’s read in is longer than the buffer, and there’s no protection against that, the data at the end of the message then runs out of the buffer and into whatever is beyond it. That’s “buffer overflow”.
The hacking comes in when you put code in the end of the message, and that code overwrites the code that happens to lie beyond the buffer. If that code is then executed, it can open a door to a broader hack, often by jumping to a short program earlier in the packet. This sort of thing happens regularly with commercial software, which is proof that it’s not easy to find, but if the computer chip and operating system understand the difference between “code memory” and “data memory”, the hack could be caught when the overflow occurs. Again, it would probably not be a foolproof approach for someone who didn’t want to get caught.
The really sinister approach would be a lot harder to catch. Suppose your network device has (as most high-end ones do) a bunch of custom chips that perform specialized packet analysis or data forwarding management. These chips, in effect, have their own software hidden in silicon. This software could respond so some external trigger, like a sequence of bits in a series of packets, by triggering something seemingly normal at the software level. The sequence could also do things like alter forwarding instructions. It would be difficult enough to know that a hack like this had been perpetrated after the fact, examining the results. It could be near-impossible to find it ahead of time.
I don’t think that code reviews of the kind various companies and countries have proposed would have a realistic chance of finding a backdoor hack, and I certainly don’t think that such a review could prove there was none. Does that mean that there is truly no way to say that network devices or other IT devices and software, don’t have backdoor hacks waiting to be activated? Maybe no ironclad way, but there are surely some things that could be done to reduce the risk, and they all fall into what I’ll call “functional isolation”.
The idea behind functional isolation is that hardware and software components are more easily hacked when the boundaries between the elements are blurred. A chip, for example, is a greater risk if it can interact with device software directly, manipulate memory directly. Software elements are riskier if they have broad ability to invoke other components or change memory contents. If you limit these interactions through functional isolation, you reduce the risk of a hack. Furthermore, if you have a functional boundary, you need to ensure that a single vendor doesn’t control how that boundary can be crossed.
One obvious step to achieve functional isolation is to protect each “function” by making it impossible to access the memory of other functions; code protection through memory management. This has to be a feature of both the operating system and the CPU chip, though, and for devices that aren’t built that way, the obvious may be impractical.
One easier standard to enforce would be to say that any network device has to have its hardware and software unbundled, with the specifications for the interface available in open form, and the hardware must have an accompanied open-source software implementation available for it. This wouldn’t prevent proprietary coupling of hardware and software because the all-proprietary option would be available, but it would allow a buyer to separate the hardware and software if they believed they needed it for security.
A better level of security could be created by isolating hardware from software through a standard software intermediary, a “driver”. Many specialized interfaces and hardware elements are connected to the operating system or software via a driver, and if the driver has specific, standard, interfaces to what’s above it, and if it’s secure, then it’s harder for a chip to introduce a hack.
Let me offer a specific example. Many network devices can be expected to use custom forwarding chips. If the vendor who provides the device provides both these chips and the software that uses them, there’s a risk of a backdoor created by having a chip open an avenue of attack that software then follows up. Suppose, though, that all network devices that use special forwarding must use a third-party driver to support their chip and make it compatible with the P4 forwarding language. If the driver is certified carefully, the risk of a chip-created backdoor problem is reduced because the software won’t follow up on an attack.
Functional computing (lambda, serverless, microservices, whatever you’d like to call them) could also reduce the risk of a backdoor hack. A “function” in programming terms is a process whose output depends only on its inputs: result=functionof(inputs), in other words. If functions cannot store things internally or put them in some central store, then it’s harder to contaminate execution without coopting a bunch of functions to support your nefarious deeds. It’s easier to scan functional code for hacks, too, because they work specifically and singularly on what’s passed to them, and they produce only the specified result.
The challenge for operators or businesses that fear backdoor hacks is that vendors are likely to be slow to adopt these kinds of practices. That would leave the same choice that buyers have today; trust or go somewhere else for products.