Hacker News new | past | comments | ask | show | jobs | submit login
Server and Client RCE in Git version 2.7.1 and below (seclists.org)
139 points by breadtk on March 15, 2016 | hide | past | favorite | 29 comments



A couple of thoughts on the potential impact: https://ma.ttias.be/remote-code-execution-git-versions-clien...

Server-side: github & bitbucket will get patched quickly, if they're even still vulnerable. Self-hosted installations like Gitlab will be more difficult, as it requires sysadmins to patch themselves. History has thought us this takes too long.

Client-side: possibly the biggest impact, as nearly every Linux distribution ships vulnerable versions. Any kind of local system user activity could trigger the RCE. Technically, that includes any PHP, Ruby or Python site that allows shell commands to be executed - which, by default, they nearly all do.

It has all the potential to be huge.


  >  includes any PHP, Ruby or Python site that allows
  >  shell commands to be executed
So any site already vulnerable to arbitrary command execution will now be vulnerable to RCE via arbitrary command execution? If your site currently allows arbitrary shell command execution the game was already lost.

  >  It has all the potential to be huge. 
Really? The vulnerability on the client side is limited to a very small percentage of the internet users. Furthermore these users are much more likely to be aware of the vulnerability and upgrade compared to grandma and her flash plugin. The story is not that different on the server. The number of publicly accessible git daemons pales in comparison to apache or services that use openssl. As mentioned above this does not really change anything for sites that allow arbitrary shell command execution.

Running around like chicken little saying the sky is going to potentially fall is not productive and in the long run will probably not bring about the desired result for your page views...


At GitLab this was fixed with https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/3240 which we plan to release tomorrow in 8.5.7 https://gitlab.com/gitlab-org/gitlab-ce/issues/14308


You can already download the fixed packages of 8.5.7 right now.



Nice, thanks for the fast response!


You're very welcome.


Note: if you're using Ubuntu, there is a semi-official PPA that has a non-vulnerable version (2.7.3): https://launchpad.net/~git-core/+archive/ubuntu/ppa


But a fix should come via the normal update channel soon? I'm on wily, should I expect to add this PPA or risk vulnerability?


Ubuntu should announce the fix at https://www.ubuntu.com/usn/ but I can't load the page right now.

(removed DSA link as per advice below)


That Debian advisory is a different, older vulnerability. Looks like they know about it but haven't released anything yet:

https://security-tracker.debian.org/tracker/source-package/g...


Oops, thanks.


https://bugs.launchpad.net/ubuntu/+source/git/+bug/1557787 is the tracking bug for this issue. Seems like it's fixed on xenial but not yet in older releases.


Unfortunately it looks like the distros have not been particularly diligent about releasing a fix via the security channel (according to the article), so this PPA is a workaround


Times like this i'm glad i'm still on Mercurial (no `strcpy` overflows in Python). Is anyone planning on writing a DVCS in Rust?


Yes, pijul: https://pijul.org/


Almost certainly.

Which reminds me of a (partial) Haskell git implementation: http://stefan.saasen.me/articles/git-clone-in-haskell-from-t...

Previously posted to HN a number times, e.g. https://news.ycombinator.com/item?id=8713328


It wouldn't have to be a new DVCS. It could be a Rust implementation of Git. e.g. Java Git implementation (JGit) used by Eclipse, Gerrit, etc.


Pijul, linked in a sibling comment, appears to actually be a Rust implementation of Darcs (or at least inspired by it).


Pijul is not a reimplementation of darcs, it's based on a new theory, without the performance drawbacks of darcs.

Btw, rewriting darcs would really feel like reinventing the wheel. Haskell is safe and great already.



Sounds like this could be a big deal for bitbucket.org and gitlab.com? Esp. considering private repositories there.


For sure a big deal, we're deploying GitLab.com as we speak https://twitter.com/gitlabstatus/status/709888872549847040


And GitLab.com us updated. If someone finds anything please contact us https://about.gitlab.com/disclosure/


BitBucket Cloud is currently on Git 2.1.1.1.g1fb337f (Version Info link in the footer https://bitbucket.org/support). Anyone know what about GitHub?


Public mirror here if the official ones go down: https://marc.ttias.be/oss-security/2016-03/msg00180.php


Git kind of implies that you're going to execute something from the remote end anyway so it's not something like hartbleed....


Remote code execution is worse than Heartbleed.


Oops, my bad. I didn't realize this was a server side issue, that is pretty bad.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: