3

Software libraries targetting resource constrained environments like embedded systems use conditional compilation to allow consumers to shave space and thus increase performance by removing unused features from the final binaries distributed in production.

Assume that library developers produced the compiler flags and were a consideration at design and test phases of the library.

As most design decisions, there are tradeoffs, in this case the code complexity and product quality unarguably suffer due to the increased branches to design and test against.

However with regards to security, the net impact is not clear, there are both positive and negative effects from removing features. Initially, removing code reduces the surface of attack. But on the other hand, building a custom binary means that a bug, and thus exploit, might be present in that specific combination.

The implications differ from those of traditional runtime path complexity, not just because of the consideration of 2 different types of branching, but because compiler condition syntax is far unsafer than its runtime counterpart (at least in C).

An interesting phenomenon is that building a custom binary might expose the users to targetted attacks, but using a standard build might expose the users to mass exploits.

The question is, considering there are both positive and negative influences on security, if we were to quantify them, would the net impact be positive or negative? In other, less academic words, if one is concerned with security, should they build a custom binary without the features they need?

The specific example that sparked this question is Busybox heavy use of conditionally compiled feature flags. https://git.busybox.net/busybox/tree/networking/httpd.c

5
  • 1
    ... Both. It does reduce the surface area. It does provide opportunities for a set of infrequently paired configurations to do something bad. It does increase the complexity of the tooling around the code. How much of each entirely depends on the code base, the testing, and the tooling. It might be better to ask what sort of vulnerabilities are exacerbated, and what sort of vulnerabilities are reduced. Also the Information Security group might be a better place to ask this. – Kain0_0 Mar 3 '20 at 0:23
  • Thank you for the link! I posted this question there as well security.stackexchange.com/questions/226708/… – Tomas Zubiri Mar 3 '20 at 0:37
  • In memory constrained systems, removing unused features is not done for a performance increase, but to have a bigger chance that you can fit all the requested system features actually on the device. – Bart van Ingen Schenau Mar 3 '20 at 9:39
  • I don't have proof for this, but since busybox is such a low level library, I believe that it could increase cache hit rates on CPU caches and RAM. Additionally busybox is heavily used through alpine on container networks. If bandwidth throughput is a bottleneck it could also increase performance on such a distributed system, albeit for deployment events like updates, incident repair, and traffic balancing. – Tomas Zubiri Mar 3 '20 at 10:45
  • 1
    Btw, BusyBox has been subject to a lot of research efforts related to variability and conditional compilation. Just to give you a quote: "we found several configurations of BUSY- BOX, for which the GCC compiler warns about format- string security problems...", Tartler et al. 2014. If you are not aware of this I recommend just looking for "busybox ifdef" on scholar.google.com – Hyggenbodden Mar 3 '20 at 22:34
2

Generally speaking, it decreases the security risk.

Whenever you have unused features, there is a chance that some attacker might find a way to activate them and this will cause code which you haven't tested to run.

However, if the code is not written robustly in the first place, it may introduce new security vulnerabilities. It is reasonable to assume that a library which has compiler flags to remove features is designed to work properly with any combination of features removed. This might not be true for the code which uses the library.

A lot of code doesn't check for errors from library calls, when the developer thinks the call cannot fail. If a call that "can't fail" suddenly fails, it can have unexpected security implications. For example, at one point in time, the Linux program sendmail didn't check for errors from the setuid call, which lets your program assume the privileges of another user. If an attacker made setuid fail, sendmail would have root privileges, when it should have the attacker's privileges. The attacker could access files anywhere on the filesystem, instead of just their own files. The vulnerability description does not explain exactly how sendmail can be used to access files.

Another special case is if protocol version negotiation is involved. If you have a TLS library which supports TLS 1.3, and connect to a server which supports TLS 1.3, it will use TLS 1.3 to connect to the server. However, if you disable support for TLS 1.3 and 1.2 and 1.1 and 1.0, if the server allows it, the library decide may connect to the server using SSL 3.0, which is vulnerable to an attack called POODLE. (You should mitigate against this possibility by disabling all the old protocols which - once again - increases security)

0

Generally speaking it increases the security risk.

Whenever you have a feature flag of some kind you no longer have a single program, you have two or more programs.

Each program may have bugs so a single compilation flag potentially doubles your risk.

Now obviously, you can analyse any given program/feature flag set and work out that only parts of the program are affected and thus the actual risk isn't doubled. But I would venture that such mathematically proven static analysis is not the norm.

If we are just ball parking risk, then we have to assume that there are bugs for which we haven't tested, that a seeming small feature flag might affect seemingly unrelated parts of the program and account for those risks.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.