Internet of Things Security Vulnerabilities: It's All About Buffer Overflow

Altium Designer
|  Created: December 15, 2017  |  Updated: September 25, 2020

A fist punching a palm with orange sparks flying

I follow a bunch of animal and nature publications, and recently the phrase ‘zombie ants,’ kept popping up in my feed. I decided to do a little digging and discovered that there’s a type of fungi - Ophiocordyceps - whose life cycle involves infecting ants that walk across its spores with fungal cells that infiltrate the ant’s central nervous system and essentially take over the ant. Once they have the ant "under its control", the fungus-infected ant climbs a plant stalk, clamps down on a leaf, and turns into more of the fungus from the ant’s body to then spread more of its spores. This overflows the region with more potential fungus and zombie-ants.

This may seem a bit gratuitous, but it's a lot like the way hacker groups steal their information from large companies and even governments. They attack websites and services using botnets made up of thousands of Internet of Things devices. These gadgets have been turned into “zombies” that do their master’s bidding through malicious software (malware). Defending our networks and products from becoming part of these armies is a daunting task as software exploits can come in all shapes and sizes. Luckily for us, though, there is one vulnerability that is often used which we can protect against: buffer overflow vulnerabilities. This error allows hackers to inject their code into our PCB’s memory and then execute it. Careful programming can reduce the risk posed by buffer overflow, and following IoT security best practices can limit attackers ability to attempt buffer overflow.

What is Buffer Overflow

Buffer overflow was first widely acknowledged during the “Code Red” attacks in 2001. These assaults used buffer overflow vulnerabilities in Windows to take control of computers, one version infecting hundreds of thousands of machines in a matter of hours. Once infected those computers were then used to launch a distributed denial-of-service (DDoS) attack on the White House. Since that time, buffer overflow has become one of the methods of choice for hacker groups seeking to infect devices. In order to defend against this vulnerability, it’s important to understand how it works and why it poses a particular threat to the IoT.

This kind of error occurs when a program tries to write a value that is too large into a buffer. A buffer is simply a piece of memory allocated for certain values. When the program attempts to fill it with more data than it can hold, the buffer “overflows” into other sections of memory. This usually results in a system crash but can also open the door for hackers to gain access to the system. Hackers can use buffer overflow vulnerabilities to do two things: inject their code into a system, and run the injected code. The first can be quite complicated and is system dependent. The second, however, is quite easy to understand. If malware has been inserted into memory and the hacker knows where it is, they can simply overflow the buffer next to it with a connected device in order to run that program. It's like putting an embedded device that steals wallets into a room no one every goes in, then inviting over a ton of people. People "overflow" into the extra room, and wallets go missing.

The Weak Links Targeted by Buffer Overflow

Buffer overflow poses a particular risk to an IoT device because of their limited memory, the languages they’re programmed in, and the commonality of programs.

  • Memory: An IoT device usually needs to conserve power, which leads to small amounts of energy efficient memory. The smaller the buffer, the easier it is to overflow. This removal of an innate  IoT security "buffer" makes the IoT the perfect arena for these kinds of attacks.
  • Language: Most programs for the IoT are written in C or C++. Neither C nor C++ has a “garbage collector” for extra memory needs, which increases the risk of buffer overflow vulnerabilities. Also, these languages use pointers, which can be used by hackers to determine the location of critical code in memory.
  • Commonality: The convenience of buying ready-made, inexpensive, programs for our IoT devices can be too tempting to pass up. When you use the same code as everyone else, though, you run the risk of having common vulnerabilities. One such exploit, known as Devil’s Ivy, was found in software used by thousands of IoT devices and just recently revealed. Many machines only escape infection through obscurity. If your product can be infected along with thousands of others because of common code, it’s much more likely to be targeted.
A computer error shutdown screen
A buffer overflow can be used to gain access to or crash your device.

Bar Your (Programming) Windows, Patch Your (Security Gateway) Walls

Now that we know the dangers that buffer overflow poses to a typical IoT device, how do we defend against it? There are several ways to mitigate this risk. If you’re writing your software yourself, careful internal programming can keep your device safe:

  • Check Input Sizes - If you know how large an input should be, check to make sure it is that size. Buffer overflow vulnerabilities occur because a value that is too large is written to memory. If you can detect the size before passing it to memory, you can reject values that are too large and will cause overflow. This may not be applicable to all systems, for example where incoming sensor data may be an unknown size.
  • Make Memory Non-Executable - As stated previously hackers will often hide malware in memory and then use a buffer overflow to execute it. If the part they inject source code into is non-executable, it could keep them from activating their program. Due to the diversity of buffer overflow attacks, this can stop some intrusions, but not all.
  • Use ASLR (Address Space Layout Randomization) - As the G.I. Joes always said, knowing is half the battle. If a hacker knows where critical code is stored, they may be able to overwrite or delete it. ASLR randomizes memory locations, making it much more difficult for attackers to find their targets.

Even if you use someone else’s programs you can insist on a few best practices or enable them yourself that will defend your system. Some of these may soon be mandated by the US government:

  • Enable Patching - If you find out that your software is vulnerable, you’ll need to be able to patch it. If you’re not able to, your gizmo could become a “zombie” in a botnet for the rest of its existence.
  • Gateways - If you’re designing a peripheral or sensor for a large network, consider designing for interoperability with an IoT security gateway. These can reduce the likelihood that a hacker will assault your device directly, and will instead have to deal with a portal that is designed for security.
  • Authentication - Many buffer flow attacks are attempted using “Man in the Middle” (MITM) schemes. Authentication will ensure that your system only receives inputs from trusted devices, not malicious code or pretenders.
Green numbers on a black screen with overload in a large font
You can defend your system with careful code and best practices.

The IoT can benefit mankind greatly, but also presents a huge new attack surface for hackers. Buffer overflow assaults have been used extensively in the past, and are perfectly positioned to affect the IoT. Fortunately, we can either write source code that protects against this vulnerability, or incorporate a few best practices into our design to mitigate this risk.

Cybersecurity is a daunting issue, and one that will likely take up more of our time than we’d like in the future. With this issue looming, there’s no time to waste on inefficient design. That’s why you should use the best PCB software available. Altium Designer® comes with a range of tools, and even optional add ons, that can speed up your design process.

Have more questions about IoT cybersecurity? Call an expert at Altium Designer.

About Author

About Author

PCB Design Tools for Electronics Design and DFM. Information for EDA Leaders.

Recent Articles

Back to Home