Every application depends on other software to work. It’s not just the operating system, but an entire ecosystem of libraries and Application Programming Interfaces (APIs) that speed the process of developing and delivering all modern applications. From a software developer’s point of view, the wide variety of libraries and packages available is an amazing accelerator. It’s code that doesn’t have to be written and debugged and maintained because someone out there is already doing that work. But it can also be an accelerator for malware.

For example, let’s suppose you need to know how many hours are between two dates. If you’re a programmer, you can definitely figure this out. First, you convert the date (like “January 16, 1964”) to some standard format. Do the other date, and then subtract the two. The answer might be in seconds, so you’d divide that by 3600, and boom, there’s your answer. Except that we’re now talking about thousands of lines of software to do all of that work.

Or, you can take the easy way out: Find a library with some time-and-date API you can call to hand over a couple of dates and do the subtraction. That’s not just easy — it’s actually better, because you can use a library that has been tested and debugged and is based on hundreds of hours of someone else’s work, probably doing an excellent job at solving the problem.

Do APIs pose security risks?

For an IT manager, though, this style of software development comes with increased complexity and security risks. Why? Because when you install an application from developer X, you aren’t just installing software from X. You’re also installing libraries and APIs from A, B, C, D, E and F. And that can bring potential problems. First, each of these libraries and APIs may have bugs that can open the door to system compromise and security failure.

Second, the libraries and APIs are generally large compared to the amount of code that is actually needed. For example, a date-time library has more than 100 functions in it. And even if only one of those functions is needed, the entire library is loaded when even one of the routines is ever called. More code equals more potential for security problems.

It’s not just a theoretical problem. In October 2019, security researchers discovered that WhatsApp was using a library called “libpl_droidsonroids_gif.” That library has a memory allocation error in it (called a “double-free” bug). Combining that bug with a complementary bug in WhatsApp, and the researchers discovered several small holes that can be used to compromise Android versions 8.1 and 9.0.

What can be done about it?

Is this a problem? What can an IT manager actually do about these libraries that are hitchhiking on their applications? The unfortunate answer is, “not much.” But there are some things to keep in mind when users want to install applications on their mobile devices.

1. Just because the software developer is trusted and trustworthy doesn’t mean that the entire software supply chain is uncompromised. Treat every application, even ones from trusted vendors, as a potential security problem. Tools such as Android for Work and Knox Platform for Enterprise help to isolate applications and data, reducing the risk when security is compromised.
   
   
2. Use your Mobile Device Management (MDM) and Enterprise Mobility Management (EMM) tools to control application installation. For example, restricting application installations to the Google Play Store or requiring that Google Play Protect be enabled can help reduce the risk of malware making a beachhead on your mobile devices.
   
   
3. Using approved application lists is a radical step, but in high-security environments or those where the costs of compromise are very high, it may be the right step — again, managed through your MDM/EMM tools.
   
   
4. Remove applications, especially applications that are not being regularly updated, from your mobile devices when they are not being used. If someone loads a car rental app on their mobile device because they want to rent a car, that’s fine. But if that’s a one-off and they normally use a different rental car agency, get rid of that application.
   
   
5. If you’re also developing applications, encourage your development team to work with native Android APIs rather than third-party libraries. That’s not a promise that API compromise won’t happen, but it means you’re traveling a broader road with many more application developers, and many more eyes are looking at that code — which usually speeds security updates.

Today’s mobile device landscape is dotted with security landmines, and businesses and their employees can never be too cautious about what’s happening inside smartphones or tablets. See how Samsung Knox can help you navigate this landscape.