Eight Is Bad News

If you follow our blog, you probably know that we are all about keeping open-source libraries updated. Development teams use these libraries to develop software, so they don't need to start from scratch. Depending on the language in which it is written, most software uses dozens, hundreds or even thousands of open-source libraries. Our post about the newest OWASP Top 10 reported how using vulnerable and outdated components represents a bigger threat nowadays. What follows is that teams need to establish processes to manage their open-source libraries efficiently.

To no one's surprise, developers have found a way to make their work easier by using package managers. We are talking about systems or tools that help them automate processes related to managing third-party open-source libraries. These processes include installation, upgrade and configuration. What is surprising is that recently, and concurrently, eight popular open-source package managers were reported to have vulnerabilities.

The recent discovery was made by researchers at code security solutions provider Sonar. On March 8, they listed the names, versions, CVE IDs and whether there's already a patch. The affected package managers are Composer, Bundler, Bower, Poetry, Yarn, pnpm, pip and Pipenv.

The vulnerability in Composer, for libraries written in the PHP language, is quite critical, with a CVSS v3 score of 9.8. This package manager's vulnerable versions fail to properly neutralize special elements used in a command. So, a threat actor can execute a command of their choosing by injecting malicious new items into an existing command. This is a command injection attack that results in modifying the interpretation away from what the victim originally intended.

The flaw (CVE-2021-41116) is present in the browse command when running Composer on Windows machines. This command can open a package's source and documentation. Users need to type the name of the package as the argument, and the command will open the URL of that package's homepage. At least it seems. Because this URL can be corrupted by a threat actor to execute several other commands. This includes downloading payloads in the background. The attacker needs to phish the victim into using the package for all this to happen, though. The researchers recommend running commands with argument lists and using reliable escaping functions. This would restrict customization, reducing the risk of suffering an attack.

The severity of Bundler's vulnerability (CVE-2021-43809) is high, with a CVSS v3 score of 7.3. When victims invoke git commands, that allows interpreting several user-controlled arguments that could be maliciously crafted. What attackers could do is create a Gemfile (i.e., a file that describes the libraries —gems— used in a program) declaring a dependency that is located in a Git repository. But also injecting arguments that would fool Bundler into executing malware. Again, attackers need to phish the victim; in this scenario, into using the malicious Gemfile. As it requires considerable user interaction, exploitation is not as easy as in the relatively straightforward command injection, making it less critical.

Imagine a person gives you the exact route to where they ask you to go. Now imagine another scenario: This person doesn't give you any clue other than the name of the destination, say, a Starbucks. When the destination could be any of many, there's confusion. Let's get back to package managers: If you don't specify the path to a file you want to run in the command, the operating system will have to look for it only by its name. Supposedly safe locations are stored in a variable called PATH. Most operating systems will look for the file there, but Windows will look first at the current working directory and then PATH.

What is considered an untrusted search path weakness is present in Yarn, which manages libraries written in JavaScript. The vulnerability in versions up to 1.22.13 allows fetching a file that is outside PATH. If the working directory has an untrusted file with the same name referenced in the command, that means trouble. The researchers mention the possibility of a victim trying to fetch a library from a Git repository by typing only "git" without its path, and there being a malicious git.exe file in the working directory. This would cause Yarn to fetch the malicious file.

The untrusted search path weakness was also discovered in Bower (CVE-2021-43796; affecting libraries in HTML, CSS and JavaScript), pnpm (JavaScript), pip (Python) and Pipenv (Python). But also in Composer and Poetry.

pip and Pipenv decided not to fix this issue. Reportedly, because "there are several other ways [...] an attacker could gain code execution in the same attack scenario." Composer didn't have this scenario in their threat model, so they chose not to address it. But the rest did address it. Yarn, for example, now uses a command called where and allows the search to be done only in locations defined in PATH.

What's most interesting about the vulnerabilities we addressed in this post is that developers have to be tricked into fetching malicious libraries. Attackers have to rely on social engineering or sneak malicious files into a trusted codebase. This could sound like a relief, but, in earnest, this whole situation highlights the importance of developers being aware of the libraries they're using and how they behave. It also wouldn't hurt to learn some indicators to have in mind when choosing open-source. All the while, let's remember what's key: Upgrade! Upgrade! Upgrade!

At Fluid Attacks, we help you ensure that the libraries you use in your software have no vulnerabilities. Have you heard about our secure code review solution? Contact us!