Library bundling is a growing problem for IT security and operations professionals – introducing risk in the form of software vulnerabilities that may slip into the environment – invisible and difficult to detect, writes Kasper Lindgaard, pictured, Director of Secunia Research at Flexera Software.
To complicate matters, frequently organisations aren’t even aware that they’re using bundled libraries. This makes it difficult for them to know whether they are actually protected against all vulnerabilities to which they may be exposed.
Indeed, bundled libraries presents a sort of shell game for companies, non-profit organisations and governmental institutions. Unfortunately, most are not even aware they’re playing this game of chance. Readers may be familiar with the gambler’s shell game scheme whereby an item – say a little ball – is placed under one of three identical shells while the player observes. The operator quickly shuffles the shells around, after which the player – usually to his detriment – bets on which of the three shuffled shells contains the ball.
In many respects, this is the challenge security and IT Operations professionals face when contending with reducing the vulnerability risk associated with bundled libraries. For a variety of reasons, many if not most software vendors do not develop 100 percent of the code comprising their products. In fact, they frequently bundle libraries and open source code developed by others into their products.
The reasons for bundling software vary by vendor – but these decisions are usually made to increase application development efficiencies, compatibility or cross-application communications. Examples of commonly bundled code include cryptography, image, and document handling libraries. In most of these situations, code to perform common computing functions – whether that code is open source or otherwise – already exists and has been standardised. So, it makes sense for vendors to bundle the libraries into their own products rather than to recreate it themselves.
There are, however, security implications of bundled libraries that both application producers and their enterprise customers need to understand and account for. For instance, producers must keep track of all open source or third-party software they bundle into their products. From a security perspective, this is essential because if a software vulnerability is found within the third party software, it is the producer’s responsibility to be aware of the problem and provide a software update or patch to affected customers when one becomes available.
Enterprise customers using bundled libraries are often at a disadvantage in the battle against software vulnerabilities– because it is not obvious to them that they are even running a bundled code. Software companies do not necessarily advertise their use of bundled libraries – and therefore enterprises have difficulty unravelling whether or not they are at risk when a vulnerability in a library is reported.
The 2014 Heartbleed vulnerability in the OpenSSL library that swept through the industry a couple years ago is a case in point. What made Heartbleed so pervasive and difficult to tackle was that the open source library in which it was found was bundled into so many different software products, putting at unwitting risk the users of those products. Indeed, Secunia Research at Flexera Software issued more than 211 advisories on products impacted by Heartbleed, the last one on May 13, 2016, more than two years after the vulnerability was disclosed.
Another complication is ‘criticality’. Some vulnerabilities are more critical than others in terms of risk exposure. And depending upon how the bundled libraries interacts with a vendor’s application in which it has been bundled – the criticality of a particular vulnerability can differ. For instance, when the vulnerable code containing the Heartbleed vulnerability is bundled with application “Application A”, it may be rated as “3 – Moderately Critical . But that same vulnerability bundled with “Application B” may only be rated as “1 – Not Critical.”
The challenges for enterprises are therefore threefold. First, they need some sort of mechanism to know they are using a product, which has a bundle library containing a vulnerability. Second, then they need to understand the vulnerability’s risk in order to prioritise it. Lastly, they need to await a patch to be released by the product vendor and then determine whether and when it should be patched.
Software vulnerability management
The shell game would no longer present a gambling risk if the shells were transparent, making the ball hidden underneath immediately apparent to the player. And that is the function a good Software Vulnerability Management strategy should perform for bundled software. It should accommodate the special use case bundled software presents. And it should provide automation and seamless handoff from vulnerability assessment, to mitigation to verification. So let’s examine each of these three steps:
Vulnerability Assessment: In the assessment stage, organizations need access to verified vulnerability intelligence that enables them to verify that a vulnerability, indeed exists. Given the wide variety of vulnerability reporting sources, and their varied quality, receiving verified intelligence is critical to know whether further action is necessary.
A good vulnerability intelligence source will also be able to track the vendors reporting vulnerabilities in their bundled libraries. Their vulnerability advisories, therefore, would not just be issued on the source library containing the vulnerability, but also the applications bundling that same code. This is the reason, for instance, that Secunia Research at Flexera Software issued 211 advisories on Heartbleed – not just one. Good vulnerability intelligence enables organisations that may not be aware they’re running bundled software to nonetheless be alerted that an application they’re running is impacted by vulnerable bundled code.
Assuming the threat is real, security and IT Operations teams must then determine if the organisation is at risk. To do this, organisations need reliable automation that will continually discover, inventory and normalise all IT assets. Only with this comprehensive inventory, can you understand which verified vulnerabilities actually apply to you.
Finally, meaningful assessment should support prioritisation. Most companies are faced with hundreds if not thousands of vulnerabilities in a given year. Without the ability to prioritise risk, mitigating those risks appropriately is difficult. The vulnerability intelligence service an organisation subscribes to, therefore, should attach some sort of criticality rating to each vulnerability. This allows security and IT Operations teams to efficiently, effectively and economically assess whether and when a patch needs to be applied.
Mitigation: The second prong of the Software Vulnerability Management strategy involves mitigation. This is often where the handoff takes place between an organisation’s security and IT Operations group. The IT Operations team ordinarily handles patch management, and will use their Application Readiness processes to identify and download the applicable patches. Patches then need to be tested (i.e. for dependencies) and packaged up and distributed to the correct devices.
A good mitigation process should also assist the IT Operations team in identification of known vulnerabilities within the corporate environment, and prioritisation of patches based on criticality, so the most dangerous vulnerabilities can be addressed first. As noted earlier, intelligence and automation are key to both identifying and prioritising vulnerabilities, as well as assigning criticality and automating the patch process.
Verification: The last step of the Software Vulnerability Management strategy should involve verification, whereby the application of the patch or other mitigation technique is verified. For different areas of the organisation, different verification methods can be applied, such as ticketing systems, scanners or reports.
Using bundled libraries is like a security shell game – if you can’t see where the software vulnerability is – you can’t fix it. To reduce the shell game risk, organisations need transparency. A good Software Vulnerability Management strategy will give organisations the intelligence and automation they need to assess their vulnerability risk across all IT assets, including bundled software, and then mitigate those risks and verify that the threat has been handled.
