This has the potential to be huge: server and client side remote code execution through a buffer overflow in all git versions before 2.7.1 2.7.4 (see update).
Ok the bug works by pushing or cloning a repository with a large
filename or a large number of nested trees.
[…]
The point is affected versions are still shipped as part of many
distributions as part of their stable branch, so I think it’s
important to get a ᴄᴠᴇ for public awareness.
This could impact git hosting services like Github or Bitbucket but potentially worse are installations like Gitlab, that can be self-hosted. If you operate a Git repository server, you may want to keep an eye on this vulnerability and patch whenever updates are available.
Update 16/03/2016: Gitlab.com confirms they’ve upgraded already. The updated packages are available for download for self-hosted installations.
If you’re running Gitlab, you want to be on version 8.5.7 at a minimum!.
This version raises the minimum required Git version to 2.7.3 to address the recent remote code execution vulnerability. The Omnibus packages have been updated to include this new version.
Git Server exploitation
In order to push to a remote git repository, you need write access which for most git servers would require some kind of authentication / authorization first. However, for services like Bitbucket or Github where you can create or clone a repository without approval from an admin, the consequences could be bigger as anyone can attempt to trigger the vulnerability.
Then again, both Bitbucket and Github have the (human) resources to deal with this vulnerability in the quickest way possible, those self-hosted git hostings may not …
Git Client exploitation
The bug can also be triggered by cloning a repository with large filenames.
To clone a repository you just needs a local user account on a Linux or Windows machine with access to the git binary. This leaves the door wide open for, well, pretty much everyone. If you allow users to execute arbitrary code on your servers, you could have a problem (think of PHP’s exec(), system(), … calls). (1)
Any system with local users that allows the execution of git client commands should be carefully watched.
(1) Well, if you allow any user to execute any kind of code on your servers, you probably have more than just this git vulnerability to be aware of – just saying.
Everyone’s vulnerable?
Debian is one of the first to show which systems are vulnerable.
It’s safe to assume right now, pretty much everyone is vulnerable: Ubuntu, CentOS, Red Hat, …
Update: it hits all versions < 2.7.4, not 2.7.1
Due to a miscommunication, the vulnerability got disclosed before the code got patched publicly.
Oh………………………… Big mistake. I might advertised too soon.
I saw changes were pushed in master, so I thought the next version (which was 2.7.1) would be the one which will include the fix.
But as pointed out on https://security-tracker.debian.org/tracker/CVE-2016-2324 no versions including the fixes were released yet, and even 2.7.3 still include path_name(). I didn’t checked the code (Sorrrry).
The good news, on the other hand: the vulnerability got fixed in git 2.7.4.
The same set of bugfix patches from the current
‘master’ have been backported to older maintenance tracks and are
available as v2.4.11, v2.5.5 and v2.6.6. These are to fix a heap
corruption / buffer overflow bug and users are strongly encouraged
to upgrade.
Next up: have all package maintainers update or backport their packages to include this fix!