Earlier this week, we received an automated security notice from GitHub regarding a static blog page the interns made last year.
The vulnerability was due to the Jekyll theme that we were using, which had an outdated version of Rake listed as a dependency. This outdated version had a known command-injection vulnerability, which could potentially allow attackers to run system-level commands on a machine hosting the site files. This vulnerability was flagged as “moderate” severity by GitHub, so I dove in to investigate the issue and figure out how to mitigate it.
The issue was originally reported in this hackerone post. Apparently, the vulnerability was due to the function Rake::FileList, which is a Ruby function that is meant to create a lazy list representing all files in the current directory, for easier manipulation. One line in this function was responsible for opening the files that were passed in:
The “open” command is the culprit in this vulnerability, because it does not validate input that it is given, it simply interprets it as a string and decides how to evaluate it. (source) This means that when a file’s name starts with a pipe character, “|”, the rest of the file name is evaluated as a shell command. This example shows how this vulnerability can be exploited by creating a file named “| touch evil.txt”. when Rake::FileList is called, a new file called “evil.txt” is created. You can imagine how much worse consequences could occur if this vulnerability were used to run scripts, or open up a network connection to an attacker.
Luckily, this vulnerability was easily resolved by developers by changing the “open” command to the more secure “File.open”, as seen in the screenshot above. This change was pushed in Rake 12.3.3, so in order to address this vulnerability, the only change that was needed was to upgrade the dependency version in our project’s theme to 12.3.3.
Luckily, this vulnerability was not a huge threat to begin with, because it is only exploitable during development, (when Rake is being actively used) and furthermore, it requires attackers to already have gained access to the server or the repository, in order to plant the malicious file. So this vulnerability should not be a risk to live, static sites. Additionally, this is a very easy vulnerability to fix, as shown by the version change above.
It was cool to see how GitHub automatically tries to identity and alert you of vulnerabilities in your dependencies. GitHub also provides reference links, and makes it very easy to track down and understand your vulnerability. The only complain I have is that this vulnerability was first reported and resolved in July, 2019, a whole eight months ago. GitHub security alerts were originally introduced in 2017, why is GitHub only flagging this for our repository now?
