Critical bug, actively exploited, gets some clarification.

Google has updated its account of a vulnerability, and issued a patch to address exploitation in the wild. TechCrunch reports that what had formerly been perceived as a vulnerability in Chromium is in fact a problem with the open-source libwebp library used by Chromium developers.

The challenge of tracing the supply chains.

Researchers at Huntress are tracking CVE-2023-4863, a critical heap buffer overflow vulnerability in the libwebp library used by Chromium. Libwebp is widely used by applications for supporting the WebP image format. The vulnerability’s description says the flaw has been exploited by a “remote attacker to perform an out of bounds memory write via a crafted HTML page.”

Huntress notes, “A full list of affected software is still unknown at this time. Any software that uses the vulnerable library is likely affected. Due to the prolific use of libwebp as a software library, the attack surface of this vulnerability is likely extensive. The patch to libwebp 1.3.2 fixes this issue upstream of its implementation. However, any software that ships with libwebp is potentially vulnerable.”

The researchers add, “Right now, the most prudent step to take is to update any web browsers and ensure you have a solid software inventory that includes software versions. Being able to quickly identify where you have vulnerable versions of software as patches are released will greatly reduce your risk.”

Convenience and productivity, but with a more extensive attack surface..

Chris Wysopal, founder and CTO at Veracode, sees the obvious advantages of good open-source code, but explains some of things users might do to help keep their supply chains secure. “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," Wysopal wrote in emailed comments. "This means that organizations must have two critical processes in place to manage the risk of vulnerabilities." 

Wysopal went on to offer two prudent measures. “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," Wysopal concluded. "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.”