News
Libwebp vulnerability – Comment by Veracode
September 2023 by Marc Jacob
As you probably already know, the Chrome zero-day vulnerability revealed a few weeks ago that was subsequently patched by Google, has turned out to not be originated from Chrome, but from the libwebp library, which is popular among applications for encoding and decoding the WebP image format. This two comments analysing the news by Veracode’s most senior spokespeople: Chris Wysopal, co-founder & CTO and John Smith, EMEA CTO.
John Smith, Veracode EMEA CTO:
In recent years a lot of software has been written using languages that manage memory for you which makes it much easier to avoid these kinds of problems. But when speed and efficiency are essential - as with jobs like image rendering in a browser - languages that provide lower level capabilities are needed and so the risk of these kinds of memory related vulnerabilities become more likely.
As with any software project developers don’t reinvent the wheel if a viable option already exists so it’s not surprising that libwebp is widely used. The same reasoning was behind the widespread issue of Log4J and other well known vulnerabilities in recent times.
For software developers the imperative now is to make sure that the libraries they are using are safe and up to date. For software consumers the challenge can be harder - first you need to know what is in the software you are buying. This is where Software Bill of Materials (as referenced in a recent Executive Order in the US) can help.
If you are buying software you should insist that your suppliers are taking steps to ensure the security of their products, and that they are transparent about the ingredients they are using.
Chris Wysopal, Veracode Co-founder & CTO:
“The large number of high-quality open source projects has allowed organizations to build more custom applications – and become more dependent on open source software (OSS) – than ever before. This means that organizations must have two critical processes in place to manage the risk of vulnerabilities.
The first is to inventory the OSS in those apps continuously by scanning code during the software development life cycle (SDLC). This mitigates the latent risk that exists in production code and enables organizations to efficiently remediate it when new vulnerabilities like Log4j are disclosed.
The second crucial step is to implement a highly automated SDLC. This ensures that the process of updating, testing, and deploying a new version of a custom application with an updated OSS package to fix a new vulnerability is quick and efficient. This is necessary to beat attackers who are racing to exploit the newly discovered vulnerability.
We have found that 79% of developers never update third-party libraries after including them in the codebase. This is despite the fact that 92% of open source library flaws can be fixed with an update, and 69% of fixes are minor and won’t break the functionality of even the most complex software applications. Software buyers should ask their vendors if they have these processes in place to close the vulnerability window caused by a slow response to updating their open source.”
