5

If you clone a git repository, the hooks are not cloned for security reasons I suppose. But what if I get a repository by an other way like a ZIP file? How can I make sure there is no hook executed when I run GIT commands on a repository which I don't fully trust?

What I can think of, is to remove the executable flag of all files in the .git/hook directory. But according to the documentation, the hooks are only normally stored in this directory so there might be other places to clean first. (How to change the hook directory by the way?)

As an example, I'm concerned about a file like the one from this contest:

http://hackyeaster.hacking-lab.com/hackyeaster/challenge12.html

Den
  • 547
  • 1
  • 6
  • 15

3 Answers3

3

You are correct that if you receive a .git directory by some means other than cloning it, it might contain malware, including hooks. (If you're in the habit of downloading arbitrary code from elsewhere and not inspecting it, though, you have more risks than just git hooks.)

As it turns out, there's a bug in older versions of git that fails to prohibit files (tree entries) with names like .Git. If you clone such a repository onto a Linux or Unix box using a case-sensitive file system, you are OK, but if you clone onto a Windows or Mac system using a case-insensitive file system (or set up such a file system on your Linux/Unix box), the name .Git matches the name .git and these older version of git will go ahead and write to .git; so this is a way someone can sneak things into your system even if you use the standard git cloning mechanism.

In Git versions before 2.9, turning off the execution bit in .git/hooks/* will suffice to stop hooks from running (as there are no alternative hook locations). In Git 2.9 or later, you—or whoever owns your configuration file—can configure a core.hooksPath variable to add additional locations from which hooks could run, so this alone is not sufficient. As a general rule, whenever you obtain un-verified code from elsewhere, you should inspect it carefully. Even when using security-certificate signed software (as in, e.g., Apple's software updates for Mac), you might want to use some degree of caution, as mistakes do happen.

torek
  • 448,244
  • 59
  • 642
  • 775
  • "there are no alternative hook locations" is, as far as I understand it, not true - cf. [nbari's answer](https://stackoverflow.com/a/50866196/2748899). – smheidrich Jun 15 '18 at 10:03
  • 2
    @pmos: yes, `core.hooksPath` was introduced in Git 2.9, released in June 2016 (after I wrote the answer). I'll edit it now though. – torek Jun 16 '18 at 02:31
3

Answer to this specific question

I'm researching this myself and surprised at how many caveats there are.

You can just specify a local path as the source repository for git clone, so that's one way to start working on a codebase given to you e.g. as a zipped repo without worrying about its hooks, given that (at least as of June 2018) there are no hooks which are executed on a "remote" repository when it is being cloned.

But even then, you have to be careful to never accidentally run git push in your cloned repo afterwards, as it will trigger the "server-side" hooks in the original repo, again allowing arbitrary code execution! To eliminate the possibility of this happening, it's probably best to remove the reference to the original repo from the cloned repo's remotes altogether.

In conclusion, my suggested "workflow" for this would be:

# instead of cloning normally, we will use --mirror in order to exactly
# replicate the branches of the original repo; unfortunately, this implies
# creating a "bare" repo without working tree (think .git directory).
mkdir -p cloned_repo/.git
# --no-hardlinks to get a "proper" copy
git clone --no-hardlinks --mirror /path/to/original_repo cloned_repo/.git
cd cloned_repo
# turn this into a proper repo with working tree
git config core.bare false
git checkout HEAD
# check if the database has been tampered with
git fsck
# remove remote pointing back to the original repo
git remote remove origin

But it's entirely possible that I've missed yet more issues.

Circumventing the problem

If possible, you could also ask whoever gave you the repo to prepare it using git bundle instead (cf. How to git bundle a complete repo). Bundles can be cloned the same way you would clone a local repo and, to the best of my knowledge, can not contain hooks. In fact, they are specifically designed to enable "offline" git workflows (e.g. via files exchanged on flash drives) and you can also prepare bundles containing only parts of a repo's history.

smheidrich
  • 4,063
  • 1
  • 17
  • 30
2

If you don't need the hooks you can remove them:

rm -rf .git/hooks

If you want to keep them but not execute them, you could temporally change the executable bit:

chmod -x .git/hooks

But probably you will need to also do this to prevent warnings:

git config advice.ignoredHook false

And ensure the path as @pmos comment is using .git/hooks or to an empty path:

git config core.hooksPath .git/hooks
nbari
  • 25,603
  • 10
  • 76
  • 131
  • 2
    The way I understand it, this will **not** in general get rid of all hooks, because the hook path can be changed in a repo's local (!) configuration via the ``core.hooksPath`` option. You'd have to first obtain the value of this option and then delete the path pointed to, but given that it can point to *any* path on the filesystem (not just within the repo!), this comes with issues of its own. Another idea would of course be to just set ``core.hooksPath`` to a path you know is empty. – smheidrich Jun 15 '18 at 08:59
  • chmod? what about Windows users? – Jerry Chin Jul 09 '20 at 05:56