
Critical security updates for Git, Subversion and Mercurial - mnw21cam
http://marc.info/?l=git&m=150238802328673&w=2
======
jjnoakes
It's interesting to me that the fix was pattern matching the ssh hostname and
banning a starting hyphen, rather than (say) passing "\--" to ssh to signal
the end of the intentional options so a hostname of "-oProxyCommand=whatever"
is interpreted by ssh properly (as a hostname which can't be reached, instead
of as a rogue argument).

I thought this was a fairly well known way to pass arbitrary strings to
commands and ensure they aren't interpreted as options (for commands which
honor "\--", like ssh does).

~~~
peff
We discussed that, but it wasn't clear that doing so was portable. It works
for OpenSSH. It doesn't for PuTTY. We don't know what other implementations
people might have as `ssh` on their systems.

~~~
luckydude
What happens if you do the -- fix and then use PuTTY? If it just fails then
I'd argue that's OK, PuTTY will get updated as a result of the failure, no?

~~~
pwdisswordfish
Why do you think Lennart Poettering is hated so much?

~~~
gazarsgo
+100000

Someone needs to teach the next generation about ABI compatibility...

------
icc97
Kudos to Chocolatey on Windows, they immediately updated their Git package [0]
to v2.14.1, so a simple `choco upgrade -y git` gets me up to date. If only
life on Windows had always been this hassle free.

[0]:
[https://chocolatey.org/packages/git](https://chocolatey.org/packages/git)

~~~
skrebbel
Getting off topic fast, but I always found Chocolatey to be needlessly
complicated and messy.

I was _very_ happy when I found [http://scoop.sh](http://scoop.sh). It's
simpler and slightly less powerful, and most notably it just runs official
installers in the background instead of copying binaries over from the source
and packing them up in a special way.

(It's also at the latest got already)

~~~
jpfed
>Getting off topic fast, but I always found Chocolatey to be needlessly
complicated and messy.

I haven't released it yet, but Napkin solves this very issue.

~~~
kakarot
Would you mind elaborating?

~~~
0xffff2
I really hope it's just a joke about overly opaque project naming, possibly
riffing on the need for a napkin after a "Chocolatey" "Scoop" [of ice cream].

~~~
kakarot
oh damn you're right, I didn't catch the humor. Thanks ~

------
skj
Report from the person who discovered the vulnerability:
[http://blog.recurity-labs.com/2017-08-10/scm-vulns](http://blog.recurity-
labs.com/2017-08-10/scm-vulns)

------
innocenat
Just a note for everyone on Ubuntu, the fixed version for Ubuntu 16.04 is git
v2.7.4-0ubuntu1.2 [0].

[0]: [https://people.canonical.com/~ubuntu-
security/cve/2017/CVE-2...](https://people.canonical.com/~ubuntu-
security/cve/2017/CVE-2017-1000117.html)

~~~
lotsoflumens
Does anybody understand Ubuntu releases?

The update this morning for Ubuntu 17.04 installs git 2.11.0

.. NOT the patched 2.11.3 NOR the latest 2.14.1

Why isn't Ubuntu fully up to date?

~~~
CiPHPerCoder
They backport patches and lie about the version number, to maintain the
illusion of stability. It really pisses off the PHP community.

[https://github.com/ircmaxell/password_compat/issues/90](https://github.com/ircmaxell/password_compat/issues/90)

~~~
cperciva
I can't speak for Ubuntu, but when I was FreeBSD Security Officer we would
regularly backport patches because importing an entire new release would
regularly break existing functionality or even add new security
vulnerabilities. It annoyed the heck out of vulnerability scanning tools, but
I decided that giving users a system which didn't randomly break when they
applied security patches was far more important.

~~~
CiPHPerCoder
That was years ago, IIRC.

PHP has gotten better about "no BC breaks in patch versions" over the years,
but the Debian/Ubuntu teams still insist on making people effectively run e.g.
7.1.8 while the version indicator says 7.1.1.

It makes feature detection a nightmare.

~~~
rlpb
Ubuntu developer here. Huh? No, we don't. Can you provide a more specific and
current example to make sure I don't misunderstand you?

For example, the current package for Ubuntu 16.04 LTS is
7.0.22-0ubuntu0.16.04.1. How does this mismatch 7.0.22 from the PHP upstream
project?

~~~
CiPHPerCoder
Okay, maybe Ubuntu stopped being stupid and only Debian is still guilty of
this?

This used to be a huge problem. I've since convinced [most PHP devs I talk to]
to stop using distro-provided packages, in favor of deb.sury.org.

~~~
rlpb
Ubuntu and Debian's PHP packages are largely the same.

> I've since convinced [most PHP devs I talk to] to stop using distro-provided
> packages, in favor of deb.sury.org.

You do realise that Ondřej Surý (of sury.org) _is_ the primary Debian PHP
maintainer? The point of his repositories (AIUI) is to allow users to mix and
match PHP versions. The downside is that he's one person with (AFAIK) a bus
factor of 1 when it comes to security updates. That's irresponsible to use in
production.

In contrast, Debian and Ubuntu's PHP packages, essentially provided _by the
same person_ , has in addition teams (both in Debian and Ubuntu) who can pitch
in when required.

------
jomar
_A "ssh://..." URL can result in a "ssh" command line with a hostname that
begins with a dash "-", which would cause the "ssh" command to instead
(mis)treat it as an option._

It's a shame, because the Git dispatching code ought to be able to invoke the
ssh command via

    
    
      ssh -p 22 -etc -etc -- <hostname>
    

to prevent interpreting options in <hostname>, thus defusing the in-band
signalling causing this. But I suppose it can't depend on every ssh
implementation understanding this "\--" POSIX utility syntax guideline.

~~~
numbsafari
How is this any different than a SQL-injection attack?

Seems to me like git shouldn't be using the shell in order to invoke ssh at
all.

~~~
jjnoakes
I haven't checked git, but even if git uses exec*() directly and skips the
shell (which I suspect it does), the problem still exists.

The issue isn't one of shell quoting, but one of ssh treating the argument
list ["ssh", "-oProxyCommand=something", "remote-cmd"] not as ["ssh",
hostname, command] but as ["ssh", option, hostname].

~~~
deckar01
There are C libraries for SSH, like libssh, that would avoid these type of
vulnerabilities.

[https://www.libssh.org/](https://www.libssh.org/)

~~~
peff
One downside of libraries like libssh is that they don't behave the same way
as your regular ssh command. So thing you've configured like host aliases,
proxy commands, etc, don't just work out of the box (and in some cases may not
even be supported at all).

~~~
deckar01
True. It sounds like there is room for an ORM-like sanitizer for SSH that is
responsible for translating a C API to sanitized commands. I have no clue what
to search to find if that already exists.

~~~
virtualized
It almost seems like ad-hoc text formats like command line argument syntaxes
are difficult to use correctly.

------
bburky
Wow, git's url bugs always seem to become easily exploitable due to
.gitmodules.

I found CVE-2015-7545 a few years ago, a malicious URL using the ext:: scheme
could cause code execution. It was only easily exploitable because you can ask
the client to fetch any URL you want via git submodules. (This vulneriblity
was fixed, and since then the entire ext url scheme was disabled by default.)

------
aroberge
This may be of interest to people using git on Windows and have malwarebytes
installed.

I tried to install a new version and found I could not as there was another
version that was present. Git did not appear anywhere as a program to
uninstall. I tried to delete it (from an admin account) and it failed with an
access denied - and no other information.

The solution was to use LockHunter
([https://lockhunter.com/](https://lockhunter.com/)) which informed me that
malwarebytes was the program preventing me from deleting it. Using LockHunter,
I removed the lock and successfully removed the old version of git.

------
rubayeet
At the time of writing this, no official binary release for Mac[0], you have
to build from source.

[0]: [https://git-scm.com/download/mac](https://git-scm.com/download/mac)

~~~
johnhenry
Looks like it's already available through homebrew, if you use that.

~~~
fmitchell0

      brew update && brew upgrade

~~~
Exuma
Or if you are on a fresh install of OSX or don't have git installed

    
    
        brew update && brew install git

------
rloconne
Where's the communication from Git itself about this? When I Google "critical
git security update" I see this item, and stories from a few other outlets,
but no notification from Git.

Their release note for this release just says "This release forward-ports the
fix for 'ssh://...' URL from Git v2.7.6".

Nodejs has a page where they outline their procedure
([https://nodejs.org/en/security/](https://nodejs.org/en/security/)), with a
list you can subscribe to. Does Git have something like that and I'm just
missing it?

------
chungy
> * In the same spirit, a repository name that begins with a dash "-" is also
> forbidden now.

This will negatively affect
[https://github.com/nasser/\---](https://github.com/nasser/---)

------
captn3m0
Arch Linux has the new package in testing:
[https://www.archlinux.org/packages/testing/i686/git/](https://www.archlinux.org/packages/testing/i686/git/)

------
HeadlessChild
Fix has landed for Debian Jessie/Stretch in the security repo

[https://security-
tracker.debian.org/tracker/CVE-2017-1000117](https://security-
tracker.debian.org/tracker/CVE-2017-1000117)

------
megous
A lot of the time people use git to get source code to build and run on their
computers. You can probably hide a nefarious code in many places, where it
would be less noticeable, too, like pre-generated configure/Makefile.in
scripts. I don't think anyone reads those. Another reason to welcome those new
simpler configure/build systems like meson/ninja.

------
cyphar
This was already submitted earlier today
([https://news.ycombinator.com/item?id=14984044](https://news.ycombinator.com/item?id=14984044)).

It's actually quite easy to reproduce (the RCE aspect comes from the
ProxyCommand and LocalCommand SSH options that you can set from the SSH
command-line).

------
djstein
For MacOS users simply use: `brew install git` Then restart terminal instance.

------
ing33k
on Ubuntu,

use this PPA [https://launchpad.net/~git-
core/+archive/ubuntu/ppa](https://launchpad.net/~git-core/+archive/ubuntu/ppa)

~~~
pawadu
why PPA? the official release is already patched

------
avivo
Is there any site where as security vulnerabilities are disclosed, you can see
each what platform/contexts are affected, which have updated, and how to do
that update?

~~~
kakarot
Couple that with an API and notification system and you've got yourself a good
service.

My hands are a little full at this moment but feel free to shoot me an email
if you're interested in doing something I like this. Seems like a good case
for automation.

------
VrEdxxx
I wonder how can I do it on OSX without brew or port?

~~~
justinclift
The next security release by Apple may include it. It's not uncommon to see
open source library/utility updates in their change logs.

eg: [https://support.apple.com/en-us/HT207922](https://support.apple.com/en-
us/HT207922)

------
numbsafari
I wonder how many "git client libraries" in various languages are also
impacted by this.

~~~
ethomson
I'm not familiar with any that exec ssh. Certainly libgit2 does not, nor do
the language bindings on top of it. So libgit2, LibGit2Sharp, Rugged, Jagged,
NodeGit are unaffected.

------
the_common_man
FYI, Cloudron has pushed out updates for Gitlab, Gogs (from their slack).

------
diegoperini
How can I do it on OSX without brew or port?

~~~
SCdF
I'm not sure where you got your git from (did it come with macos?) but I'd
highly recommend you use something like brew.

Not just for git, but for any tools you use honestly. MacOS very rarely
patches this kind of thing, and in situations like this you need to be able to
move fast.

~~~
tomjakubowski
> MacOS very rarely patches this kind of thing

I think it's more accurate to say that Apple often takes their time patching
these vulnerabilities. CVE‑2016‑2324 and CVE‑2016‑2315 were announced in March
2016 but Apple didn't release a patched version with Xcode until May 2016. Are
there any major security vulnerabilities in git Apple hasn't yet released a
patch for, other than this one?

But yeah, Homebrew gets the patches out much faster. It's probably the right
move to prefer using Homebrew's git to system git.

