Article originally published on DevPro Journal.
The debate surrounding open source code is sure to continue for years to come, and we’ve previously detailed both the high-level pros and cons to utilizing it. But one thing for sure is that the usage of open source is nearly unavoidable today and it’s becoming an integral part of any software development effort. With this in mind, another critical element to consider is the variety of security stacks that exist and are based on open source code. The most common of these stacks is often referred to as “LAMP,” but there are countless others as well as tools that don’t fall into a specific stack. Although each offers its own handful of benefits, they also have their own vulnerabilities, given they’re all built on insecure code.
According to recent research, open source vulnerabilities rose by almost 50% in 2019 over the previous year. Additionally, even though 85% of open source security vulnerabilities have a patch available, more than 50% of open source vulnerabilities don’t receive it for one reason or another, ultimately leaving them open to attack. We are so used to deploying tech stacks and relying on network protections, but if bad actors are assumed to get in, the security is exposed. So what are some of these specific vulnerabilities that exist within the LAMP stack?
The “LAMP” security stack was one of the first of its kind and remains the most commonly used stack. Consisting of Linux as the operating system, Apache as the webserver, MySQL as the database, and PHP as the programming language, LAMP is a classic layered architecture that can host a variety of popular web applications, such as WordPress, Wikipedia, and Drupal, and also offers a great amount of flexibility, such as deployment across multiple operating systems. A LAMP stack also provides users a considerable amount of customization and the ability to scale. However, each of its four components is still open to potential vulnerabilities. According to cvedetails.com and its categorization of vulnerabilities, a large percentage fall into the three categories of memory corruption, overflow, and code execution. The following tables break down the data into the total number of LAMP vulnerabilities, as well as those that fall specifically within three categories, over the last two decades and also the previous five years:
| Software | Number of Years Reporting | 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 | Number of Years Reporting | 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 apparent that Linux vulnerabilities are much higher than the rest of their stack counterparts. This can be directly attributed to the sheer amount of software that is deployed via Linux systems. One of the primary vulnerabilities found throughout the stack is common vulnerability and exposure (CVE) 2015-0235, otherwise known as “GHOST.” It was named after the system functions where the vulnerable code was found and the vulnerability itself is a buffer overflow that was a bug in the GNU C Library (GLIBC). This vulnerability exists on nearly every Linux system and is also loaded into almost every application, placing them all at risk. But GHOST isn’t the only CVE that has recently plagued the components of LAMP. The table below has further description of some other notable vulnerabilities:
| LAMP Stack | CVE # | Details |
| Linux | CVE-2016-7117 | Remote code execution via a 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 | A race-condition in mod_status allows for a 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 | Buffer overflow opportunity as a result of invalid multi-byte 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 such as SSH, PostgreSQL, NGINX, and Redis are also quite common throughout the open source community, offering various benefits, as well as associated vulnerabilities. SSH focuses on encrypting data to ensure that attackers are unable to access user credentials and passwords, while also preventing the spoofing of DNS and IP addresses. Meanwhile, PostgreSQL, formerly known as Postgres, is most known for being the first database management system that utilizes a multi-version concurrency control (MVCC) feature, even prior to Oracle, while needing only very minimal maintenance and low cost associated with its use. Helping to power popular websites like Pinterest, WordPress.com, and Netflix, NGINX focuses primarily on web serving, reverse proxying, and media streaming by offering high performance yet simple configuration. Additionally, Redis is used mainly as a “database, cache, and message broker.” It’s known for its speed and support of almost all code languages and is becoming more and more popular by the day. However, these four open source tools are imperfect and all susceptible to attacks, specifically the following CVEs:
| Non-Stack Tools | CVE # | Details |
| SSH | CVE-2012-5975 | Bypass authentication via a crafted session involving entry of blank passwords |
| PostgreSQL | CVE-2019-10164 | Buffer overflow due to incorrect processing of a malicious user password |
| CVE-2014-0063 | Stack-based buffer overflow related to timestamp parsing | |
| NGINX | CVE-2019-12207 | Heap-based buffer overflow in utf8 parsing |
| Redis | CVE-2018-12326 | Buffer overflow in the redis-cli that allows for code execution and privilege escalation |
In addition to the LAMP stack and these four individual components, it’s also important to note the presence and popularity of the MEAN and ELK security stacks. The first was coined “MEAN,” in 2013 by Valeri Karpov. It refers directly to its composition of MongoDB, Express.js, AngularJS, and Node.js and offers the benefit of being entirely written in JavaScript, easily deployable, and cost-effective. Additionally, the MEAN stack is the perfect candidate for cloud hosting and developing cloud-native applications and has been adopted by large enterprises, including PayPal, Netflix, and Uber, to assist with tasks like expense tracking, location finding, and news aggregation. The other security stack was previously known as “ELK,” but is now mostly referred to as the Elastic Stack. Drawing its name from the Elasticsearch, Logstash, and Kibana components, the recent addition of Beats completed the group to where it is today. Growing exponentially in popularity in open source circles, Elastic Stack is now used by organizations like Box, Walmart, and Pfizer. This is because it offers numerous benefits in the log analytics space that were previously left unfulfilled by other stacks, whether it’s the analysis of these logs, scraping and visualizing data, or even allowing for a full-text search option. Again, although both MEAN and ELK are quite common, they offer their own set of issues and are susceptible to vulnerabilities like those detailed above.
The numerous vulnerabilities across some of the most popular open source security stacks may lead most non-technical users, and even some developers or security teams, to perceive that open source code is inherently insecure. That said, open source security isn’t all doom and gloom. These vulnerabilities only signal to users that there are indeed cyber risks involved, similar to every aspect of technology, but there are other tools and processes specifically designed to mitigate these risks. Frequently installing updates, prioritizing secure coding, and using automated tools to detect and remove potential flaws as quickly as possible in the development process are just a few ways to mitigate the risks associated with open source usage. Regardless of the specific tool used to harden software against the vulnerabilities that exist within open source security stacks, organizations that utilize LAMP and the other security stacks should keep up-to-date on the risks involved to keep development and innovation running smoothly, securely, and without error.
Article originally published on DevPro Journal.
