22

After the news of the Shellshock vulnerability broke out, I remembered I had GitHub's version of a bash shell for Windows installed. Just to see if it also had the vulnerability, I executed:

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

And got back:

vulnerable
this is a test

Still, being a Windows system, can anything malicious be done from the GitHub bash shell, other than mess with my repositories?

(GitHub v2.0.6.0 130c781) (GitHub v2.4.0.12 34d40b7)

edit:

env x='() { :;};' bash -c "vi foldername/filename"

Confirming this can edit Windows system files.

cptncrnch
  • 305
  • 3
  • 8
  • 1
    Anything your bash shell can do, an exploit that controls your bash shell can do. Can your bash shell do anything besides manipulate your repositories? (Note, however, that your chance of attack is may be reduced, because nothing else *uses* your bash shell. My understanding is that, in *nix, this is a huge problem because lots of other software depends on bash and environment variables. In Windows, it's less likely that any other software is set up to invoke your vulnerable bash shell.) – apsillers Sep 25 '14 at 17:25
  • 1
    Well, looks like I can execute pings, check directories "ls", and edit files "vi directory/file". – cptncrnch Sep 25 '14 at 17:36

1 Answers1

25

I'm a developer on GitHub for Windows - we're closely monitoring the msysgit mailing list for progress on this, but we believe at the moment that there isn't any way to exploit this in GitHub's shell, because there is no escalation of privilege (i.e. you can only hack yourself).

We're definitely actively looking for scenarios where that is not the case, and if we find one we'll definitely be pushing out an update ASAP.

Update: We've pushed out a release that resolves the known Bash vulnerabilities mentioned in recent CVEs. We'll be on the lookout for future issues as well.

Ana Betts
  • 366
  • 3
  • 4
  • good to know Paul. – r3wt Sep 26 '14 at 12:23
  • 2
    So you won't push out an update if the situation described in the question is not found to happen (escalation of privileges)? Or are you just saying you will push out an update as soon as the situation is found to be true, and otherwise you may do it sometime later but it's not a priority? – trysis Sep 26 '14 at 19:28
  • 2
    The latter - the fix for this is currently in-flux, so we'd rather wait to push out a complete fix unless it's an emergency – Ana Betts Sep 26 '14 at 19:33
  • Many Windows users have Administrator rights or disabled UAC. Anyways this vulnerability could give access to your git repositories (including private). – Victor Oct 01 '14 at 14:33
  • @Victor Can you give a proof of concept as a Gist? If you don't want to share this publicly, please go to https://bounty.github.com/submit-a-vulnerability.html – Ana Betts Oct 01 '14 at 15:55
  • @Victor I think what Paul says makes sense. If you disabled UAC then you already don't have sandboxed processes and any rogue process you run can own you totally. If you have UAC and unsandboxed rogue processes, same thing. If you have UAC and sandboxed rogue processes they can't IPC to an unsandboxed Github process. Or am I missing something? – Steve Dodier-Lazaro Oct 01 '14 at 16:49
  • @PaulBetts No, I don't have a PoC, just thinking aloud. Sorry for any inconvenience. – Victor Oct 02 '14 at 14:17