Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
fix(git-checkout): fix a critical security issue reported by @drivertom
the security issue would lead to arbitrary file writing on the user's machine, which could be extremely dangerous when some critical file be overwritten (eg: the crontab file, ssh-keys) The root cause of this issue is that the .git folder leakage is an abnormal scene of manipulating the git repository. When we executing `git clone`, there are multiple steps to do. 1. download the internal objects into the `.git` folder and **CHECK the VALIDITY** of all object files. 2. perform `checkout` to extract the current content of the `.git` folder. git will completely *TRUST* the object files of the .git folder cause they are already be checked. But when hackers use `GitHacker` (or other similar tools like git-dumper) to exploit the `.git` folder leakage vulnerability. These tools will just simply download the `.git` folder directly, then perform `git checkout .`. The critical thing is that the developer of these tools just trusts the `git checkout .` will do the check, but unfortunately, `git checkout .` doesn't. git assume that before checking out, the .git folder is already been verified. To **fix** this issue, I just use `git clone instead of `git checkout .` (`git clone` is able to clone a folder on the file system, ref: https://git-scm.com/docs/git-clone#_git_urls). It's a simple but dirty fix. The best way to fix this issue is to let git verify the .git folder when performing `checkout`, but it seems that is not possible. :( To **summarise**, git does the right thing, the developer does the right thing too. All the evil thing comes from the weird scenario of git leakage.
- Loading branch information