More thoughts on CVE-2014-9390

I'm still muddling away, trying to understand CVE-2014-9390.

One thing that's weird is that if you go to the MITRE CVE database for CVE-2014-9390, you get: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-9390:

** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem. When the candidate has been publicized, the details for this candidate will be provided.

And if you follow the link to the National Vulnerability Database, you get: National Vulnerability Database: Unable to find vuln CVE-2014-9390

Is this unusual? I thought that, since two months have passed since the disclosure, I'd be able to find this vulnerability in the public databases by now.

How long does it usually take?

Meanwhile, I've been amusing myself by trying to understand the vulnerability in more detail.

One very interesting article in this area is on the Metasploit blog: 12 Days of HaXmas: Exploiting CVE-2014-9390 in Git and Mercurial.

Both Git and Mercurial clients have had code for a long time that ensures that no commits are made to anything in the .git or .hg directories. Because these directories control client side behavior of a Git or Mercurial repository, if they were not protected, a Git or Mercurial server could potentially manipulate the contents of certain sensitive files in the repository that could cause unexpected behavior when a client performs certain operations on the repository.

Another Metasploit-related article is on the Packet Storm Security blog: Malicious Git And Mercurial HTTP Server For CVE-2014-9390

This Metasploit module exploits CVE-2014-9390, which affects Git (versions less than 1.8.5.6, 1.9.5, 2.0.5, 2.1.4 and 2.2.1) and Mercurial (versions less than 3.2.3) and describes three vulnerabilities.

I'm particuarly interested in the HFS+ aspects of the vulnerability.

Although this vulnerability received massive attention as a git issue, it was actually discovered by the author of Mercurial (Matt Mackall), so I tried digging into the Mercurial-related info for more clues.

In the fix notes for this problem for Mercurial, it seems that the bug arises when manipulating a UTF8-encoded filename string.

Meanwhile, a close reading of the git patch indicates that for git, the bug also involved UTF8-encoded filenames.

And Augie Fackler's patch includes reference to an ancient Apple Technote 1150 which might give some more clues about when the HFS+ filesystem has this vulnerability.

I found a copy of that technote here: Technical Note TN1150, and it contains this little bit:

In HFS Plus and case-insensitive HFSX, strings must be compared in a case-insensitive fashion. The Unicode standard does not strictly define upper and lower case equivalence, although it does suggest some equivalences. The HFS Plus string comparison algorithm (defined below) include a concrete case equivalence definition. An implementation must use the equivalence expressed by this algorithm.

Furthermore, Unicode requires that certain formatting characters be ignored (skipped over) during string comparisons. The algorithm and tables used for case equivalence also arrange to ignore these characters. An implementations must ignore the characters that are ignored by this algorithm.

A more relevant section of that document is probably the Unicode Subtleties section, where we read:

To reduce complexity in the B-tree key comparison routines (which have to compare Unicode strings), HFS Plus defines that Unicode strings will be stored in fully decomposed form, with composing characters stored in canonical order. The other equivalent forms are illegal in HFS Plus strings. An implementation must convert these equivalent forms to the fully decomposed form before storing the string on disk.

I'm not sure what any of this means (I worry that I'm approaching the state of "fully decomposed" myself, nowadays), nor do I know whether to trust a random copy of a 10-year-old Apple document. But perhaps what it's saying is that this vulnerability is specific to a code path where you might pass UTF8-encoded filenames to the operating system?

On a relatively modern Mac, running 'man 2 open' just says:

int open(const char *path, int oflag, ...);

DESCRIPTION

The file name specified by path is opened for reading and/or writing, as specified by the argument oflag; the file descriptor is returned to the calling process.

Nowhere obvious in the 'man 2 open' output is anything about the encoding of the filename that you provide to open().

Filename encoding on HFS+ is obviously confusing to many, as witnessed by these StackOverflow questions:

• Different utf8 encoding in filenames os x
• How to enter special characters so that Bash/Terminal understands them?

And the Mac filesystem in general is an object of fascination to many: here's a great old article by John Siracusa on Ars Technica: The state of the file system.

I suspect that the bottom line is that certain aspects of CVE-2014-9390 are going to remain opaque to me.

There are just too many things to learn, and not enough time.