New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

EXE hijacking runs unexpected code when using context menus in Windows Explorer #944

Closed
mattymcfatty opened this Issue Nov 4, 2016 · 19 comments

Comments

Projects
None yet
8 participants
@mattymcfatty

mattymcfatty commented Nov 4, 2016

Setup

  • Which version of Git for Windows are you using? Is it 32-bit or 64-bit?
    Git-2.10.2-64-bit.exe

  • Which version of Windows are you running? Vista, 7, 8, 10? Is it 32-bit or 64-bit?
    Windows 8.1

  • What options did you set as part of the installation? Or did you choose the
    defaults?
    Defaults

# One of the following:
C:\>type "C:\Program Files\Git\etc\install-options.txt"
Path Option: Cmd
SSH Option: OpenSSH
CRLF Option: CRLFAlways
Bash Terminal Option: MinTTY
Performance Tweaks FSCache: Enabled
Enable Symlinks: Disabled

 - Any other interesting things about your environment that might be related
   to the issue you're seeing?
Don't think so. Had some buddies reproduce the issue on Windows 10

### Details

 - Which terminal/shell are you running Git from? e.g Bash/CMD/PowerShell/other
Windows Explorer

 - What commands did you run to trigger this issue? 
Here is an example of the steps to reproduce in Windows Explorer
https://youtu.be/S7jOLv0sul0

 - What did you expect to occur after running these commands?

Open Git Bash in the current folder

 - What actually happened instead?

Arbitrary file named "git.exe" in the current folder was executed. This has security implications since users will not expect this behavior when using Windows context menus. For example, a security-conscious user would know not to execute EXE files included in an untrusted repository, but using Windows context menus could unexpectedly execute such untrusted code. This issue is similar to DLL hijacking if you are familiar with that. Here is a brief explanation of DLL hijacking if you're not familiar https://trustfoundry.net/what-is-dll-hijacking/
@dscho

This comment has been minimized.

Show comment
Hide comment
@dscho

dscho Nov 5, 2016

Member

It would be better to produce a step-by-step list of instructions (with clarifications) in text form, here, than some YouTube video.

I mean, you expect me to fix the code and push the commits fixing the code, right? You don't expect me to post a YouTube video of me typing something into my editor that might, or might not, fix your problem, right?

Member

dscho commented Nov 5, 2016

It would be better to produce a step-by-step list of instructions (with clarifications) in text form, here, than some YouTube video.

I mean, you expect me to fix the code and push the commits fixing the code, right? You don't expect me to post a YouTube video of me typing something into my editor that might, or might not, fix your problem, right?

@AnnoyedGit

This comment has been minimized.

Show comment
Hide comment
@AnnoyedGit

AnnoyedGit Nov 5, 2016

I mean, you expect me to fix the code and push the commits fixing the code, right? You don't expect me to post a YouTube video of me typing something into my editor that might, or might not, fix your problem, right?

No but if you were trying to visually demonstrate how commit and push, a youtube video would be a great option. Right up until someone commented that you should be making a text post to describe those things because thats their preference and followed it with a bad analogy (and some bad language/name calling, because thats what happens in youtube comments).

You could have just said you prefer not to go to youtube and/or asked for clarification if you needed it. I have no problem understanding the issue as is without even viewing the video.

AnnoyedGit commented Nov 5, 2016

I mean, you expect me to fix the code and push the commits fixing the code, right? You don't expect me to post a YouTube video of me typing something into my editor that might, or might not, fix your problem, right?

No but if you were trying to visually demonstrate how commit and push, a youtube video would be a great option. Right up until someone commented that you should be making a text post to describe those things because thats their preference and followed it with a bad analogy (and some bad language/name calling, because thats what happens in youtube comments).

You could have just said you prefer not to go to youtube and/or asked for clarification if you needed it. I have no problem understanding the issue as is without even viewing the video.

@eapz

This comment has been minimized.

Show comment
Hide comment
@eapz

eapz Nov 5, 2016

It would be better to produce a step-by-step list of instructions (with clarifications) in text form, here, than some YouTube video.

I mean, you expect me to fix the code and push the commits fixing the code, right? You don't expect me to post a YouTube video of me typing something into my editor that might, or might not, fix your problem, right?

Nice to see a major security issue taken serious because of your personal issues with YouTube. The video is short, simple, to the point and shows the problem without fuss or additional junk. Perhaps you should hire someone to handle public relations for you since you seem too entitled to do it yourself.

eapz commented Nov 5, 2016

It would be better to produce a step-by-step list of instructions (with clarifications) in text form, here, than some YouTube video.

I mean, you expect me to fix the code and push the commits fixing the code, right? You don't expect me to post a YouTube video of me typing something into my editor that might, or might not, fix your problem, right?

Nice to see a major security issue taken serious because of your personal issues with YouTube. The video is short, simple, to the point and shows the problem without fuss or additional junk. Perhaps you should hire someone to handle public relations for you since you seem too entitled to do it yourself.

@dscho

This comment has been minimized.

Show comment
Hide comment
@dscho

dscho Nov 7, 2016

Member

Nice to see a major security issue taken serious because of your personal issues with YouTube.

@eapz I think you seriously misunderstand the issue. I simply could not watch that YouTube video at the time I wrote this. As a matter of fact, I still cannot access it right now, as I am reading these issues on a tiny screen in text mode.

And quite honestly, a YouTube video cannot be a proper bug report that details enough background information in an easy-to-understand manner. If you are serious about this bug, you seriously need to step up your bug reporting game.

Additionally, it is really poor style to redirect readers away from the issue tracker. The issue tracker is here to track issues, not to link to some other place where some random content has been posted that may be inaccessible or get deleted at any time.

In any case, from the incomplete information that is provided here, I have to guess that the original poster noticed that git.exe files copied into the active PATH override Git for Windows' git.exe.

If this guess (and I have to repeat that I resent being bullied into having to guess here, for lack of a proper bug report) is correct, then there is not really much of a security flaw here: if you can trick a user into installing random .exe files into their file system, then there is not much any software can do to prevent bad things from happening.

Member

dscho commented Nov 7, 2016

Nice to see a major security issue taken serious because of your personal issues with YouTube.

@eapz I think you seriously misunderstand the issue. I simply could not watch that YouTube video at the time I wrote this. As a matter of fact, I still cannot access it right now, as I am reading these issues on a tiny screen in text mode.

And quite honestly, a YouTube video cannot be a proper bug report that details enough background information in an easy-to-understand manner. If you are serious about this bug, you seriously need to step up your bug reporting game.

Additionally, it is really poor style to redirect readers away from the issue tracker. The issue tracker is here to track issues, not to link to some other place where some random content has been posted that may be inaccessible or get deleted at any time.

In any case, from the incomplete information that is provided here, I have to guess that the original poster noticed that git.exe files copied into the active PATH override Git for Windows' git.exe.

If this guess (and I have to repeat that I resent being bullied into having to guess here, for lack of a proper bug report) is correct, then there is not really much of a security flaw here: if you can trick a user into installing random .exe files into their file system, then there is not much any software can do to prevent bad things from happening.

@mattymcfatty

This comment has been minimized.

Show comment
Hide comment
@mattymcfatty

mattymcfatty Nov 7, 2016

Hey @dscho,

Didn't mean to upset anyone by posting the video. It's quite common to use screenshots and videos when delivering Proof of Concepts for vulnerabilities (especially when they are GUI-related). Here is the text version of what's happening in the video for you:

  1. Name any malicious code "git.exe" (I renamed "calc.exe" to "git.exe" for my PoC).
  2. Place that "git.exe" in any folder on your system.
  3. Right click an item in the folder to show the Git for Windows context menu.
  4. Select "Git Bash Here".
  5. The malicious "git.exe" is executed.

I think you're right. It's related to how the %PATH% is searched by the application. Let me know if you need any more information.

mattymcfatty commented Nov 7, 2016

Hey @dscho,

Didn't mean to upset anyone by posting the video. It's quite common to use screenshots and videos when delivering Proof of Concepts for vulnerabilities (especially when they are GUI-related). Here is the text version of what's happening in the video for you:

  1. Name any malicious code "git.exe" (I renamed "calc.exe" to "git.exe" for my PoC).
  2. Place that "git.exe" in any folder on your system.
  3. Right click an item in the folder to show the Git for Windows context menu.
  4. Select "Git Bash Here".
  5. The malicious "git.exe" is executed.

I think you're right. It's related to how the %PATH% is searched by the application. Let me know if you need any more information.

@AnnoyedGit

This comment has been minimized.

Show comment
Hide comment
@AnnoyedGit

AnnoyedGit Nov 7, 2016

@dscho Doesn't take even seeing the youtube vid to understand it executing anything named "git" in the repository root. It really looks like you simply stopped reading when you saw the youtube link or are being overly pedantic. The issue reported did describe this in text form but left out the obvious "steps" in favor of a visual demonstration.

Arbitrary file named "git.exe" in the current folder was executed. This has security implications since users will not expect this behavior when using Windows context menus. For example, a security-conscious user would know not to execute EXE files included in an untrusted repository, but using Windows context menus could unexpectedly execute such untrusted code. This issue is similar to DLL hijacking if you are familiar with that. Here is a brief explanation of DLL hijacking if you're not familiar https://trustfoundry.net/what-is-dll-hijacking/

I can understand insistence that people actually use and fill in your template properly (I have this problem myself with users of a different project, drives me crazy) but even with out describing "open git bash" in text form its easy to understand whats being said here so you acting like you have to guess is incomprehensibly silly.

I can also agree that if you already have a bad exe you already have problems that aren't git-for-window's fault but I still think this is worth looking at - if the users path wasn't also hijacked, there is no reason for it to be running a different exe path is there?

@mattymcfatty I wasn't expecting anyone else to come along and up the ante, nor the developer to think they had to guess at this.

I'll leave you both alone now, I've said my peace.

AnnoyedGit commented Nov 7, 2016

@dscho Doesn't take even seeing the youtube vid to understand it executing anything named "git" in the repository root. It really looks like you simply stopped reading when you saw the youtube link or are being overly pedantic. The issue reported did describe this in text form but left out the obvious "steps" in favor of a visual demonstration.

Arbitrary file named "git.exe" in the current folder was executed. This has security implications since users will not expect this behavior when using Windows context menus. For example, a security-conscious user would know not to execute EXE files included in an untrusted repository, but using Windows context menus could unexpectedly execute such untrusted code. This issue is similar to DLL hijacking if you are familiar with that. Here is a brief explanation of DLL hijacking if you're not familiar https://trustfoundry.net/what-is-dll-hijacking/

I can understand insistence that people actually use and fill in your template properly (I have this problem myself with users of a different project, drives me crazy) but even with out describing "open git bash" in text form its easy to understand whats being said here so you acting like you have to guess is incomprehensibly silly.

I can also agree that if you already have a bad exe you already have problems that aren't git-for-window's fault but I still think this is worth looking at - if the users path wasn't also hijacked, there is no reason for it to be running a different exe path is there?

@mattymcfatty I wasn't expecting anyone else to come along and up the ante, nor the developer to think they had to guess at this.

I'll leave you both alone now, I've said my peace.

@kostix

This comment has been minimized.

Show comment
Hide comment
@kostix

kostix Nov 7, 2016

So, to reconcile the matters on the issue, I would say the bug report could have been:

Please consider modifying the installer code which updates the Explorer's context menu entries to use the full path to the git.exe executable (presumably recorded somewhere in the Registry when installing).

Does this sound okay, @mattymcfatty?

kostix commented Nov 7, 2016

So, to reconcile the matters on the issue, I would say the bug report could have been:

Please consider modifying the installer code which updates the Explorer's context menu entries to use the full path to the git.exe executable (presumably recorded somewhere in the Registry when installing).

Does this sound okay, @mattymcfatty?

@kostix

This comment has been minimized.

Show comment
Hide comment
@kostix

kostix Nov 7, 2016

FWIW, I don't see a point in calling this a security hole: in (any) shell, most of the time you execute commands without spelling their full names (which is next to silly on Windows thanks to those long C:\Program Files\blah\blah anyway) so the "attack vector" remains anyway even if this issue is fixed.

On the other hand, I'd say 99.9% of entries of the Start menu and of context menus do use full pathnames on Windows, so having this fixed would just be in line with the common practices without breaking things (supposedly).

kostix commented Nov 7, 2016

FWIW, I don't see a point in calling this a security hole: in (any) shell, most of the time you execute commands without spelling their full names (which is next to silly on Windows thanks to those long C:\Program Files\blah\blah anyway) so the "attack vector" remains anyway even if this issue is fixed.

On the other hand, I'd say 99.9% of entries of the Start menu and of context menus do use full pathnames on Windows, so having this fixed would just be in line with the common practices without breaking things (supposedly).

@dscho

This comment has been minimized.

Show comment
Hide comment
@dscho

dscho Nov 7, 2016

Member

Please consider modifying the installer code which updates the Explorer's context menu entries to use the full path to the git.exe executable (presumably recorded somewhere in the Registry when installing).

@kostix this is an excellent suggestion.

Furthermore, it looks like this does not really need deep knowledge of Git.

Member

dscho commented Nov 7, 2016

Please consider modifying the installer code which updates the Explorer's context menu entries to use the full path to the git.exe executable (presumably recorded somewhere in the Registry when installing).

@kostix this is an excellent suggestion.

Furthermore, it looks like this does not really need deep knowledge of Git.

@dscho

This comment has been minimized.

Show comment
Hide comment
@dscho

dscho Nov 7, 2016

Member

Hold on.

I just compiled the following program into %HOME%\Desktop\git.exe:

#include <windows.h>

int main(int argc, char **argv)
{
    MessageBox(NULL, "Hello", "World", MB_OK);
    return 0;
}

Then, I verified that calling that .exe really shows the message box.

After that, I opened the Desktop in Windows Explorer and right-clicked in the empty area, calling Git Bash Here. I was greeted with the all-too-familiar Git Bash window, and typing git version produced git version 2.10.2.windows.1.

This is on Windows 10, cmd //c ver says this: Microsoft Windows [Version 10.0.14393].

So it seems that I cannot reproduce the purported behavior.

It also seems that the absolute path to the git-bash.exe is used in the shell integration.

Maybe it is a difference between Windows 10 and Windows 8.1?

Member

dscho commented Nov 7, 2016

Hold on.

I just compiled the following program into %HOME%\Desktop\git.exe:

#include <windows.h>

int main(int argc, char **argv)
{
    MessageBox(NULL, "Hello", "World", MB_OK);
    return 0;
}

Then, I verified that calling that .exe really shows the message box.

After that, I opened the Desktop in Windows Explorer and right-clicked in the empty area, calling Git Bash Here. I was greeted with the all-too-familiar Git Bash window, and typing git version produced git version 2.10.2.windows.1.

This is on Windows 10, cmd //c ver says this: Microsoft Windows [Version 10.0.14393].

So it seems that I cannot reproduce the purported behavior.

It also seems that the absolute path to the git-bash.exe is used in the shell integration.

Maybe it is a difference between Windows 10 and Windows 8.1?

@njfox

This comment has been minimized.

Show comment
Hide comment
@njfox

njfox Nov 7, 2016

I did some digging and I believe this behavior could be due to git-cheetah-git_shell_ext64.dll (https://github.com/msysgit/Git-Cheetah/blob/master/explorer/dll.c) searching for git.exe in the current directory. When Git-For-Windows is installed, the following two shell extensions are added, both pointing to this DLL:

untitled picture

I think a quick fix would be to modify this behavior in the source file above to only use the absolute path to git.exe, rather than searching the current directory. A longer-term solution could involve migrating away from Git-Cheetah, as I don't believe it is currently being maintained.

I should note that I am on Windows 10 and am seeing the same behavior mattymcfatty is describing.

Update: I just noticed I actually have two sets of "Git Bash" options in my explorer shell extensions:

untitled picture

Clicking "Git Bash Here" at the top does not execute the arbitrary code, clicking "Git Bash" towards the bottom does. So it seems somehow multiple shell extensions got added--those for Git-Cheetah, which are vulnerable, and those for the shell extension dscho listed above, which shouldn't be vulnerable. Is there anything in the installer code that would be registering the Git-Cheetah shell extensions, or could those be those left over from some earlier installation?

njfox commented Nov 7, 2016

I did some digging and I believe this behavior could be due to git-cheetah-git_shell_ext64.dll (https://github.com/msysgit/Git-Cheetah/blob/master/explorer/dll.c) searching for git.exe in the current directory. When Git-For-Windows is installed, the following two shell extensions are added, both pointing to this DLL:

untitled picture

I think a quick fix would be to modify this behavior in the source file above to only use the absolute path to git.exe, rather than searching the current directory. A longer-term solution could involve migrating away from Git-Cheetah, as I don't believe it is currently being maintained.

I should note that I am on Windows 10 and am seeing the same behavior mattymcfatty is describing.

Update: I just noticed I actually have two sets of "Git Bash" options in my explorer shell extensions:

untitled picture

Clicking "Git Bash Here" at the top does not execute the arbitrary code, clicking "Git Bash" towards the bottom does. So it seems somehow multiple shell extensions got added--those for Git-Cheetah, which are vulnerable, and those for the shell extension dscho listed above, which shouldn't be vulnerable. Is there anything in the installer code that would be registering the Git-Cheetah shell extensions, or could those be those left over from some earlier installation?

@landstander668

This comment has been minimized.

Show comment
Hide comment
@landstander668

landstander668 Nov 7, 2016

For what it's worth, I don't seem to be able to reproduce this issue on Windows 7 Professional SP1.

$ git version --build-options
git version 2.10.2.windows.1
sizeof-long: 4
machine: x86_64

landstander668 commented Nov 7, 2016

For what it's worth, I don't seem to be able to reproduce this issue on Windows 7 Professional SP1.

$ git version --build-options
git version 2.10.2.windows.1
sizeof-long: 4
machine: x86_64
@mattymcfatty

This comment has been minimized.

Show comment
Hide comment
@mattymcfatty

mattymcfatty Nov 7, 2016

@njfox I'm having the same issue. I think even though I have the latest version of Git installed, the old mysysgit was still on there (unbeknownst to me). The behavior is coming from an old install of mysysgit. The latest version of Git Bash for Windows does not appear to be vulnerable to the same attack. I think we can close this issue out @dscho. Thanks guys for reproducing and helping me solve the mystery.

mattymcfatty commented Nov 7, 2016

@njfox I'm having the same issue. I think even though I have the latest version of Git installed, the old mysysgit was still on there (unbeknownst to me). The behavior is coming from an old install of mysysgit. The latest version of Git Bash for Windows does not appear to be vulnerable to the same attack. I think we can close this issue out @dscho. Thanks guys for reproducing and helping me solve the mystery.

@eapz

This comment has been minimized.

Show comment
Hide comment
@eapz

eapz Nov 7, 2016

@eapz I think you seriously misunderstand the issue. I simply could not watch that YouTube video at the time I wrote this. As a matter of fact, I still cannot access it right now, as I am reading these issues on a tiny screen in text mode.

What are you browsing the internet on, an old Nokia phone? I serious doubt this is true, but whatever you need to say to try and backtrack your cocky attitude.

And quite honestly, a YouTube video cannot be a proper bug report that details enough background information in an easy-to-understand manner. If you are serious about this bug, you seriously need to step up your bug reporting game.

This is probably one of the most ridiculous things I've read in a long time from a project maintainer. It's pretty obvious you have some personal grudge with YouTube given that tons of products ask for videos / screenshots / etc. to assist with detailing a bug report and showing the steps to reproduce something in a more clear manner. Which the video did perfectly, but again, you refused to watch it so what would you know, right?

Additionally, it is really poor style to redirect readers away from the issue tracker. The issue tracker is here to track issues, not to link to some other place where some random content has been posted that may be inaccessible or get deleted at any time.

This is really where you are going with this? You are trying that hard to backtrack what you said lol? The video does not need to survive the lifetime of this project, it simply needs to survive the lifetime of the issue at hand being fixed. You clearly responded to this within the 24hrs it was posted, so the video would have been seen under normal circumstances if you didn't have a grudge against YouTube.

Git's website uses videos hosted on Vimeo for its documentation. What if that site dies tomorrow or just decides to delete the videos?

In any case, from the incomplete information that is provided here, I have to guess that the original poster noticed that git.exe files copied into the active PATH override Git for Windows' git.exe.

You wouldn't if you got the stick out of your ass about YouTube and just watched the video. But clearly, that is not going to happen since you are too entitled for it.

eapz commented Nov 7, 2016

@eapz I think you seriously misunderstand the issue. I simply could not watch that YouTube video at the time I wrote this. As a matter of fact, I still cannot access it right now, as I am reading these issues on a tiny screen in text mode.

What are you browsing the internet on, an old Nokia phone? I serious doubt this is true, but whatever you need to say to try and backtrack your cocky attitude.

And quite honestly, a YouTube video cannot be a proper bug report that details enough background information in an easy-to-understand manner. If you are serious about this bug, you seriously need to step up your bug reporting game.

This is probably one of the most ridiculous things I've read in a long time from a project maintainer. It's pretty obvious you have some personal grudge with YouTube given that tons of products ask for videos / screenshots / etc. to assist with detailing a bug report and showing the steps to reproduce something in a more clear manner. Which the video did perfectly, but again, you refused to watch it so what would you know, right?

Additionally, it is really poor style to redirect readers away from the issue tracker. The issue tracker is here to track issues, not to link to some other place where some random content has been posted that may be inaccessible or get deleted at any time.

This is really where you are going with this? You are trying that hard to backtrack what you said lol? The video does not need to survive the lifetime of this project, it simply needs to survive the lifetime of the issue at hand being fixed. You clearly responded to this within the 24hrs it was posted, so the video would have been seen under normal circumstances if you didn't have a grudge against YouTube.

Git's website uses videos hosted on Vimeo for its documentation. What if that site dies tomorrow or just decides to delete the videos?

In any case, from the incomplete information that is provided here, I have to guess that the original poster noticed that git.exe files copied into the active PATH override Git for Windows' git.exe.

You wouldn't if you got the stick out of your ass about YouTube and just watched the video. But clearly, that is not going to happen since you are too entitled for it.

@kostix

This comment has been minimized.

Show comment
Hide comment
@kostix

kostix Nov 7, 2016

@eapz, please consider getting back to watching youtube clips rather than venting here. Such venting is not productive especially given the fact the issue was already scrutinized and even tested by several folks.

kostix commented Nov 7, 2016

@eapz, please consider getting back to watching youtube clips rather than venting here. Such venting is not productive especially given the fact the issue was already scrutinized and even tested by several folks.

@dscho

This comment has been minimized.

Show comment
Hide comment
@dscho

dscho Nov 8, 2016

Member

I did some digging and I believe this behavior is due to git-cheetah-git_shell_ext64.dll (https://github.com/msysgit/Git-Cheetah/blob/master/explorer/dll.c) searching for git.exe in the current directory.

But we do not ship Git Cheetah as part of Git for Windows any longer, ever since releasing the first Git for Windows 2.x release in August 2015!

Even more, we do have code in the installer to remove Git Cheetah as part of uninstalling Git for Windows, which we do implicitly when upgrading Git for Windows. The code to handle the 64-bit version of Git Cheetah was introduced in msysgit/msysgit@f5f7760 and was shipped with every single Git for Windows version since 1.7.0-preview20120409.

He's right clicking on a python file and git bash is in his context menu. If I right click on a filename, thats not on my context menu.

That is a strong indicator of a left-over Git Cheetah.

Member

dscho commented Nov 8, 2016

I did some digging and I believe this behavior is due to git-cheetah-git_shell_ext64.dll (https://github.com/msysgit/Git-Cheetah/blob/master/explorer/dll.c) searching for git.exe in the current directory.

But we do not ship Git Cheetah as part of Git for Windows any longer, ever since releasing the first Git for Windows 2.x release in August 2015!

Even more, we do have code in the installer to remove Git Cheetah as part of uninstalling Git for Windows, which we do implicitly when upgrading Git for Windows. The code to handle the 64-bit version of Git Cheetah was introduced in msysgit/msysgit@f5f7760 and was shipped with every single Git for Windows version since 1.7.0-preview20120409.

He's right clicking on a python file and git bash is in his context menu. If I right click on a filename, thats not on my context menu.

That is a strong indicator of a left-over Git Cheetah.

@kgybels

This comment has been minimized.

Show comment
Hide comment
@kgybels

kgybels Nov 8, 2016

@mattymcfatty You say you are using Git-2.10.2-64-bit.exe but in the video the Git Bash prompt starts up with Welcome to Git (version 1.9.5-preview20141217).

Arbitrary file named "git.exe" in the current folder was executed.

From what I can see in the video it is more like: Git Bash starts as normal and in addition the payload is executed.

@dscho For what it's worth, I can not reproduce with git version 2.10.2.windows.1.

kgybels commented Nov 8, 2016

@mattymcfatty You say you are using Git-2.10.2-64-bit.exe but in the video the Git Bash prompt starts up with Welcome to Git (version 1.9.5-preview20141217).

Arbitrary file named "git.exe" in the current folder was executed.

From what I can see in the video it is more like: Git Bash starts as normal and in addition the payload is executed.

@dscho For what it's worth, I can not reproduce with git version 2.10.2.windows.1.

@mattymcfatty

This comment has been minimized.

Show comment
Hide comment
@mattymcfatty

mattymcfatty Nov 8, 2016

@kgybels Yeah, there were two versions of git installed on my machine. When i noticed the behavior I downloaded the latest version and confirmed the behavior there as well, but I didn't realize there were two competing context menus as in njfox's screenshot above.

The behavior is coming from an old install of mysysgit. The latest version of Git Bash for Windows does not appear to be vulnerable to the same attack. I think we can close this issue out @dscho. Thanks guys for reproducing and helping me solve the mystery.

I cannot reproduce this issue since uninstalling all versions of Git for Windows and re-installing only the latest. This is not a vulnerability for the latest versions.

mattymcfatty commented Nov 8, 2016

@kgybels Yeah, there were two versions of git installed on my machine. When i noticed the behavior I downloaded the latest version and confirmed the behavior there as well, but I didn't realize there were two competing context menus as in njfox's screenshot above.

The behavior is coming from an old install of mysysgit. The latest version of Git Bash for Windows does not appear to be vulnerable to the same attack. I think we can close this issue out @dscho. Thanks guys for reproducing and helping me solve the mystery.

I cannot reproduce this issue since uninstalling all versions of Git for Windows and re-installing only the latest. This is not a vulnerability for the latest versions.

@dscho

This comment has been minimized.

Show comment
Hide comment
@dscho

dscho Nov 9, 2016

Member

Thank you all for testing and figuring this one out!

Member

dscho commented Nov 9, 2016

Thank you all for testing and figuring this one out!

@dscho dscho closed this Nov 9, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment