I got targeted
frankwiles.com
Someone targeted me in an attempt to gain access or credentials because of my Open Source and/or consulting roles
  • lobsters__junot@crustaceanson.theshelf.top
    1·
    12 days ago

    I immediately alerted Dropbox and Vercel’s security teams so they can hopefully take these accounts down before they snag someone. Sadly, they also were impersonating an unspecting development shop owner as part of the ruse.

    Is there a reason not to involve law enforcement in this case? Seems like the author could have been significantly harmed if they weren’t already aware of this attack vector.

    score 1 · canonical

    • lobsters__z3bra@crustaceanson.theshelf.topM
      0·
      13 days ago

      This could be even worse. I assume git does a checkout after cloning a repository, this hook could be triggered right after a clone without your ability to review it.

      Edit: I tried, and git refuses to checkout the file initially :

      $ git clone bad-repo.got
Cloning into 'bad-repo'...
done.
error: invalid path '.git/hooks/post-checkout'
fatal: unable to checkout working tree
warning: Clone succeeded, but checkout failed.
You can inspect what was checked out with 'git status'
and retry with 'git restore --source=HEAD :/'

      So I assume that you’re safe as long as you ALWAYS clone repositories with git, and don’t retrieve the work tree from someone else (like the author was asked to).

      Nothing within git (the repository format) prevents you from commiting a hook though, so it’s up to the frontend to secure against it.

      I also tried with got, and it refuses to checkout the file as well. No idea about jj or other git frontends.

      score 2 · canonical

      • lobsters__atk@crustaceanson.theshelf.top
        1·
        13 days ago

        It’s difficult for the format to do anything about this. You’d need to come up with a way of encoding a path which had no representation for paths starting with .git/.

        This attack path has been known about for a long time. And git has refused to check out files at paths starting with ./git for as long as I remember.

        There was a bug on windows years ago due to its case insensitive FS.

        Generally treat any .git directory that git itself has not created as a live grenade.

        score 1 · canonical

  • lobsters__carlomonte@crustaceanson.theshelf.top
    0·
    13 days ago

    This is the price for having one universal tool and for having a monoculture based on it. Separation of concerns (earlier Unix) is still a sound engineering principle. Competition also helps. Without someone stealing their user base, Git will never touch such issues, for the sake of maintaining compatibility.

    It might be that it was not the developers who turned their backs at Mercurial, Fossil and others, but the Hubs and the Labs. Maybe JJ shows us a way out of this situation.

    score 1 · canonical

    • lobsters__toastal@crustaceanson.theshelf.topM
      1·
      13 days ago

      I’ve been kicking it primarily with Darcs (still holding out for Pijul tooling). I have been trying to build tooling to help VCS polyculture too which usually ends up being one of the primary reasons folks stick with Git.

      score 1 · canonical

      • lobsters__stephenr@crustaceanson.theshelf.topM
        1·
        13 days ago

        Welp I blame reading it… I dunno, without coffee. Maybe too much coffee?

        I knew it was a git clone in a dropbox folder, and somehow my brain read that line (even when I quoted it in my comment) as “a folder that had several folders of Make files”, and immediately I had visions of crazy people who know what Make is, but also put those Make files in Dropbox.

        As the great man said, egg and my face, are in alignment.

        score 1 · canonical

  • lobsters__agwa@crustaceanson.theshelf.top
    0·
    13 days ago

    An even more devious attack is to ship a .git/config file with the core.fsmonitor option set to a malicious command. This command gets executed by many different git operations, including very basic ones like git status.

    This is rather nasty because several other programs like to implicitly run git status, including IDEs, go build, and fancy shell prompt integrations that e.g. show the current branch. I disabled all of my git shell integrations and set GOFLAGS=-buildvcs=false after I learned about core.fsmonitor.

    Note that git itself refuses to check out a .git directory from a remote repo so running git clone, git pull, etc. can never install a malicious config or hook, but if you install directory trees from any other source, like a tarball, a different VCS, or Dropbox (as in this article), you have to watch out for .git directories.

    score 1 · canonical

  • lobsters__steinuil@crustaceanson.theshelf.topM
    0·
    13 days ago

    This is not the first attack I read about on here that involves git hooks. IMO the implementation is kind of insane and lends itself very well to this kind of attack. git basically treats the local .git directory as trusted probably because it believes that git repositories can only come from a clone (or init) operation, which has additional checks for hooks, but as we see here that is not always the case!

    I don’t like git hooks in general but I think a better trust model would look similar to direnv’s. .envrc files must be explicitly allowed for them to run, and the hashes of the file and path of allowed .envrc files are stored in an allowlist in .local/share/direnv, which is (generally) outside of the bounds of any repo. It’s not perfect: if the .envrc file contains use flake you won’t get another prompt when the flake.nix file changes, but I think it’d be a reasonable improvement.

    score 1 · canonical