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 cvedetails.com 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||%|
|Software||Last 5 years||Total vulnerabilities||3 categories||%|
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, WordPress.com, 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|
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.