You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
0 commit comments