[Arnavion]

As the article states, it's a feature of git-gui, not the git CLI.

The vulnerability is Windows-only, so maybe whatever Windows users do to install git always gives them git-gui. But at least for Linux, the distro might package it separately (mine does), so you won't even have it if you didn't install it.

[mdaniel]

As best I can tell from the "The Windows-specific issue involves a $PATH lookup including the current working directory" part, it would be:

    echo "calc.exe" > aspell.cmd
    git commit -a -m"lolol windows"

and wait for someone to clone that repo

[zerocrates]

What I don't quite get is why there's spellchecking on incoming commits at all.

[Arnavion]

Don't understand what you mean by "incoming commits". git-gui shows you a textbox for the commit message, and error squiggles for misspelled words (presumably; I CBA to install a spell checker). The bug is that it spawns the spellcheck binary using Tcl's API, which on Windows also looks up binaries in the current directory regardless of whether the current directory is in $PATH or not.

Edit: Maybe you're referring to the existing commits in the repo that you just cloned? If so, those are irrelevant. git-gui is a GUI for composing commits. The commit message being spell-checked is the one that you would write in order to create a new commit.

[zerocrates]

My reason for asking that is that this is the vuln description from the article:

> After cloning a repository, Git GUI automatically applies some post-processing to the resulting checkout, including running a spell-checker, if one is available.

> A Windows-specific vulnerability causes Git GUI to look for the spell-check in the worktree that was just checked out, which may result in running untrusted code.

I get what you're saying that just in general, there's an issue that you could put a file that matches the name for the spellchecker command in the repo and thereby have git-gui run your payload when the spellchecker should run.

But the article says this is "post-processing" to a checkout. That's what doesn't make sense to me, but the CVE itself says the same thing, that aspell is getting run immediately after a clone. What's the point of doing that?

[Arnavion]

It's phrased badly. I can see that it sounds like it's post-processing the new clone by running spellcheck on all the commits of the cloned branch, but it definitely doesn't do that. I checked the code just to be sure and there's nothing like that in the clone code. (Unless I'm missing something, but as you said I can't fathom why it would need to do that.)

What happens is that, when you use it clone a repo it immediately shows the window for authoring a new commit message, which as I said will invoke the spell-check. That's why you are vulnerable from the moment you use git-gui to clone.

[wolfgang42]

I’m pretty sure it’s spell-checking the next commit the user will make, which on an new repository is of course empty, but there's no special case to start the spell-checker only when the user starts writing. (The “post-processing” the article refers to, I think, is just starting up the GUI on the repo, which includes setting up the textbox for the commit message. In fact I’m pretty sure the act of cloning is irrelevant, that’s just the most likely way for an unwitting user to get a malicious repository.)