There are thousands of open source security vulnerabilities reported every year. But in this week’s post, we’re running down the most talked open source security vulnerabilities of the past year, as well as a few that you maybe should have been talking about.
We prioritized the different open source vulnerabilities based on popularity and usage of the affected libraries, CVSS score, and we even analyzed the search volume as a parameter for popularity. Therefore, only the nastiest of bugs which impacted open source security and caused a stir in the open source community got into our list.
So without further ado, here are the 7 most talked about severe open source security vulnerabilities of 2016…
#1 Glibc Vulnerability
CVE-2015-7547 – CVSS Score 8.1 (February)
Topping our chart of the most talked about open source security vulnerabilities is the Glibc vulnerability.
Glibc, the GNU C library at the heart of 2015’s Ghost vulnerability, was found to be vulnerable to yet another critical flaw in February this year.
This open source security vulnerability affected all Linux servers and web frameworks such Python, PHP, Rails as well as API web services which use the GNU C library. The bug enabled hackers to compromise apps via a man-in-the-middle attack, with the possibility of taking control of a user’s system which accessed a hacker-controlled DNS host.
What made this bug particularly nasty was that it was introduced to glibc 2.9, way back in 2008. This, meant the bug was around for 8 years until it finally popped up our radars!
To make matters worse, glibc is not only the standard implementation library for C++ and C, but also one the of the oldest open source libraries out there. This means glibc is contained within an untold number of systems.
Thankfully, RedHat moved fast and issued a patch within a few days of Glibc’s disclosure.
Affecting over 900 million Android phones, the Quadrooter set of vulnerabilities were one of the heaviest hitters in this year.
For Quadrooter to do its thing, the user needed to first install a malicious app. Yet unlike other malware, the app required no special permissions, meaning the user’s suspicions weren’t raised.
After the malware’s installation, the attacker could gain root access to the device by exploiting any of the four vulnerabilities. This put all system contents and controls (including sensitive data, microphone, GPS and system changes) at risk of exploitation.
All but one of the bugs were patched in Google’s August update, but one missed the cut. This was due to manufacturers taking Android code from Qualcomm, rather than directly from Google.
Even though the remaining bug was patched in Google’s September update, the initial delay highlights the ongoing challenges of issuing timely updates for an open source operating system.
#3 Drown Attack
CVE-2016-0800 – CVSS Score 5.9 (March 2016)
When open source security vulnerabilities start to have their own logo, you know you’re hitting the big leagues.
The CVSS score for this severity wasn’t serious, yet with Drown affecting HTTPS, as well as other services relying on SSL and TLS, the sheer scope of this vulnerability means it forced its way into third place.
At Drown’s height, 33% of all HTTPS websites were affected by this vulnerability- that’s about 11 million websites. To get an idea of some of the top websites which were affected, just a click here.
The whole point of the HTTPS web protocol is to make the internet more secure, right? However, when Drown burst onto the scene, HTTPS may have just given users a false sense of security.
The vulnerability exploited a flaw in SSL v2, allowing attackers to break HTTPS’ encryption, and consequently steal sensitive communications such as usernames, passwords, credit card numbers, sensitive documents etc.
Thankfully, fixing this open source security vulnerability was fairly straightforward. All you needed to do was disable SSL v2 on all your servers and services.
#4 Zero-Day Linux Kernel Vulnerability
CVE-2016-0728 – CVSS Score 7.8 (January)
With our second Linux Kernel vulnerability, things began to heat up in the source community.
This zero-day local privilege escalation Linux kernel vulnerability certainly took Linux by surprise. Especially seeing that the bug had been around since 2012!
This open source security vulnerability impacted all Linux versions 3.8 and higher, as well as 66% of all Android devices. Once the bug was exploited, the attacker could gain root access to the unlucky user’s OS.
#5 Critical MySQL Database Vulnerability
CVE-2016-6662 – CVSS Score 8.8 (September)
In at number 5, this critical MySQL vulnerability affected every available version (5.7.15, 5.6.33 and 5.5.52) of Oracle’s MySQL Database, as well as its clones MariaDB and PerconaDB.
By injecting malicious settings into MySQL configuration files, the vulnerability allowed attackers to gain full access to the server on which the affected MySQL was running. This meant hackers could view, change and even erase any entries they wished.
Not only could this open source security vulnerability be exploited both locally and remotely, but the attacker had the choice of using either valid access credentials (passwords etc), or an SQL Injection attack as vectors.
Seeing as SQL Injection attack is one of the most common issues in web applications, the last vector made this vulnerability particularly worrying.
#6 Linux Kernel Vulnerability
CVE-2016-5696 – CVSS Score 4.8 (August)
Although its CVSS score wasn’t particularly high, the Linux Kernel Vulnerability caused ripples in the open source world.
However, with this open source security vulnerability affecting the 1.4 billion Android devices running Android 4.4 KitKat or later, as well all Linux OS running version 4.6 and earlier, this isn’t surprising.
The vulnerability’s vector of choice was exploiting a weakness in the TCP of all relevant systems. Once exploited, the vulnerability enabled the attacker to degrade the privacy of anonymous networks (e.g. Tor browser), track users’ online activity, hijack a conversation between hosts and even forcibly terminate a conversation.
Luckily, no attacks were actually reported in the wild.
#7 OpenJDK Vulnerability
CVE-2016-0636 – CVSS Score 9.3 (March)
Perhaps this extremely severe OpenJDK security vulnerability should have had a slightly higher profile.
The bug affected all users running Oracle Java SE 7 Update 97, and 8 Update 73 and 74 for Windows, Solaris, Linux, and Mac OS X.
This open source security vulnerability could be remotely exploited without any need for authentication details, such as passwords or usernames. This meant a single visit to a malicious web page could allow an attacker to degrade the availability, integrity and confidentiality of a user’s system.
However, you’ll no doubt be pleased to hear that all affected versions have been updated.
3 Vulnerabilities You Should Have Been Talking About, But Didn’t…
In the course of our research, we came across some particularly nasty vulnerabilities which didn’t cause a raucous in the community. But perhaps they should have.
#1 HTTP/2 Protocol Vulnerabilities
With one of the bugs having a CVSS rating of 10, and 85 million websites at risk from these vulnerabilities, it’s surprising that no one was talking about the HTTP/2 Protocol Vulnerabilities.
The HTTP/2 web protocol was launched in May 2015 as a more secure alternative to the current HTTP protocol.
The HTTP/2 vulnerabilities allowed attackers to flood webservers with innocent looking messages, which in reality contained gigabytes of data. Consequently, these messages allowed attackers to consume all of a server’s memory, slowing it’s processing speed to a crawl, or even causing it to crash.
A reason why these vulnerabilities didn’t cause more of a stir could have been because all vendors were notified of the issues before any details were disclosed. Therefore, by the time the vulnerabilities went public, all flaws had been fixed.
#2 Critical Google MediaServer Vulnerability
CVE-2015-6636 – CVSS Score 9.8 (January)
With more than 475million Android devices affected by the Google MediaServer Vulnerability, this high severity open source security vulnerability really should have caused more of a stir.
The bug was located in Mediaserver, which was particularly serious as this process interacts with many applications (e.g MMS and browser media playback features) that can be used to exploit the bug.
Upon exploitation, the attacker could cause memory corruption, and remote code execution as the mediaserver process.
Unsurprisingly, with Stagefright still fresh in Google’s mind, they were very quick to push out a patch. Perhaps this was why this easily exploitable open source security vulnerability didn’t attract much attention.
#3 Qualcomm Security Flaw
CVE-2016- 2060 – CVSS Score 7.8 (May)
The least severe of our neglected bugs is the Qualcomm Security Flaw vulnerability.
In 2011, Qualcomm introduced new APIs in order to give Android devices improved tethering capabilities. Sounds great right?
Well, in the process of introducing the new APIs, they also unwittingly wrote a security flaw into the code. To exploit, users needed to install a malicious app via such means as a fake download, phishing campaign or a malicious app which had slipped through Google Play’s security net.
Once infected, the attack could interact with the API, siphoning away SMS, phone calls and even web data. Furthermore, the open source security vulnerability didn’t trigger any alerts, as the permission needed to interact with the API is requested by millions of other applications.
Ultimately, with the open source security vulnerability affecting hundreds of Android models due it going undetected for 5 years, maybe this bug should have had more of an impact.
However, with no evidence of the bug being exploited in the wild, perhaps its low profile can be understood.
Are You Secure?
As you can see, all these vulnerabilities have released fixes in the forms of patches, new versions or workarounds. So there really isn’t any reason why you should continue using these vulnerable components. But are you sure you’re not?
If some of these bugs gave you the heebie-jeebies, then you should go and check if your software contains any of the vulnerable libraries and update accordingly.
And remember, if the open source community knows about an open source security vulnerability, so do hackers. Consequently, remediating the situation sooner rather than later is probably a good idea.
Let the ‘open source’ be with you (I hope you can see what I was trying to do there 🙂 )