The fault of the unsecured open source code



The debate around open source code is sure to continue in the years to come, and we have already detailed the high-level pros and cons of using it. But one thing is certain, the use of open source is almost inevitable today and it is becoming an integral part of any software development effort. With that in mind, another essential thing to consider is the variety of security stacks that exist and are based on open source code. The most common of these batteries is often referred to as a “LAMP”, but there are countless others as well as tools that are not part of a specific battery. While each offer their own handful of benefits, they also have their own vulnerabilities, given that they are all built on insecure code.

According to recent research, open source vulnerabilities increased by almost 50% in 2019 compared to the previous year. Additionally, even though 85% of open source security vulnerabilities have a patch available, over 50% of open source vulnerabilities do not receive it for one reason or another, ultimately leaving them open to attack. We’re so used to deploying tech stacks and relying on network protections, but if bad actors are supposed to come in, security is exposed. So what are some of these specific vulnerabilities that exist within the LAMP stack?

The “LAMP” security battery was one of the first of its kind and remains the most commonly used battery. Consisting of Linux as an operating system, Apache as a web server, MySQL as a database, and PHP as a programming language, LAMP is a classic layered architecture that can host a variety of web applications. popular, such as WordPress, Wikipedia, and Drupal, and also offers great flexibility, such as deployment to multiple operating systems. A LAMP stack also gives users a tremendous amount of customization and the ability to scale. However, each of its four components remains open to potential vulnerabilities. According to and its vulnerability categorization, a large percentage falls into the three categories of memory corruption, overflow, and code execution. The following tables break down the data by total number of LAMP vulnerabilities, as well as those that specifically fall into three categories, over the last two decades and also the previous five years:

Software Number of reporting years Total vulnerabilities 3 categories %
Linux 21 3057 1239 40.53%
Apache 21 225 47 20.89%
MySQL 20 715 38 5.31%
PHP 20 601 336 55.91%
Software Last 5 years Total vulnerabilities 3 categories %
Linux 5 2581 999 38.71%
Apache 5 46 5 10.87%
MySQL 5 478 6 1.26%
PHP 5 221 126 57.01%

Based on the data, it becomes extremely obvious that Linux vulnerabilities are much higher than the rest of their counterparts in the stack. This can be directly attributed to the large amount of software deployed through Linux systems. One of the primary vulnerabilities found in the stack is Common Vulnerability and Exposure (CVE) 2015-0235, also known as “GHOST”. It was named after the functions of the system where the vulnerable code was found and the vulnerability itself is a buffer overflow which was a bug in the GNU C Library (GLIBC). This vulnerability exists on almost all Linux systems and is also loaded in almost all applications, putting all of them at risk. But GHOST is not the only CVE that has recently infested the components of LAMP. The table below contains a more detailed description of some other notable vulnerabilities:

LAMP Pile CVE # Details
Linux CVE-2016-7117 Remote code execution via malicious MPLS packet
CVE-2016-10229 Remote code execution via malicious UDP packets
Apache CVE-2019-10097 Stack buffer overflow that could be exploited by a trusted proxy server
CVE-2014-0226 Race condition in mod_status allows heap-based buffer overflow
MySQL CVE-2014-0001 Buffer overflow from a long server version string
CVE-2016-0546 Unspecified buffer overflow
PHP CVE-2019-9025 Possible buffer overflow due to invalid multibyte string regex processing
CVE-2016-2554 Stack buffer overflow in PHP’s processing of TAR archives

But not all open source tools rely on a commonly used security stack. Components like SSH, PostgreSQL, NGINX, and Redis are also quite common in the open source community, providing various benefits, along with the associated vulnerabilities. SSH focuses on data encryption to ensure that attackers cannot access user credentials and passwords, while preventing DNS and IP address spoofing. Meanwhile, PostgreSQL, formerly known as Postgres, is best known for being the first database management system that uses multi-version concurrency control (MVCC) functionality, even before Oracle, while not requiring very minimal maintenance and a low cost associated with its use. . Helping power popular websites like Pinterest,, and Netflix, NGINX primarily focuses on web service, reverse proxy, and media streaming by offering high performance but simple setup. In addition, Redis is primarily used as a “database, cache, and message broker”. It is known for its speed and support for almost all coding languages ​​and is becoming more and more popular by the day. However, these four open source tools are imperfect and all susceptible to attacks, especially the following CVEs:

Non-stacked tools CVE # Details
SSH CVE-2012-5975 Bypass authentication through a specially crafted session involving entering blank passwords
PostgreSQL CVE-2019-10164 Buffer overflow due to incorrect handling of a malicious user password
CVE-2014-0063 Stack-based buffer overflow related to timestamp analysis
NGINX CVE-2019-12207 Heap-based buffer overflow in utf8 scan
Redis CVE-2018-12326 Buffer overflow in redis-cli which allows code execution and elevation of privileges

In addition to the LAMP battery and these four individual components, it is also important to note the presence and popularity of MEAN and ELK safety batteries. The first was invented “MEAN” in 2013 by Valeri Karpov. It directly references its composition of MongoDB, Express.js, AngularJS and Node.js and offers the advantage of being entirely written in JavaScript, easily deployable and cost effective. Additionally, the MEAN stack is the perfect candidate for cloud hosting and cloud native application development and has been adopted by large companies including PayPal, Netflix, and Uber to facilitate tasks such as expense tracking, location research and news aggregation. The other safety stack was previously known as “ELK”, but is now primarily referred to as the elastic stack. Taking its name from the Elasticsearch, Logstash, and Kibana components, the recent addition of Beats has rounded out the group where it is today. Increasingly popular in open source circles, Elastic Stack is now used by organizations like Box, Walmart, and Pfizer. This is because it offers many advantages in the log analysis space that was previously not satisfied by other stacks, whether it is analyzing these logs, scratching and viewing. data, or even the possibility of a full-text search option. Again, while MEAN and ELK are quite common, they present their own set of issues and are susceptible to vulnerabilities like those detailed above.

The many vulnerabilities in some of the most popular open source security stacks can lead most non-technical users, and even some developers or security teams, to perceive open source code to be inherently insecure. That said, open source security isn’t all pessimistic. These vulnerabilities only signal users that there are indeed cyber risks involved, similar to all aspects of technology, but there are other tools and processes specifically designed to mitigate these risks. Installing updates frequently, prioritizing secure coding, and using automated tools to detect and remove potential vulnerabilities as quickly as possible in the development process are just a few ways to mitigate the risks associated with the use of open source. Regardless of the specific tool used to harden software against vulnerabilities that exist within open source security stacks, organizations that use LAMP and other security stacks need to keep abreast of the risks involved in order for development and innovation happens smoothly, securely, and without error.



Leave A Reply