Limited local file inclusion with .mailmap symlinks and git-archive

Git's mailmap implementation first tries using the blob from the repository, but also supports using a local (possibly uncommitted) .mailmap file. When reading from the local file, git will follow symlinks. If a symlink is committed to a repository named .mailmap, git will parse the file on the other side of the symlink if the repository is cloned locally.

Git log supports an %aN placeholder which prints the result of the mailmap, if it is possible for this value to be sent to an attacker this could become a local file inclusion concern. With git-archive it is possible to use $Format:%aN$ to include this value in an exported archive.

Running git on bare repos or using git archive --remote=... is unaffected because a local file is never used, only the in-repo blob.

Git's mailmap parser is very forgiving, it reads in each line, skips lines starting with #, then considers whatever it finds between < and

.mailmap. As a demonstration I used a symlink to /proc/self/exe (which itself is a symlink to /usr/bin/git). The string [--exec-path[= was extracted from the binary as the author name.

git init mailmap cd mailmap ln -s /proc/self/exe .mailmap echo "test export-subst" > .gitattributes echo '$Format:%aN$' > test git add .mailmap .gitattributes test git commit -m "test" --author="foo <path>" cd ..

# Pretend you're cloning from the internet... git clone mailmap mailmap-clone cd mailmap-clone git archive --format=tar HEAD # Output contains [--exec-path[=

These are unaffected:

cd .. git --git-dir=mailmap/.git archive --format=tar HEAD git archive --remote=git://localhost/ --format=tar HEAD

I reported this issue to the private security list first and discussed this issue with Peff. This is similar to existing concerns with .gitmodules, .gitattributes and .gitignore. Git already disallows checking out a .gitmodules file from a repository, and I understand there are in progress patches to add similar protection for .gitattributes and .gitignore. Please ensure the .mailmap file gets similar symlink protection.

Exploitability is limited because the targeted file must contain a string formatted like <foo> known to the attacker, or attacker controlled. Also, most automated build systems that checkout code are sandboxed and prepared to run arbitrary code already (it is technically possible to read potentially sensitive variables from /proc/self/environ with this, but is very limited because it contains null bytes).

-- Blake Burkhart