Full Report
The author got code access from a friend to some of the Mozilla infrastructure. They use SCM for version control, which is where the bug is at. pash appears to be a small shell that was used for handling SCM operations for hg.mozilla.org. One function allows users to clone private repos of a given user. The user controls some input being read via SSH. In particular, the user is completely user controlled. When checking to see if the user exists via ldap, the author thought they had LDAP injection at first. However, characters necessary for this were being filtered out. So, what can we do? When doing the processing, the filtration can be bypassed by injecting in nullbytes. The interpretation of the nullbyte will stop the processing within the filtering calls. It should be noted that the nullbyte is encoded and escaped for the LDAP syntax. However, when being used in the LDAP query, it's interpreted like normal. What does this mean? The filtering of the bad characters in the LDAP query can be bypassed to get LDAP injection. With the LDAP injection, we can trick the query to return true with our user but contain other malicious information. In particular, command injection can be done within the rest of this script, which assumed that no user could have malicious characters. To me, the filtering on the command should have been done no matter. You can't rely on valid users, as issues like this one may occur. I asked the author how they thought of this issue. The author said he was reading LDAP specifications, saw you can encode arbitrary bytes then just tried it on their local environment. To me, the takeaway is just trying lots of things and seeing the results of this with a good test env.
Analysis Summary