Insecure C?

We are at the dawn of a new era of connected embedded devices, broadly being marketed as the “Internet of Things” (IoT). The majority of these systems are likely to be programmed using C/C++. To date, much of the embedded world has been connected to propriety networks, however with the gold rush in to IoT we are not going to be able to rely on “Security through Obscurity“. This is the first in a series of articles looking at some of the vulnerabilities at the programming language level.

This and many other issues are covered in the Feabhas Training course Secure Linux Programming

Integral data types in C

Due, mainly to history, the integer types in C can be a little confusing, but for simplicity and brevity I’ll consider the core integral types to be:

• char
• short
• int
• long
• long long

In reality, of course, a short is a short int, but for this discussion I’ll keep to the generally accepted model of referencing them as they’re shown above.

Next we can apply signness to the types:

• unsigned
• signed

Again for simplicity I’m going to assume that a signed int is using 2’s compliment representation. Even though the standard allows for “Sign and Magnitude” and “1’s compliment” I don’t know any (mainstream) modern compiler not using 2’s compliment[1].

Next we have to look at the underlying data models. The actual sizes of the data types are implementation defined in <limits.h>, but the implementation values must be greater than or equal to:

• A char is a minimum of 8 bits
• A short is a minimum of 16 bits
• An int is a minimum of 16 bits
• A long is a minimum of 32 bits
• A long long is a minimum of 64 bits

Note the emphasis on the word “minimum”. However, it is also accepted that plain int’s “have the natural size suggested by the architecture of the execution environment”; thus on a 16-bit architecture a plain int would most likely be 16-bits, whereas on a 32-bit architecture they would be 32-bits.

For the remainder of this discussion I will base my examples around a “ILP32LL” architecture, meaning that the int, long and pointer are 32-bits, char is 8, short is 16 and long long is 64 (e.g. commonly found on ARMv7 architecture).

Ideally, to help reduce some of this confusion we should be using the C99 platform independent types from <stdint.h> and <inttypes.h>, but for now I’ll still reference the base types.

What are the potential underlying problems?

The problems with integers occur in a number of ways, significantly:

• Overflow
• Underflow
• Promotion/extension
• Demotion/narrowing
• Sign conversion

with the behaviour of each issue being dependent of the underlying types

Continue reading →