
A security vulnerability in Git that can lead to arbitrary code execution - martinwoodward
https://blogs.msdn.microsoft.com/devops/2018/05/29/announcing-the-may-2018-git-security-vulnerability/
======
peff
A few important points that aren't mentioned in the post:

\- you have to tell git to use submodules for this to trigger (so `clone
--recurse-submodules` or a manual `git submodule update --init`)

\- credit for discovery goes to Etienne Stalmans, who reported it to GitHub's
bug bounty program

\- most major hosters should prevent malicious repositories from being pushed
up. This is actually where most of the work went. The fix itself was pretty
trivial, but detection during push required a lot of refactoring. And involved
many projects: I wrote the patches for Git itself, but others worked on
libgit2, JGit, and VSTS.

~~~
ethomson
Thanks, peff, for the feedback. I pushed some changes to try to clarify that
this does indeed require `clone --recursive`, and I added a note to credit
Etienne Stalsman explicitly. That was an oversight in my haste.

~~~
peff
No problem! Thanks for all your work on this.

I should have clarified above, too: there were folks from GitHub, Microsoft,
and Google working on the various fixes.

~~~
ethomson
The Git community is great because even though many of the interested parties
compete with each other in some form or another, we always put that aside. And
that's especially true for security issues.

------
gitlab-security
The monthly security release for GitLab was today, and this release was
coordinated with the Git security release.
[https://about.gitlab.com/2018/05/29/security-release-
gitlab-...](https://about.gitlab.com/2018/05/29/security-release-
gitlab-10-dot-8-dot-2-released/)

In addition to our recently implemented monthly non-critical security release
process (we already had a critical release process before), we are making a
number of changes in how we secure GitLab.com, which includes expanding our
HackerOne program this year to be a public bounty program. As always, we
appreciate the contributions of security researchers.

------
runesoerensen
The initial Git for Windows 2.17.1 releases published on GitHub earlier today
[0] apparently didn't include the patch. So just a heads up if you updated
right after this was published: You probably want to make sure you have the
fixed version (2.17.1.windows.2) [1]

Not sure why the erroneous releases haven't been removed? Seems a bit
confusing.

[0] [https://github.com/git-for-
windows/git/releases/tag/v2.17.1....](https://github.com/git-for-
windows/git/releases/tag/v2.17.1.windows.1)

[1] [https://github.com/git-for-
windows/git/releases/tag/v2.17.1....](https://github.com/git-for-
windows/git/releases/tag/v2.17.1.windows.2)

~~~
mappu
The link on [https://git-scm.com/](https://git-scm.com/) still points to the
old 2.17.0.

Chocolatey has the original 2.17.1, the 2.17.1-2 update is not yet approved.

Cygwin still only has 2.17.0-1. I wonder whether they were even part of the
embargo.

~~~
runesoerensen
For some reason git-scm.com is almost always slow at updating links to new Git
for Windows releases.

I usually just track the repository's atom feed [0] and download urgent
updates directly from there (git-scm.com eventually links to the releases
published on GitHub anyway).

[0] [https://github.com/git-for-
windows/git/releases.atom](https://github.com/git-for-
windows/git/releases.atom)

Edit: The Git 2.17.1.2 Chocolatey package has now been approved
[https://chocolatey.org/packages/git/2.17.1.2](https://chocolatey.org/packages/git/2.17.1.2)

------
0942v8653
Perhaps it would be best if sensitive options such as the post-checkout hook
could only be stored outside of the repository altogether. Given this
vulnerability and the semi-recent .GiT/config vulnerability[0], I would not be
surprised if other attack vectors are lurking under the surface.

Storing config data outside the repo would not be a foolproof solution, but it
would probably make things a little safer. (Having the <repo_root>/.git folder
has always felt a little bit "in-band" to me, and I don't like it.)

[0]:
[https://news.ycombinator.com/item?id=8769667](https://news.ycombinator.com/item?id=8769667)

------
Foxboron
The correct CVE numbers are CVE 2018-11233 and CVE 2018-11235. The microsoft
blog mentions 11234, but thats not the git vulnerability.

~~~
JBiserkov
I know this isn't Reddit, but I can help but point out that 11234 =
average(11233, 11235)

~~~
slrz
That's most likely the result of how CVE numbers are allocated: in sequence.

------
colemannugent
Another reason to train yourself to always think before you execute code you
found on a site.

Too many of us are so used to _git clone_ 'ing a repo and building the
software with _make_ or its descendants that we overlook the security
considerations.

~~~
koolba
> Too many of us are so used to git clone'ing a repo and building the software
> with make or its descendants that we overlook the security considerations.

The issue here is that the "git clone ..." allows for arbitrary code execution
so the flow of 1) clone 2) analyze 3) make breaks at step 1.

Looks like it's back to tarballs for me.

~~~
jacquesm
Even with tarballs all it takes is one fuck-up in a script and your
homedirectory is gone. In that sense nothing is safe. You could of course
audit all the code that the makefile or build script executes but I really
don't know anybody that would do that for anything beyond the trivial.

We've been totally conditioned to just wget some archive, unpack it and build
it, and even if git clone takes it one step further in day-to-day practice
there is no difference between the two.

~~~
shawnz
I think the parent's concern is that there should at least be SOME way to
audit everything. That doesn't necessarily mean that everyone ought to be
doing it every time they clone a repo.

~~~
jacquesm
Most web interfaces to git will allow you to review the repo, if you blindly
clone some repo that someone asks you to clone recursively I would see that
mostly as a social engineering hack with the technical hook than a purely
technical hack.

And depending on the sophistication you might want to do that in a chrooted
environment or a VM.

~~~
tedunangst
There's no way to know if what you see on the web will be what you clone. The
inspection must occur locally.

------
QuinnWilton
Over the past few years there's been a few vulnerabilities in Git that result
from an attacker injecting hooks into a repo. I wonder whether it'd be
possible / worthwhile to disable hooks by default, and only enable them on a
per-repo basis.

Of course, then the goal just becomes attacking that whitelist, and all the
complexity that comes with that. Security is hard.

~~~
chatmasta
A good starting point would be requiring a specific flag when executing any
git command that should be attached to a hook. Something like git clone
—-allow-hooks to enable post-checkout hooks ; or git commit —-allow-hooks to
allow pre/post-commit hooks.

------
jancsika
After reading the responses to my previous question, I'd like to know if
there's a global way to turn off post-checkout hooks.

None of the use-cases I read are convincing enough to allow `git clone` to do
anything but what its short man description says.

I'm not even thinking about security, just basic separation of concerns. If
`git clone` leaves a script-hooked repo in an unusable state for building, I
want to know up front so I can complain to the maintainer and get that problem
fixed.

~~~
ameliaquining
Hooks aren't part of the repo. The only way your copy of a repo will have
hooks is if you put them there.

~~~
Piskvorrr
Not if you `git clone --recursive` an evil repo with anything < 2.17.1 (which
is the point of the article and the reason of this discussion): then your copy
will have hooks that you have _not_ put in.

------
jancsika
What's a (common) example use case for a post-checkout hook?

~~~
ethomson
That's a really interesting question. I tried to think about that when I was
writing this blog post and couldn't really think about anything. Perhaps
setting some permissions on a file or running `chattr` / `setfacl` is the best
idea I had, but I omitted any suggestions because I've never actually used a
post-checkout hook in anger.

~~~
avar
The post-checkout hook gets used for things like concatenating JS and CSS
assets in a repository that's meant to house templates, i.e. a poor man's
invocation of "make" whenever a user does a "git pull" without the user having
to do anything extra.

It can also be used for other cases where you'd like to amend what git does by
default when updating the tree. See this recent thread[1] where some users
want to have mtime behavior on files that's different from git's defaults, and
one way to do that is via a post-checkout hook.

1\. [https://public-
inbox.org/git/20180413170129.15310-1-mgorny@g...](https://public-
inbox.org/git/20180413170129.15310-1-mgorny@gentoo.org/)

------
jokoon
I'm sure there are security experts out there who managed to create tools that
scans source code to find eventual security vulnerabilities.

Although I'm not sure those tools could 'find' and build a vuln, but there
could be ways to analyze an algorithm, and detect that it can do dangerous
things it's not not supposed to do. A little like static analysis works.

I'm sure those tools are already built by the NSA at least, so they just have
to peek into github repos, point out what code is vulnerable, give it to some
developer to make an exploit. Done.

That way the NSA would clearly wins the cyber arms race, versus those pairs of
eyes Torvalds was being quoted for, would surely be obsoleted.

~~~
Vinnl
See: [https://testing.googleblog.com/2016/12/announcing-oss-
fuzz-c...](https://testing.googleblog.com/2016/12/announcing-oss-fuzz-
continuous-fuzzing.html)

------
amaccuish
Cached since I can't load the page:
[https://webcache.googleusercontent.com/search?q=cache:CO48Rd...](https://webcache.googleusercontent.com/search?q=cache:CO48Rd83tw0J:https://blogs.msdn.microsoft.com/devops/2018/05/29/announcing-
the-may-2018-git-security-vulnerability/+&cd=1&hl=en&ct=clnk&gl=uk)

~~~
feb
And the announcement from the Git project is at
[https://marc.info/?l=git&m=152761328506724&w=2](https://marc.info/?l=git&m=152761328506724&w=2).
See also CVE-2018-11233 and 11235.

------
raesene9
So to an extent, this is bad, you can be compromised by a malicious git repo,
however given that most people already trust code cloned from git (or acquired
from similarly untrusted sources like npm, rubygems, maven central etc) it may
not change the equation that much.

If you run code without trusting the author, you're likely going to have a bad
time.

~~~
0x0
Sounds like it could be devastating for shared git hosting like github,
bitbucket, gitlab, and for anyone just mirroring repos.

~~~
raesene9
Unless I'm reading it wrong the attacker still has to have a repo. under their
control, then get the victim to clone the repo.

I'm not saying it's trivial , but more that people execute code from GH and
similar alll the time without reading/evaluating , and this won't do any worse
than that.

~~~
0x0
Let's say you sign up for a free account on a shared git-whatever.example.com
and set it up to auto-mirror a malicious repo you host elsewhere. If git-
whatever.example.com(1) had implemented its mirror feature on top of regular
git, boom and you might get shell access on their server and full access to
any and all private repos stored on the same service.

(1) could be any shared service like gitlab.com, github.com, bitbucket.org,
etc

~~~
raesene9
oh yeah, cool :) I was thinking about the issue from the perspective of an
ordinary user of git, not of services that consume git repo's from other
places.

I guess this will make some bug bounties for researchers who can find services
that haven't patched quickly...

~~~
0x0
Seems like this actually happened on github:
[https://twitter.com/_staaldraad/status/1001542421161930752](https://twitter.com/_staaldraad/status/1001542421161930752)

------
lvangool
Hmm - the "official" git PPA isn't updated yet: [https://launchpad.net/~git-
core/+archive/ubuntu/ppa](https://launchpad.net/~git-
core/+archive/ubuntu/ppa). Wonder if this due to dependencies or oversight?

~~~
lvangool
Ps. anyone running debian strech can get this via stretch-backports:

    
    
      echo "deb http://ftp.debian.org/debian stretch-backports main" | tee /etc/apt/sources.list.d/stretch-backports.list 
      apt-get update
      apt-get -t stretch-backports install git

------
testplzignore
Am I the only one who didn't even know git submodules and recursive clones
were a thing?

------
elfchief
What the link doesn't mention, that I can see, is what the first version
affected was. Does this bug go back to the inroduction of submodules in git?

------
empath75
Page is down -- anyone have a mirror?

~~~
AdmiralAsshat
Surely Microsoft should have enough resources to survive the usual HN-hug-of-
death?

~~~
reitanqild
Maybe HN, Reddit and /. struck at the same time?

------
Froyoh
It's probably not worth upgrading anyways.

------
chris_wot
What I really love about this is that they give details of the vulnerability.
They never do this in any Microsoft security advisories.

Guess when it's not your direct product this is OK.

