Security Stack Vulnerabilities: Blame it on Insecure Open Source Code

According to recent research, open source vulnerabilities rose by almost 50% in 2019 over the previous year.

cloud native security

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 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 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.


SHARE
Doug Britton

Doug Britton is Chief Technology of RunSafe Security and a member of its board of directors. As RunSafe’s CTO, Doug plays an essential role in showcasing how RunSafe’s technology changes the economics of cyber defense, and he has been instrumental in driving the RunSafe technology strategy and roadmap, the development of its patent portfolio and IP strategy, managing software development teams, and building a world-class security research team.

Prior to RunSafe Security, Doug founded Kaprica Security which sold its Tachyon business to Samsung. He has also managed large-scale security research, reverse engineering, and exploit development programs for Lockheed Martin and SAIC. A trained computer scientist, Doug started his career in the National Center for Supercomputing Applications at the University of Illinois, before serving as a Russian Linguist and Interrogator in the US Army. He has also earned an MBA from University of Maryland and mentors several entrepreneurs and students launching their business.