This Week in Security: Unicode, Truecrypt, and NPM Vulnerabilities

Unicode, the wonderful extension to to ASCII that gives us gems like “”, “”, and “”, has had some unexpected security ramifications. The most common problems with Unicode are visual security issues, like character confusion between letters. For example, the English “M” (U+004D) is indistinguishable from the Cyrillic “М” (U+041C). Can you tell the difference between IBM.com and IBМ.com?

This bug, discovered by [John Gracey] turns the common problem on its head. Properly referred to as a case mapping collision, it’s the story of different Unicode characters getting mapped to the same upper or lowercase equivalent.

'ß'.toLowerCase() === 'SS'.toLowerCase() // true
// Note the Turkish dotless i
'John@Gıthub.com'.toUpperCase() === 'John@Github.com'.toUpperCase()


GitHub stores all email addresses in their lowercase form. When a user sends a password reset, GitHub’s logic worked like this: Take the email address that requested a password reset, convert to lower case, and look up the account that uses the converted email address. That by itself wouldn’t be a problem, but the reset is then sent to the email address that was requested, not the one on file. In retrospect, this is an obvious flaw, but without the presence of Unicode and the possibility of a case mapping collision, would be a perfectly safe practice.

This flaw seems to have been fixed quite some time ago, but was only recently disclosed. It’s also a novel problem affecting Unicode that we haven’t covered. Interestingly, my research has turned up an almost identical problem at Spotify, back in 2013.

TrueCrypt and German Secrets

TrueCrypt is an amazing piece of software that literally changed the world, giving every computer user a free, source-available solution for hard drive encryption. While the source of the program was made freely available, the license was odd and restrictive enough that it’s technically neither Free Software, nor Open Source Software. This kept it from being included in many of the major OS distributions. Even at that, TrueCrypt has been used by many, and for many reasons, from the innocent to reprehensible. TrueCrypt was so popular, a crowdfunding campaign raised enough money to fund a professional audit of the TrueCrypt code in 2013.

The story takes an odd turn halfway through the source code audit. Just after the initial audit finished, and just before the in-depth phase II audit was begun, the TrueCrypt developers suddenly announced that they were ending development. The TrueCrypt website still shows the announcement: “WARNING: Using TrueCrypt is not secure as it may contain unfixed security issues.” Many users thought the timing was odd, and speculated that there was a backdoor of some sort that would be uncovered by the audit. The in-depth audit was finished, and while a few minor issues were discovered, nothing particularly serious was uncovered.

One of the more surprising users of TrueCrypt is the German government. It was recently discovered that the BSI, the information security branch of the German government, did an audit on TrueCrypt back in 2010.

Many governments have now have laws establishing the freedom of information, granting a “right-to-know” to their citizens. Under these laws, a citizen may make an official request for documentation, and if such documentation exists, the government is compelled to provide it, barring a few exceptions. A German citizen made an official request for information regarding TrueCrypt, particularly in regards to known backdoors in the software. Surprisingly, such documentation did exist!

Had the German government secretly backdoored TrueCrypt? Were they part of a conspiracy? Probably not. After some red tape and legal wrangling, the text of the audit was finally released and cleared for publication. There were some issues found back in 2010 that were still present in the TrueCrypt/Veracrypt source, and got fixed as a result of this report coming to light.

NPM Binary Planting

The Node Package Manager, that beloved repository of all things Javascript, recently pushed out an update and announced a pair of vulnerabilities. The vulnerabilities, simply stated, were both due to the lack of any sanity checking when installing packages.

First, the binary install path wasn’t sanitized during installation, meaning that a package could attempt to interact with any file on the target filesystem. Particularly when running the NPM CLI as root, the potential for abuse is huge. While this first issue was taken care of with the release of version 6.13.3, a second, similar problem was still present in that release.

Install paths get sanitized in 6.13.3, but the second problem is that a package can install a binary over any other file in its install location. A package can essentially inject code into other installed packages. The fix for this was to only allow a package to overwrite binary files owned by that package.

The upside here is that a user must install a compromised package in order to be affected. The effect is also greatly mitigated by running NPM as a non-root user, which seems to be good practice.

Google Cloud Shell

Google provides a bunch of services around their cloud offering, and provides the very useful web-based Cloud Shell interface for managing those services. A researcher at Offensi spent some time looking for vulnerabilities, and came up with 9 of them. The first step was to identify the running environment, which was a docker image in this case. A socket pointing back to the host system was left exposed, allowing the researcher to easily escape the Docker container. From there, he was able to bootstrap some debugging tools, and get to work finding vulnerabilities.

The vulnerabilities that are detailed are interesting in their own right, but the process of looking for and finding them is the most interesting to me. Google even sponsored a YouTube video detailing the research, embedded below:

Odds and Ends

Using an iPhone to break the security of a Windows machine? The iPhone driver sets the permissions for a certain file when an iPhone is plugged into the machine. That file could actually be a hardlink to an important system file, and the iPhone driver can unintentionally make that arbitrary file writable.

The Nginx web server is currently being held hostage. Apparently the programmers who originally wrote Nginx were working for a technology company at the time, and now that the Nginx project has been acquired, that company has claimed ownership over the code. It’s likely just a fraudulent claim, but the repercussions could be far-reaching if that claim is upheld.

OpenBSD has fixed a simple privilege escalation, where a setuid binary is called with a very odd LD_LIBRARY_PATH — a single dot, and lots of colons. This tricks the loader into loading a user owned library, but with root privileges.