Is GIT Bash for windows Vulnerable to Shell Shock

[shield...@gmail.com]

Hi

I use the GIT Bash MINGW32 shell console on my Windows platform to work with my GIT repositories, a download of which is available here: www.git-scm.com 

Is this vulnerable to the Shell Shock Vulnerability as i am struggling to find any resources online that are specific to GIT for windows as most of them refer to Linux and MAC which are predominately affected.

I have attached a screenshot showing the output of the two commands that can be run to check for the vulnerability.

Any help on this would be greatly appreciated.

Adam

[Johannes Schindelin]

Hi,

On Fri, 26 Sep 2014, shield...@gmail.com wrote:

> Any help on this would be greatly appreciated.

Have you had a look in the archives?
https://groups.google.com/forum/#!forum/msysgit

Hth,
Johannes

[Johannes Schindelin]

Hi,

On Fri, 26 Sep 2014, shield...@gmail.com wrote:

> I have attached a screenshot showing the output of the two commands that
> can be run to check for the vulnerability.

Please also note that it makes much more sense to make it *easy* for
others to help you. A screenshot of commands is not helpful. You basically
ask others to type the letters in one by one, i.e. to spend much more time
than the quick and dirty screenshot. That is not exactly enticing other
people to pitch in more effort.

Htha,
Johannes

[Gauthier Van Vreckem]

I've looked at the archive and the question is not properly answered.
From the archive we learn that yes the bash version of git is buggy, and it's in the process of being solved.

However having a response of vulnerable to the test command doesn't make the buggy feature a vulnerability.
There is the matter of the attack vector and the user setup.

As far as I can see the attack need to go trough the ssh-agent.exe
From:
http://unix.stackexchange.com/questions/157477/how-can-shellshock-be-exploited-over-ssh

It seems that it may only be vulnerable if using keys for user authentication and only authenticated users would be able to use one exploit to bypass restrictions which I'm not sure are even in place.
So the questions are:
Using any of the default setup available is there a remotely exploitable vulnerability?
What kind of sshd config is the ssh-agent.exe using, is it using ForceCommand or command=

Gauthier

[Erik Faye-Lund]

If I understand the situation correctly, you need some way of remotely
calling bash (with user-controlled input, through an unauthenticated
user), for this to really be a vulnerability.

Git for Windows does not, to my knowledge, provide a mechanism to
remotely call bash with user-input (we can call hooks, but to install
a malicious hook you already need access to the machine). Even if you
install CopSSH (or some other SSH server for Windows), you should
still be safe, as bash.exe will only be started after log-in, so
remote code execution is already allowed. There *might* be some cases
where you set up a restricted shell that could be vulnerable, though.

So, in short, I don't think shellshock is a real issue as deployed in
Git for Windows, except for *maybe* some setups that depend on other
software as well.

[Gauthier Van Vreckem]

> On Monday, September 29, 2014 11:41:58 AM UTC+2, Erik Faye-Lund wrote:
>> From:
>> http://unix.stackexchange.com/questions/157477/how-can-shellshock-be-exploited-over-ssh
>>
>> It seems that it may only be vulnerable if using keys for user
>> authentication and only authenticated users would be able to use one exploit
>> to bypass restrictions which I'm not sure are even in place.
>> So the questions are:
>> Using any of the default setup available is there a remotely exploitable
>> vulnerability?
>> What kind of sshd config is the ssh-agent.exe using, is it using
>> ForceCommand or command=
>
> If I understand the situation correctly, you need some way of remotely
> calling bash (with user-controlled input, through an unauthenticated
> user), for this to really be a vulnerability.

Not at all, that vulnerability exploit apply only to untrusted authenticated users
trough ssh keys.

But if there is any way to remotely trigger the creation of an user controlled
environment variable prior to executing bash which is used to launch git we are dead too.

> Git for Windows does not, to my knowledge, provide a mechanism to
> remotely call bash with user-input (we can call hooks, but to install
> a malicious hook you already need access to the machine).

There is no need for the hooks to be malicious, just to exist.
All that is needed is a way to set user controlled environment variables.
The .cmd wrapper with a SET command are prime candidate.
( Exactly as it is done in start-ssh-agent.cmd ! )
and in that regard, the codebase is rather lazy and seems to resort
to environement variables even when not needed.
In fact un-setting all the temporary variables left over to reconstruct a command line would probably
remove any bash risks.

[Erik Faye-Lund]

On Mon, Sep 29, 2014 at 2:48 PM, Gauthier Van Vreckem
<gvanv...@gmail.com> wrote:
>
>> On Monday, September 29, 2014 11:41:58 AM UTC+2, Erik Faye-Lund wrote:
>>> From:
>>>
>>> http://unix.stackexchange.com/questions/157477/how-can-shellshock-be-exploited-over-ssh
>>>
>>> It seems that it may only be vulnerable if using keys for user
>>> authentication and only authenticated users would be able to use one
>>> exploit
>>> to bypass restrictions which I'm not sure are even in place.
>>> So the questions are:
>>> Using any of the default setup available is there a remotely exploitable
>>> vulnerability?
>>> What kind of sshd config is the ssh-agent.exe using, is it using
>>> ForceCommand or command=
>>
>> If I understand the situation correctly, you need some way of remotely
>> calling bash (with user-controlled input, through an unauthenticated
>> user), for this to really be a vulnerability.
>
> Not at all, that vulnerability exploit apply only to untrusted authenticated
> users
> trough ssh keys.
>

How is that not exactly what I said?

> But if there is any way to remotely trigger the creation of an user
> controlled
> environment variable prior to executing bash which is used to launch git we
> are dead too.
>

Yes, but we don't provide any means of doing this. But thanks for
pointing it out.

>> Git for Windows does not, to my knowledge, provide a mechanism to
>> remotely call bash with user-input (we can call hooks, but to install
>> a malicious hook you already need access to the machine).
>
> There is no need for the hooks to be malicious, just to exist.
> All that is needed is a way to set user controlled environment variables.
> The .cmd wrapper with a SET command are prime candidate.
> ( Exactly as it is done in start-ssh-agent.cmd ! )
> and in that regard, the codebase is rather lazy and seems to resort
> to environement variables even when not needed.
> In fact un-setting all the temporary variables left over to reconstruct a
> command line would probably
> remove any bash risks.

But you cannot remotely inject environment variables, so the whole
point is moot. If you can inject environment variables, you can do a
lot of other nasty things as well; you're already inside the air-tight
hatch.

[Gauthier Van Vreckem]

On Monday, September 29, 2014 2:58:39 PM UTC+2, Erik Faye-Lund wrote:
>> If I understand the situation correctly, you need some way of remotely
>> calling bash (with user-controlled input, through an unauthenticated
>> user), for this to really be a vulnerability.
>
> Not at all, that vulnerability exploit apply only to untrusted authenticated
> users
> trough ssh keys.
>

>How is that not exactly what I said?

You said: calling bash trough an unauthenticated user.
The GIT SSH failure lies with untrusted authenticated user.
I fail to see any way this can be the same maybe
a matter of terminology...

>> But if there is any way to remotely trigger the creation of an user
>> controlled
>> environment variable prior to executing bash which is used to launch git we
>> are dead too.
>>
>
> Yes, but we don't provide any means of doing this. But thanks for
> pointing it out.

Not directly no, but it looked like the cmd wrapper may do it in an
unwanted side effect. (I was wrong!)

> But you cannot remotely inject environment variables, so the whole
> point is moot.

Is that a fact or your opinion?

I was not so sure, after taking a good look at all environment vars,
things look clean. Except of course that I do not
master that code at all. So call it an uninformed opinion of no value.

> If you can inject environment variables, you can do a
> lot of other nasty things as well; you're already inside the air-tight
> hatch.

Those who designed CGI would strongly disagree with you.
(And with good reason!)
It is safe and an usual practice to have environment variable
(with a name of your choosing and not conflicting) set to untrusted content.
Nevertheless, thanks to this bash feature and parsing bug
this common practice it is now a prime infection vector.

Little aside, that web interface to google groups is a real mess
when you are not allowed to top post.
Is there an option somewhere to disable html editing?