Open Source technologies are becoming the backbone of all modern day solutions. It has huge advantages since the “write-once and use it across the board” approach fosters code reuse. In many cases these open source technologies get extended to adapt to specific requirements and customizations, this has similar traits to polymorphism brought in by modern day object oriented programming languages.
As always there are some ill-effects of this approach which are becoming increasingly apparent due to the following factors. Let’s look at them in the following section. But lets first start by weeding out a common perception / myth,
“We might bundle a vulnerable library but we actually dont use it, so we are fine”
Nothing can be farther from truth than the statement above. Arbitrary code execution vulnerability can result in potential exploitation of any library accessible to the runtime code. In native apps, this problem is particularly acute as gaps in bindings between native code and the runtime app can be used to escape sandboxing, gain access to other apps ( even system apps like calendar, email etc ) or gain control of the device by planting malware that can communicate to attacker controlled server.
Note: The term project referred here-forth refers to a source code repo or package that is available for public consumption.
-
Multiple projects relying on the same library across different versions
If one analyzes open source projects from different organizations, there are around a dozen libraries that increase the vulnerability exposure of those projects. This is mainly due to the fact these projects depend on the same set of libraries with different versions.
Taking Java Script as an example, multiple vulnerable versions of,
handlebars, lodash, sshpk, js-yaml, extend, mixin-deep, serialize-javascript, elliptic, http-proxy-agent, concat-stream etc
can be seen if one does a deep inspection of the code repositories using ThreatWatch.
-
Limited control / ability to upgrade library versions of upstream projects
Project owners find it challenging to upgrade versions of upstream projects, as it’s not always clear / evident if upgrading those libraries will break any functionality. So the difficult choice to make is to wait for the maintainer of the project to upgrade it or remove that project from use.
-
Frameworks consuming individual projects which power up bulk of the native and web apps
Popular frameworks depend on a number of projects themselves but latest data shows that they haven’t kept up the versioning to the latest for many of these libraries. This has a multi fold explosive effect as there are only a few of these frameworks that are used as the foundation of most modern apps / websites.
Example, ThreatWatch analysis indicated a total of 121 impacts for various libraries consumed by react-native either directly or via its dependencies. Similarly others like katlas.io , a distributed graph based platform by Intuit and polly.js , a library that allows recording and replay of HTTP interactions by Netflix was found to have 90 and 135 impacts respectively via unpatched third party libraries.
-
Containers bundling multiple layers of vulnerable software
Container is the preferred choice when it comes to making your code / service available to your users. It’s easy for users to pull the image and get the service up and running in no time. This also means no time spent in dependency resolution as the container bundles everything from the right OS libraries , application code / business logic , webserver and client side rendering software.
Each of these layers need regular updates to libraries to patch against vulnerabilities. The service provider needs to have the tooling that can work across these layers / technology stacks and make it available to the appropriate teams or individuals for applying mitigations.
Lets take the example of Jenkins , a very popular open source automation server. Jenkins offers its services via a Debian docker image and packages its automation server and user interface ( blueocean ). Beyond Jenkins core there are hundreds of plugins available for users to add and consume. The plugins themselves can be vulnerable and Jenkins publishes advisories for its core engine and plugins at regular intervals. However all these components also rely on third party libraries directly or via dependencies which largely goes unnoticed / un-patched based on data that can be seen below
jenkins/jenkins container image
jenkins-automation-server github
jenkins-blue-ocean github
-
Licensing constraints having transitive effect
License type constraints vary to a large degree from permissive to weak copyleft to strong copyleft. Down stream consumers of these projects are not always aware of this fact and include third party libraries without due checks or satisfying the licensing requirements. As an example, any software that packages another package with strong copyleft requirements needs to be open sourced as well.
Examples, some npm and ruby modules such as stylint , fobject, gnureadline, po2json , eventmachine are strong copyleft GPL licensensed requiring its consumers to open up thier source code as well, while other’s like node-forge, node.extend have dual license ( eg. GPL + MIT / BSD )
-
Lastly, Secrets in code
Some use cases of open source is to enable faster SDLC and an ability to move data , files across different systems and now on cloud. While this is good, analyzing what the open source library is accessing and how is equally important. Shared secrets, API tokens, AWS keys , passwords, misconfigurations in open source code is like an open invitation for disaster.
If you would like to scan your own private or public code repositories or to learn about ThreatWatch offerings in this space write to us at info@threatwatch.io