15 ms·
Millions of GitHub repos likely vulnerable to RepoJacking, researchers say
- 1lint 3y agoAnother reason to include commit ids in the url when fetching files from external repos. I think you should do this anyways in case the external repo maintainer makes a change that silently breaks your build script
- slimsag 3y agoThat won't help you very much. There's no guarantee the commit belongs to the named repository with e.g. raw links[0]. [0] https://twitter.com/slimsag/status/1672421999698903043 https://twitter.com/slimsag/status/1672421999698903043
- faangsticle 3y agoOf course it will, since you'll either get the commit you wanted at the time you wrote the script, or an error.
- bqmjjx0kac 3y agoUnless someone is very good at finding SHA1 collisions.
- glandium 3y agoIf you clone the repo, it won't be there.
- ewhauser421 3y agoJust verify the SHA of the tarball a la Bazel?
- glandium 3y agoRemember when git archive changed its format and that affected archives downloaded from github?
- tedunangst 3y agoWhat if there were some way to specify a difficult to forge checksum for your dependencies?
- rrdharan 3y agoThey could call it an SBOM...
- codetrotter 3y agoI think tedunangst is referring to https://man.openbsd.org/signify.1 https://man.openbsd.org/signify.1
- tedunangst 3y agoEven simpler than that, something like bsd ports distfiles checksums, or go.sum, or whatever. If you depend on something, you should know what that something is, and you should have some measure of it in your code/project.
- throwaway892238 3y agoLike a SBOM
- remram 3y agoLike a commit hash?
- deleted 3y ago[deleted]
- ashishbijlani 3y agoWe carried out a similar analysis using Packj tool [1] and found that a large number of repos are vulnerable to supply-chain attacks. We received a bunch of bounties for reporting vulnerabilities. Hopefully, these findings will bolster open-source security. 1. http://github.com/ossillate-inc/packj http://github.com/ossillate-inc/packj flags vulnerable/malicious NPM/PyPI/Rubygems/Cargo/Packagist packages. I'm the lead dev.
- runlevel1 3y agoThe redirect behavior gives users the false impression that the old organization name is still permanently associated with them. Making that the actual behavior seems like the easy solution here. If GitHub is concerned with people burning through names, they could either limit the number of changes before you have to reach out to support or limit the redirect behavior to just the last two org names.
- djbusby 3y agoOr just return a 410 and force folk to deal with the situation when their dependency breaks. I'm not convinced the convenience outweighs the risk. Especially given how many folk are just out here git-cloning random stuff from unvetted "vendors".
- deleted 3y ago[deleted]
- sublinear 3y ago> Also, because the instructions included an "npm install" command for the dependency, the attacker's code would achieve arbitrary code execution on the devices of unsuspecting users. This is debatable. If the owner unpublishes their old releases, then the npm install would simply fail and the package reference string is burned forever. I don't like the implication this post makes that other package managers don't require code execution to install, or that npm is somehow more vulnerable. > Registry data is immutable, meaning once published, a package cannot change. We do this for reasons of security and stability of the users who depend on those packages. So if you've ever published a package called "bob" at version 1.1.0, no other package can ever be published with that name at that version. This is true even if that package is unpublished. https://docs.npmjs.com/policies/unpublish https://docs.npmjs.com/policies/unpublish https://docs.npmjs.com/cli/v9/commands/npm-unpublish https://docs.npmjs.com/cli/v9/commands/npm-unpublish To hijack an npm package is to exploit sloppy code review somewhere in the dependency tree. The registry has nothing to do with this. Being aware of this policy, requiring maintainers to review all changes to "package-lock.json", and keeping this lock file in your repo ("npm-shrinkwrap.json" for releases) entirely mitigates this. https://docs.npmjs.com/cli/v9/configuring-npm/package-lock-json https://docs.npmjs.com/cli/v9/configuring-npm/package-lock-j... It's also important to regularly run npm audit on all releases and unpublish if vulnerabilities are found in the dependency tree of that lock file. It's better to break someone's build and leave a note that they need to upgrade than be part of the problem. Even further, npm audit reports are shown to the end user after an npm install so they can decide for themselves in the event the maintainers haven't unpublished yet (or ever). https://docs.npmjs.com/cli/v9/commands/npm-audit https://docs.npmjs.com/cli/v9/commands/npm-audit
- EdwardDiego 3y ago> that other package managers don't require code execution to install But that's more or less true. Arbitrary code execution isn't a feature needed when installing packages for other languages that don't use C bindings so heavily. You're spot on that Node.js isn't alone, Python packages are very much the same in that packages can require code execution to install. But not all packaging systems require the ability to execute package provided code in order to install some packages. But then, in those languages, binding to C libs is far far less common.
- lol768 3y agoI'm pretty sure GitHub warns you every single time you pull from or push to a repository where the organisation or repository has been renamed and you're relying on an alias that is not permanent. Why is this news, and why does it need a name of "RepoJacking" assigned to it when the behaviour is working exactly as designed? This isn't a novel vulnerability, and I wouldn't say any novel vulnerability research has been conducted here. Sure, there's some value in doing a code search and finding instances where people have automated scripts etc relying on aliases, but the vulnerability lies within these scripts.
- deleted 3y ago[deleted]
- kristopolous 3y agoAll mutable global namespaces have the same problems. I didn't know you could get street cred pointing this out one by one. Let's try! If someone buys an expired domain and installs an SSL cert on it then old scripts will think it's legit. Let's call it phantomain, a combination of phantom and domain.
- topato 3y agoNo no! That's gotta be Ghomainjacking, two buzzwords in one AND ghosts are waaay spookier! Phantoms evoke too much imagery of incels in masks, singing on boats.
- kristopolous 3y agoI was also trying to allude to Saint-Domingue, the French colony which France woke up one day to realize it no longer had and "sans domain", which are way too nerdy. Let's go with yours Ghomainjacking but it's pronounced fimainjacking using the gho from ghoti because it's in the class of phishing attacks using a collision you didn't realize was possible
- SoftTalker 3y agoFirst thing I thought of too. If you've acquired a company, you'll need to plan on keeping the old domain names for a long time, if not indefinitely. Anyone who can later re-register that domain will now own any email sent there and any other network traffic as well.
- deleted 3y ago[deleted]
- throwaway892238 3y agoThere are, currently, millions of exploits that are just ready to be taken advantage of, and we have no idea where they are, no way to detect them (because they could all be way upstream), and no way to stop them. That's kind of a big deal. Like an existential, massive, unsolvable, imminent disaster kind of deal. It's such a big deal that I don't think anyone's going to take it seriously until the compromises start coming in waves. Just one of these compromises could affect thousands of projects. If there are millions of potential exploits? We're talking, like, the majority of the modern software landscape now has a giant hole in it. Not a potential hole, but, actively, right now, is exploitable.
- flangola7 3y agoFine-tuned LLMs will make this nice and scalable. I look forward to the coming hacknado.
- hardwaregeek 3y agoI've thought about this a lot when building GitHub integrations. It's so so so easy to use a GitHub username or an email as the link to the GitHub account. In fact, I don't even know how you connect an account to GitHub in a persistent manner. Email is slightly better because the odds that someone takes a specific email is pretty unlikely, but hey, domains expire too. Does GitHub give you a unique, guaranteed to never change id that corresponds to an account? They should.
- eslaught 3y agoYes: https://api.github.com/users/<userhandle> https://api.github.com/users/<userhandle> From: https://github.com/NixOS/nixpkgs/blob/master/maintainers/maintainer-list.nix https://github.com/NixOS/nixpkgs/blob/master/maintainers/mai...
- hardwaregeek 3y agoIs it guaranteed to not change?
- LoganDark 3y agoGitHub user IDs look like "4723091" (there's mine). If you look at the IDs for multiple accounts, you'll very quickly notice that they seem to have been assigned sequentially at registration time. Fairly sure this is a permanent deal.
- hardwaregeek 3y agoWhat's tricky is that GitHub API docs[1] appears to explicitly recommend passing the username and not the ID. Both the GraphQL and the REST versions tell you to get a user by passing a username. [1]: https://docs.github.com/en/rest/users/users?apiVersion=2022-11-28#get-a-user https://docs.github.com/en/rest/users/users?apiVersion=2022-...
- LoganDark 3y ago
- AHOHA 3y agoAnother reason not use github.
- taftster 3y agoWhat would you suggest as an alternative? Do you have a list of github problems that tips you over to said alternative(s)?
- jeffkeen 3y agoI’d love to clickjack some repos to merge some PRs.