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.
sigh….
Have a read about the truecrypt creator being Satoshi. Who knows if it’s real, but a really good story anyway!
Sounds fun. Got a link?
This was the article. Agree may not be real, but I’d watch this movie!
https://www.investinblockchain.com/new-evidence-suggests-satoshi-nakamoto-is-paul-solotshi-the-creator-of-encryption-software-e4m-and-truecrypt/
Sometimes truth can be more interesting than fiction: TrueCrypt uses code from a program called E4M, developed for a company in part by, and then leaked to the public by, Paul “Mastermind” Le Roux.
why not just get rid of unicode?
sorry emoji creators you will have to find another way to embed emojis
I was being snarky about it in the article. Unicode is also how we have letters with accent marks, Greek letters, and a bunch of really useful other letters and symbols.
Reminds me of the tome that’s the O’Reilly Unicode book.
I agree. The simple and complete 8 bit ASCII set is really all we need/needed to get the job done.
Not really, unicode is needed to represent 10,000’s of characters of all written languages.
Except that 8 bit ASCII doesn’t exist. ASCII is 7 bit. There are various different extended versions using the upper 128 characters as well. And that’s how we got in the code-page mess, which unicode pretty much seeked to solve, and does so quite well in general.
if you write/read English, yes. But interestingly some humans can use different languages to communicate. I heard.
This being said, I will agree with you after the technological singularity occurs. Humans and charsets won’t make sense anymore.:-P
I watched the video all the way through even though much of it was way too arcane for me. For much of what was said, I understood the basic principles (which is what they try to teach you in school), but the variations and esoterica just make it almost incomprehensible. Why are there so many variations on a theme (i.e. why is it important to be able to the same thing in enumerable ways)? It’s crazy. Are their utility worth the effort and risk? I wonder, especially when too many times there are negative unintended consequences, often “hidden” and waiting to be exploited. I don’t think that obfuscated code like this serves any greater good. Too scary.
You seem to think that there is someone “in charge” who is not doing their job to keep stuff organized and neat, but in fact this is just how stuff happens when you are a human being. It is the same in every discipline, you can make the exact same complaints about railroads or power distribution systems or sewage treatment systems or your mother’s kitchen. What would be your plan if you answer “no” to your rhetorical question “is it worth the risk”? Just curious.
You oversimplify. For any critical infrastructure, be it software, industry, or whatever, there is or should be someone in charge — someone who cares that there are no latent errors, especially ones that can compromise safety and/or security. If talk as if everything is a hack and there is no thoughtfulness in their creation. I worked for 35 years in the aviation industry to mostly software of critical systems that allows planes to fly around the world (before GPS), go from airport to airport, and land planes in inclement weather. Some of that code has been running since 1982 without issue on a old, overworked 8 bit processor with 16 KB of code. Some of the newer stuff has been running since the mid 90’s on a 16 bit micro with 32-48 KB of code. I know that if code generation is trivialized, there would be little confidence in its safety. With all the code space and processor speed available today, it’s so easy to just add stuff that’s “nice to have” or only offers marginal benefit with little regard to safety and security.
“Simplicity doesn’t mean backwardness”
Proved again.
Layer upon layer of software cruft, piled upon layer upon layer of incompetence, and we are supposed to trust all this is secure?
Who exactly told you that you are supposed to trust any of this?
The Nginx one will be interesting to watch as it will probably have an effect on what your employer can lay claim to. It will be interesting to see where they were when they wrote it, as different states and jurisdictions can sometimes have different rules.
“GitHub stores all email addresses in their lowercase form.”
Aren’t email addresses technically case sensitive? At least the local part (the “username” before the @ sign?) I was under the impression that although most mailservers are configured to map uppercase addresses to lowercase equivalents, this behavior isn’t guaranteed, so it seems dangerous to assume it generally…
No. User names and email addresses are not generally case sensitive.
The original author not being politically correct was the downfall of TrueCrypt not anything from audits… The accurate parts of this news is pretty old…
Say what? You have a source for that?