8 ms·

I'm not quite sure what you're saying here. Are you claiming that you can push a commit to userA/project and then view it under the Github web interface for use

I'm not quite sure what you're saying here. Are you claiming that you can push a commit to userA/project and then view it under the Github web interface for userB/project (assuming one repo is forked from the other)? If so it seems like that's a relatively easy fix for Github, just check if the commit is actually contained in userB's fork of the repo.

slimsag 6y ago
Quick demo: go to https://github.com/slimsag/linux/tree/5895e21f3c744ed9829e3afe9691e3eb1b1932ae#linux-kernel https://github.com/slimsag/linux/tree/5895e21f3c744ed9829e3a... then try replacing "slimsag" with "torvalds" These are "known issues" I believe GitHub doesn't intend to fix: 1. With youtube-dl[0] (and probably long before?) we know you can push a commit and view it under the web UI under another user, GitHub hasn't indicated this is a vulnerability at all. 2. Many people know you can impersonate another user through Git email addresses[1] (GPG signing is supposed to solve this, but a lot of people don't use it and even when they do others don't really know they should look for "Verified" in GitHub's web UI.) Combine these two known-issues and you get a really convincing phishing attack. I really hope this doesn't become a common-place thing. Hopefully this raises some awareness that, basically, you should not trust any GitHub URL with a commit SHA in it - only trust ones with branch names - because it could be a phishing attack otherwise. [0] https://news.ycombinator.com/item?id=24882921 https://news.ycombinator.com/item?id=24882921 [1] https://bounty.github.com/ineligible.html#impersonating_a_user_through_git_email_address https://bounty.github.com/ineligible.html#impersonating_a_us...
- tasuki 6y ago
  Very neat! Though I probably wouldn't use a thing from a random hash? I'd go to the repo's main GitHub page and look for branches/tags that interest me. Doesn't everyone do that?
  - raziel2p 6y ago
    I often leave links with a specific hash, just in case the content changes in the future making my link invalid. Others don't even check the URL of the page they're looking at, as long as the link looks legit.
  - eslaught 6y ago
    To echo the sibling comment, I regularly uses hashes because branches can move, and I don't want my links to get stale over time. I don't think I'd release software like that (I'd use a tag), but in bug reports and such I do this all the time.
tkfu 6y ago
> I'm not quite sure what you're saying here. Are you claiming that you can push a commit to userA/project and then view it under the Github web interface for userB/project (assuming one repo is forked from the other)? Very close to that, yes. There's actually just one more step you need to take: you have to also open a pull request from userA/project to userB/project. As a convenience feature, GitHub automatically makes PR commits available under a special namespace. You can try it yourself with any pull request that comes from another repo--just `git fetch origin pulls/<PR #>/head. Since the foreign commit is there in this special 'pulls' namespace, it can be viewed in the web UI by its commit ID. That's how people are adding youtube-dl to github's DMCA notice repo; they're just opening a PR containing youtube-dl's commit history.
Denvercoder9 6y ago
> If so it seems like that's a relatively easy fix for Github, just check if the commit is actually contained in userB's fork of the repo. It's not that easy. First of all, you'd need to define "contained in". The naive choice would be anything reachable by a named ref. However, all pull requests also create a ref in your repository, so you'd need to exclude those. But that would mean that if you make a PR and then delete the branch the PR is made from, the PR contents aren't visible anymore. But even if you have the set of refs that you consider to be in a repository, that means every time an object is requested you'll have to walk the whole graph backwards to find if an object is reachable from a ref. That's an expensive operation, and Git is usually pretty fast because it tries really hard to avoid this.

slimsag 6y ago

Quick demo: go to https://github.com/slimsag/linux/tree/5895e21f3c744ed9829e3afe9691e3eb1b1932ae#linux-kernel https://github.com/slimsag/linux/tree/5895e21f3c744ed9829e3a... then try replacing "slimsag" with "torvalds" These are "known issues" I believe GitHub doesn't intend to fix: 1. With youtube-dl[0] (and probably long before?) we know you can push a commit and view it under the web UI under another user, GitHub hasn't indicated this is a vulnerability at all. 2. Many people know you can impersonate another user through Git email addresses[1] (GPG signing is supposed to solve this, but a lot of people don't use it and even when they do others don't really know they should look for "Verified" in GitHub's web UI.) Combine these two known-issues and you get a really convincing phishing attack. I really hope this doesn't become a common-place thing. Hopefully this raises some awareness that, basically, you should not trust any GitHub URL with a commit SHA in it - only trust ones with branch names - because it could be a phishing attack otherwise. [0] https://news.ycombinator.com/item?id=24882921 https://news.ycombinator.com/item?id=24882921 [1] https://bounty.github.com/ineligible.html#impersonating_a_user_through_git_email_address https://bounty.github.com/ineligible.html#impersonating_a_us...

tasuki 6y ago
Very neat! Though I probably wouldn't use a thing from a random hash? I'd go to the repo's main GitHub page and look for branches/tags that interest me. Doesn't everyone do that?
- raziel2p 6y ago
  I often leave links with a specific hash, just in case the content changes in the future making my link invalid. Others don't even check the URL of the page they're looking at, as long as the link looks legit.
- eslaught 6y ago
  To echo the sibling comment, I regularly uses hashes because branches can move, and I don't want my links to get stale over time. I don't think I'd release software like that (I'd use a tag), but in bug reports and such I do this all the time.

tkfu 6y ago

> I'm not quite sure what you're saying here. Are you claiming that you can push a commit to userA/project and then view it under the Github web interface for userB/project (assuming one repo is forked from the other)? Very close to that, yes. There's actually just one more step you need to take: you have to also open a pull request from userA/project to userB/project. As a convenience feature, GitHub automatically makes PR commits available under a special namespace. You can try it yourself with any pull request that comes from another repo--just `git fetch origin pulls/<PR #>/head. Since the foreign commit is there in this special 'pulls' namespace, it can be viewed in the web UI by its commit ID. That's how people are adding youtube-dl to github's DMCA notice repo; they're just opening a PR containing youtube-dl's commit history.

Denvercoder9 6y ago

> If so it seems like that's a relatively easy fix for Github, just check if the commit is actually contained in userB's fork of the repo. It's not that easy. First of all, you'd need to define "contained in". The naive choice would be anything reachable by a named ref. However, all pull requests also create a ref in your repository, so you'd need to exclude those. But that would mean that if you make a PR and then delete the branch the PR is made from, the PR contents aren't visible anymore. But even if you have the set of refs that you consider to be in a repository, that means every time an object is requested you'll have to walk the whole graph backwards to find if an object is reachable from a ref. That's an expensive operation, and Git is usually pretty fast because it tries really hard to avoid this.