GitHub Vulnerability Puts 4,000+ Repositories at Risk of Repo Hijack

So, there’s some news in the GitHub world, and it’s not great. A vulnerability was found that could have made more than 4,000 repositories vulnerable to repo hijacking. Let’s break this down. Repojacking, or “repo hijacking” for short, is a sneaky move where someone takes over a repository. They can bypass security measures and essentially gain control of it. Not good, right? The problem here is what’s called a “race condition.” This allows attackers to mess around during the creation of a repository and renaming of usernames. Not cool.

Elad Rapoport, a security researcher at Checkmarx, explained that if someone exploited this issue, it would affect a bunch of code packages in different languages like Go, PHP, and Swift. Plus, it could mess with GitHub actions. That’s not something we want. The good news is that GitHub didn’t sit around twiddling their thumbs. They got wind of this problem and did the responsible thing by disclosing it on March 1, 2023. And by September 1, 2023, they’d fixed the issue. Kudos to them for that. To understand why this was a big deal, we need to dive into the concept of “repository namespace retirement.” It’s like an extra layer of security. When a user changes their username, this mechanism stops others from making a repository with the same name if it already has more than 100 copies. It’s like calling “dibs” on the name. But if this safeguard could be easily bypassed, it would be bad news. Threat actors could create new accounts with the same username and upload malicious stuff. We definitely don’t want that to happen.

So, here’s how the whole repo jacking thing went down:

1. Somebody has the namespace “victim_user/repo.”
2. They decide to change their username from “victim_user” to “renamed_user.”
3. Now, the “victim_user/repo” repository is considered “retired,” meaning it’s locked.
4. Then, a sneaky person with the username “attacker_user” swoops in. They create a new “repo” and quickly change their username to “victim_user.”

All of this happens super fast, using API requests for creating repositories and renaming usernames. Sneaky, right? This discovery comes not long after GitHub patched a similar issue. It shows that these threats are persistent. GitHub acted fast to fix this vulnerability, but it’s a reminder that security in the open-source world is an ongoing battle. The community needs to stay on its toes to keep these valuable repositories safe from repo hijacking. Nobody wants their code to fall into the wrong hands, right?