Google Chrome - the most popular browser - recently faced a far-reaching security risk. According to ZDNet, the security vulnerability "could have been abused by hackers to develop exploits and launch attacks" on its users.
The vulnerability was found in V8 - an open-source component which is used as the JavaScript engine in Google Chrome. As claimed by ZDNet, "the bug was both critical and widespread ...; enough to be useful to develop an exploit that could allow attackers to execute malicious code inside users' browsers."
However, the vulnerability was already fixed in V8. So, what was the problem? Though V8 received a patch to fix the security bug, Google Chrome was using its older version which was still vulnerable. It's known as a patch gap, i.e., a patch is available to fix a bug but it's not utilized by the app for a time interval.
As per ZDNet, it occurred because "the V8 bug (tracked as #992914) was patched in August, but the fix for Chrome users is scheduled to go ... on September 10." As a result, "threat actors had weeks to scour the V8 changelog for security fixes and then develop exploits that could have been used against Chrome."
Thankfully, the patch gap didn't last for months in this case, else it could have affected millions of users of Google Chrome - at the least. However, it's not the first time that an open-source patch gap could have proved disastrous.
In fact, open-source vulnerabilities had proved catastrophic various times in the history of application and data security. For instance, a security vulnerability in an open-source web-application software called Apache Struts resulted in the popular data breach in 2017, which leaked data of 143 million people.
But, it was preventable! "Capping a week of incompetence, failures, ... Equifax has confirmed that attackers entered its system in mid-May ... vulnerability that had a patch available in March. In other words, the credit-reporting giant had more than two months to take precautions," according to WIRED.
That means it was a patch gap too, like the one with Google Chrome. The patch for the relevant vulnerability was fixed two months before the attack, but the technical team at Equifax failed to apply patches in a timely manner. It provided attackers enough time to develop an exploit that could target the vulnerable systems. And finally, they found and hacked the systems at Equifax.
Also, Heartbleed is another classic example of patch gap. It's a security bug in OpenSSL - an open-source cryptographic library - that was announced and patched on 7th April 2014. However, 1.5 percent of 800,000 top websites were still vulnerable on 20th May 2014, as tested by AVG's Virus Labs. Unfortunately, 91,063 sites were still vulnerable as on 11th July 2019, reported Shodan.
This brings us to the most important question: what's the solution?
Software Composition Analysis
Software Composition Analysis (SCA) automates the process of identifying the open-source and third-party components of an application. It comprises tools which help with analyzing and identifying an application's components for the purpose of risk management as well as license and security compliance.
Software Composition Analysis (SCA) is one of the technologies that help with open-source vulnerabilities. Since the modern applications are primarily built using open-source components, they pose great risks due to the rise of security vulnerabilities in the open-source applications, libraries, and utilities.
In fact, 7,000 vulnerabilities were discovered in open-source software during 2018, according to a report Open Source Security & Risk Analysis (OSSRA). Also, it reported a rise in the average number of open-source components. Moreover, 60 percent of the codebases had at least one open-source vulnerability.
On top of that, one or more of the apps are still vulnerable to buffer overflow flaw in the libmytinfo library - a bug that was reported 28 years ago. And, 43 percent of the scanned apps contained a vulnerability over 10 years old.
"The reality is that open-source is not less secure than proprietary code, ... But neither is it more secure. All software, be it proprietary or open-source, has weaknesses that might become vulnerabilities, which organizations must identify and patch," according to the report from Black Duck by Synopsys.
That's why it's of utmost importance that an app's open-source components are regularly monitored for vulnerabilities. It's because if an organization doesn't know about a vulnerability, how will they fix it, right? That's why SCA is so helpful - organizations get to know about bugs, which they can fix then.
But is it enough for securing applications? Is it possible to shield the apps?
Software Container Technology
Software container technology or container technology is a software packaging technology that helps packing an app along with its configuration files, libraries, necessary executables, and other dependables into a single package. It virtually packages and isolates an application from other apps running on a machine.
"Containers offer a logical packaging mechanism in which applications can be abstracted from the environment in which they actually run. This decoupling allows container-based applications to be deployed easily and consistently, regardless of whether the target environment is a private data center, the public cloud, or even a developer's personal laptop," according to Google Cloud.
Since containers isolate applications from one another, they prove useful as a security mechanism as well. It's mostly helpful when they're implemented along with Runtime Application Self-Protection (RASP) - a runtime technology that helps an application identify and defend against attacks in real time.
With both of these technologies working together for an application, the app protects itself from attacks as well as it's isolated from other apps. So, if some application is compromised, an attacker can't use it to target another app.
However, software containers are not perfect security boundaries, unlike virtual machines. That means they can get compromised if the container's hypervisor or the operating system's kernel (among other things) is compromised. But, it's only true if the container is not protected using the necessary security tools.
Since containers are widely adopted and supported by organizations, there is a large community of developers and security experts that work on many security products to improve docker security and container security in general. That said, software containers act as reliable security boundaries if you follow the industry-proven security practices and tools to secure your containers.
Finally, open-source vulnerabilities are raising the security risks for every app, but there are tools that help solve the problem. SCA tools can help you know your app's components, find their vulnerabilities, and fix them. Then, containers along with RASP can help protect your app during runtime. And of course, you require to put the best practices and tools in place to harden containers.
