January kicks us off with a number of high profile projects that should ring some bells, reporting vulnerabilities which are worthy of our attention and remediations.
WhiteSource’s Knowledge Group has been hard at work, pouring through our lists of newly collected vulnerabilities to bring our readers the info they need to keep their open source usage secure.
The team reviewed all the new issues that have been added to WhiteSource’s database, which are aggregated continuously from multiple sources including the National Vulnerability Database (NVD), and additional publicly available, peer-reviewed security advisories and issue trackers.
Hopefully, your development and security teams have been keeping their products up to date with the latest and most secure versions, but it never hurts to check our list for any security alerts that might have slipped through the cracks over the past month.
Vulnerability Score: Medium — 6.5
Affected versions: Versions before 18.09
Containers have been one of the hottest topics in development in the past year, with no sign of slowing down as we roll through 2019. However, along with the excitement over how they allow for smoother flow from development through deployment, we are starting to understand that they have some of their own risks which need to be accounted for along the way.
At the tail end of 2018, a significant vulnerability in Google’s Kubernetes open source controller for container orchestration was found, catching plenty of folks off guard as Kubernetes has become a core infrastructure tool throughout the industry.
Now another primary provider of container services has been found with an uncontrolled resource consumption vulnerability, while not a serious one in particular, it’s a reminder that the tools we depend on can be vulnerable to attack. For years now, Docker has been one of the leaders of the container revolution, so this vulnerability is likely highly relevant for your development and production.
According to the findings by MITRE, this vulnerability could allow attackers to cause a denial of service (DoS) via a large integer in a –cpuset-mems or — cpuset-cpus value, related to daemon/daemon_unix.go,pkg/parsers/parsers.go, and pkg/sysinfo/sysinfo.go.
The good folks at Docker have already released a fix with version 18.09, which is available here on their GitHub page.
Vulnerability Score: Medium — 5.5
Affected versions: jQuery.terminal versions before 1.21.0 are considered as vulnerable
Described as a plug-in for creating command line interpreters in web applications, the jQuery Terminal Emulator provides added functionalities for power users, allowing them to automatically call JSON-RPC service through typing commands, or for giving users the ability to provide their own function for parsing user commands.
The problem apparently arises when the user attempts to save user input in the DB and do not configure it correctly.
Looking at their GitHub page, the team advises that versions before 1.21.0 are at risk. In the updated version, they have disabled the execution of terminal methods using extended commands [[ terminal::clear() ]] by default. If you want the terminal echo, you will have to turn it on by default. However, they warn that if you want to use it safely, be sure not to save user input in the DB or echo back to other users. Escaping formatting is also an option.
For more information on how to use this popular project safely, visit their GitHub page and get the latest version. You can also double check that the invokeMethods is false if you want to be doubly sure that you are using this component safely.
It is worth noting here that this vulnerability is a little bit different than the other ones on the list as we can see from its WS prefix instead of the classic CVE. This is because it was found by the WhiteSource Research team before it was listed on the National Vulnerability Database (NVD). While vulnerabilities generally follow the route of being reported to the folks over at MITRE in order to receive a CVE ID, not all of them end up there. They may show up first on a smaller security advisory or issue tracker that we are following, and are added to our WhiteSource database.
Staying a step ahead of the hackers by picking up on newly published vulnerabilities is at the core of the open source security playbook, so following a wide variety of resources is a crucial element of our database. If you have been following our top 5 monthlies for some time now, you have probably picked up on this trend, and its importance to our reporting.
Vulnerability Score: High — 9
Affected versions: 4.2.x and 4.3.x before 4.3.1
This distributed messaging project claims to allow users to connect their code on any platform in any language. Backed by a large community of contributors, this popular C++messaging engine has hit a snag with a doozy of a vulnerability with an Integer Overflow or Wraparound CWE-type, butting its user at risk or a pointer overflow with code execution attack.
The vulnerability was discovered in the ZeroMQ libzmq versions 4.2.x and 4.3.x before 4.3.1, and could allow an authenticated attacker to use the overflow to wreak havoc by overwriting an unspecified amount of bytes of data beyond the bounds of a buffer. This, in turn, could allow the hacker to execute code on their target with the victims being none the wiser.
The flaw here gives an intruder the capacity to inject OS commands into a data structure located right after the vulnerable buffer, allowing them to exploit the target without the need for one of your more standard buffer overflow types of attacks. The researchers note that the cause of this exposure is due to the way that the memory has been laid out by its designers.
Perhaps the saving grace in this situation here as noted by the ZeroMQ team is that the attacker needs to have authentication and know in advance valid addresses in the peer’s memory if they want to jump there. So even if the result of this kind of attack could be harmful or even downright dangerous when exploited to intercept or otherwise mess with a sensitive target’s messages, there are accessibility hurdles that raise the bar on this kind of attack that keep it from reaching a full-blown 10 rating on the old CVSS charts.
This vulnerability thankfully has a fix available in version 4.3.1, so upgrading should do the trick here. They also note that measures like ASLR should also help as an effective mitigation to the attack, but we still advise you to upgrade the version.
Vulnerability Score: Medium — 6.8
Affected versions: Versions prior to 69.0.3497.81
Google’s web browser needs no introduction. Chances are that you are probably reading this post on Chrome.
Given the amount of code in this product, we are bound to come up with some significant vulnerabilities here and there, so it should come as no surprise that an interesting one has already popped up this early in the year.
It is worth noting two points about the importance of accessibility as a factor in how we model risk for this CVE. First is that this vulnerability allows a remote attacker to execute their action, thus raising the overall threat here for the potential victim. However, at the same time, the attack requires action from the target in order to be executed, hopefully lowering the risk. Unfortunately, we have learned that this does not have to be a significant barrier for attackers given the success of phishing campaigns in recent years, and this should serve as a reminder that we all need to take responsibility for our own actions and security.
Chrome being Google, the easiest way to get yourself in the clear is simply to update Chrome to version 69.0.0347.81. There is not a lot of configuration needed here as they make it pretty easy to update.
While Chrome is still an open source project, Google’s ample resources give them an edge over projects that are maintained by volunteers in the community. Their Project Zero has been racking up vulnerabilities for their projects as well as others for some time now, providing what this observer would argue is an important way of giving back to the community, making it more secure than before. They also have the cash on hand to pay out bug bounties, so Brendon Tiszka who reported this particular CVE walked away with the top payout for this recent release, taking home $5,000 in hand for his find.
Good job Brendon.
Vulnerability Score: Low — 4.3 Medium
Affected versions: before version 3.4.0
Admittedly, this is a lower vulnerability score than we would normally think to include in this list, but this project is so far-reaching and important that we felt that it would be irresponsible not to mention it.
Bootstrap is a self-described toolkit that has become a go-to for developing front-end applications, making the lives of developers and designers significantly easier, especially when it comes to making sure that their project is responsive for the all-important mobile.
According to the reports, researchers found that it was possible to carry out a cross-site-scripting (XXS) attack in the tooltip data-viewpoint attribute.
The good folks over at Bootstrap already rolled out their fix to this XXS (and possibly others?) in a December update to version 3.4.0. However, this CVE was only published to the NVD in January, reminding us that the NVD should not be our only resource.
Kudos to the team at Bootstrap for getting out ahead of this one like they did, and for including embedded music videos at the top of their blog posts.
One of our key reminders from this month was that even the tools that we think to be well established, forming the backbone of how we develop and use the internet, can still have vulnerabilities pop up.
However, as we know about the open source community and the software that we produce, it’s impossible to push out products that are vulnerability free from the get-go.
Clearly, the goal should be to be sure that the components that we are using don’t contain any known vulnerabilities, and we need to run our own code through the wringer before it gets deployed, but new vulnerabilities will always be uncovered post-deployment as more eyeballs get the chance to examine the code in the wild.
The crucial element is how are we able to find security vulnerabilities and report them to the folks running those projects who in turn can push out fixes in minimal turnaround times. In short, it’s not a matter of where we start when times get tense, but how we respond that counts.
Now it is up to us as consumers of these open source components to take the fixes that are being offered and implement them in order to keep our products secure from those hackers who would try to get the proverbial drop on us by attacking us with the published exploits. Stay a step ahead of the hackers by knowing which open source components your team is using in your products, and take measures to know when new vulnerabilities are published.
We hope that this list can inspire you to go and check if you have any of these vulnerable components in your products.
But don’t stop there. You can easily access the rest of our top 5 vulnerabilities lists from the past year here. Thanks for reading and we’ll see you again next month with more vulnerabilities and fixes.