Are your open-source components vulnerable?

Long story short, we can say that open-source took over the world.

Most of the software we use today contains to a lesser or greater extent some open-source components, which is one of the greatest benefits of this domain, we create something once and, we do it well and after we use it many times. This procedure not only saves us time but especially money.

Some of the most common open-source software we use in our development cycle is:

• Apache/Tomcat
• Nginx
• C,C++,C#
• NodeJS
• PHP
• JavaScript
• WordPress
• jQuery
• Docker
• etc…

As you can see, more or less we all rely on some open-source software to develop our applications.

“Open-source software (OSS) is a type of computer software in which source code is released under a license in which the copyright holder grants users the rights to study, change, and distribute the software to anyone and for any purpose. Open-source software may be developed in a collaborative public manner. Open-source software is a prominent example of open collaboration.”

Wikipedia docs

How safe everything is?

In terms of security, open-source software acts as a double-edged sword.

On one hand, being open source makes projects more secure, because the community is actively engaged in reading and improving the project. On the other hand, some ill-intentioned developers can inspect and search the vulnerabilities in order to use them for their own interest, or once a vulnerability is found everyone who’s following that topic will find out about it, thus putting yourself in a race with hackers, a race where every moment matters. Can you fix the problems faster than they can find out how to exploit it?

Some high-risk vulnerabilities from the last year

December 23, 2019 — Double Free in PHP

On Dec. 23, 2019, a double-free vulnerability was found in PHP when supplying custom headers to mail() function, so if the header was supplied in lower case, this would probably result in double-freeing certain memory locations. On a severity score scale from 1/10, this vulnerability was marked with a score of 9.8

This security issue could eventually lead to memory leaks or corrupted memory which could allow a malicious user to write values in arbitrary memory spaces.

The solution for this problem was to fast upgrade to version php-7.2.26,php-7.3.13,php-7.4.1

2. February 12, 2020 — Input Validation in Jenkins

The issue allows a remote user to gain privileges on the system, by circumvented the sandbox protection during the script compilation phase by applying AST transforming annotations to imports.

A remote user with read permission can bypass sandbox protection and execute arbitrary code in the context of the Jenkins master JVM.

Severity Score: 9.9

Fix: Upgrade to version 1.70

September 6, 2019 — Input Validation in Python

This vulnerability was found in the email module from Python through 2.7.16, 3.x through 3.5.7, 3.6.x through 3.6.9, and 3.7.x through 3.7.4. The problem is that the email module wrongly parses

email addresses that contain multiple @ characters, thus an attacker can trick the application to accept email addresses that should be denied.

Severity Score: 7.5

Fix: No fix version available only an upgrade versions fix

July 15, 2019 — Input Validation in Bootstrap Vue

This issue was discovered in vulnerable versions of bootstrap-vue. The issues were with an insufficient input sanitization that made components vulnerable to an XSS attack through the options variable. An attacker could have exploited this vulnerability to execute malicious JavaScript on the user’s browser.

Severity Score: 9.9

Fix: Upgrade to version 2.0.0-rc.12

November 20, 2019 — Input validation in PHP

This issue allowed attackers to execute arbitrary commands through Dolibarr ERP/CRM version 3.3.1 by exploiting the fact that the user input in viewimage.php and barcode.lib.php was not properly validated.

Severity Score: 9.8

Fix: Upgrade to version dolibarr — 3.3.2

June 26, 2019 — Buffer Errors in PostgreSQL

PostgreSQL versions 10.x before 10.9 and versions 11.x before 11.4 are vulnerable to a stack-based buffer overflow. According to PostgreSQL’s trusty release notes, “An authenticated user could create a stack-based buffer overflow by changing their own password to a purpose-crafted value.” The PostgreSQL team warns that a hacker can not only crash the PostgreSQL server but also they can further exploit it to execute arbitrary code as the PostgreSQL operating system account.

Severity Score: 8.8

Fix: Upgrade to version REL_10_9;REL_11_4

What we have seen so far is just the tip of the iceberg and the list with the vulnerabilities goes on.

How to overcome this open-source vulnerability?

A list of best practices that can help you overcome this vulnerability is the following:

• Enforce Security Standards — develop with a security-first mindset, keep in mind that the best security solutions will be the simplest to integrate, like a proper input sanitization, blocking some ports on your host that should not be accessible from outside, disable remote connections, enforce ssh connection over username/password
• Surround vulnerabilities with containers — isolating your application from the host system will limit the potential damage from any open source vulnerability.
• Audit Code Commits — check your repositories with automated tools that search for vulnerabilities
• Check Vulnerability Databases and apply security patches promptly — several vulnerability databases exist that gather information on different types of vulnerabilities, and it is prudent to check them regularly

Conclusion

Nothing will be 100% secured, no matter what open-source software you use or what programming language you choose. But you can still prevent attacks if you patch your open source components on time and you make sure that no matter what the damage will not disrupt the entire system.