Can this be used to host illegal content? I.e.: fork a popular repo, commit a pirated book to the fork, delete the fork, use the original repo to access the pirated book? What would github do after receiving a DMCA request in that case?
Anyone can access deleted and private repository data on GitHub
171–180 of 394 posts
Re: Anyone can access deleted and private repository data on GitHub
#172Earlier quoted context omitted.
> As the article pointed out, GitHub already publicly documented this vulnerability. I'm honestly not yet convinced that is enough here - I've fallen victim to this without realizing it - the behaviour here is so far removed from how I suspect most user's mental model of github.com works. For me none of the exposed data is sensitive, but the point remains I was totally unawares it would be retrievable like this. If t…
The problem with this line of argument is that the fundamental workings of git are also surprising to people, such that they routinely attempt to address mistaken hazmat commits by simple reverts. If at bottom this whole story is just that git is treacherous, well, yeah, but not news. There's a deeper problem here, which is that making the UX on hosting sites less surprising doesn't fix the underlying problem. There…
Regardless, the vulnerability in Github forks falls squarely on Github, and is not mitigated by Git being hard to understand in the first place.
Re: Anyone can access deleted and private repository data on GitHub
#173This is not new. Many people have noticed this before, e.g. https://hikari.noyu.me/blog/2020-05-05-github-private-repos-...
Re: Anyone can access deleted and private repository data on GitHub
#174Earlier quoted context omitted.
I can see this argument making a bit of sense, but if they documented this 3 years after the issue was reported, they don't have a way to demonstrate that they truly already knew. At the end it boils down to: is Github being honest and fair in answering the bug bounty reports? If you think it is, cool. If you don't, maybe it's not worth playing ball with Github's bug bounty process
It doesn't matter if they knew. If they don't deem it a security vulnerability --- and they have put their money where their mouth is, by documenting it as part of the platform behavior --- it's not eligible for a payout. It can be a bug, but if it's not the kind of bug the bounty program is designed to address, it's not getting paid out. The incentives you create by paying for every random non-vulnerability are real…
So much this. It's pretty clear that most people commenting on this thread have never been involved in a bug bounty program on the company's side.
Bug bounty programs get a lot of reports, most of which are frankly useless and many of which are cases of intended behavior subjectively perceived as problematic. Sifting through that mess is a lot of work, and if you regularly pay out on unhelpful reports you end up with many more unhelpful reports.
This particular case definitely feels like one where the intended behavior is horribly broken, but there are absolutely many cases where "this is intended" is the only valid answer to a report.
Re: Anyone can access deleted and private repository data on GitHub
#175Can this be used to host illegal content? I.e.: fork a popular repo, commit a pirated book to the fork, delete the fork, use the original repo to access the pirated book? What would github do after receiving a DMCA request in that case?
You can't host anything this way that you can't already host in your own repository, and GitHub does have a way to remove content that will make it inaccessible, whether in your repository or through another.
Re: Anyone can access deleted and private repository data on GitHub
#176Can this be used to host illegal content? I.e.: fork a popular repo, commit a pirated book to the fork, delete the fork, use the original repo to access the pirated book? What would github do after receiving a DMCA request in that case?
It already is. Even to github org's own repos. Any time you make a PR, the /tree/ link to it stays valid forever, even if the repo author removes it.
Re: Anyone can access deleted and private repository data on GitHub
#177Users should never be expected to know these gotchas for a feature called "private", documented or not. It's disappointing to see GitHub calling it a feature instead of a bug, to me it just shows a complete lack of care about security. Privacy features should _always_ have a strict, safe default. In the meantime I'll be calling "private" repos "unlisted", seems more appropriate
That might be a bit too strict. I'd still expect my private repos (no forks involved) to be private, unless we discover another footnote in GH's docs in a few years ¯\_(ツ)_/¯
But I'll forget about using forks except for publicly contributing to public repos.
> Users should never be expected to know these gotchas for a feature called "private".
Yes, the principle of least astonishment[0] should apply to security as well.
[0] https://en.wikipedia.org/wiki/Principle_of_least_astonishmen...
Re: Anyone can access deleted and private repository data on GitHub
#178Surprised at the comments minimizing this. I've used github for a long time, would not have expected these results, and was unnerved by them. I'd recommend reading the article yourself. It does a good job explaining the vulnerabilities.
So you've used it heavily, but haven't read the docs or thought about how forks work, and are now surprised. This seems like a learning opportunity, read the docs for stuff you use heavily, read the man pages and info pages for tools you rely on.
None of this seemed surprising to me, perhaps because I've made PRs, seen that PRs from deleted repositories are still visible, and generally have this mental model of "a repository fork is part of a network of forks, which is a shared collection of git objects".
Re: Anyone can access deleted and private repository data on GitHub
#179Earlier quoted context omitted.
Honest question. Submitting these types of bugs only to get a: "we have determined it is known low risk issue..." seems like they really don't want to pay for someone else's time and dedication in making their product safer. If they knew about this, was this disclosed somewhere? If not I don't see them playing a fair game. What's the motivation to do this if in the end they can have the final decision to award you or…
As the article pointed out, GitHub already publicly documented this vulnerability. My employer doesn't pay out for known security issues, especially if we have mitigating controls. A lot of people spam us with vulnerability reports from security tools we already use. At least half of them turn out to be false positives we are already aware of. In my opinion, running a bug bounty program at all is a net negative for u…
Beyond that is is also a batshit crazy implementation. Just I imagine AWS would still allow AWS credentials to give access to a deleted account
Re: Anyone can access deleted and private repository data on GitHub
#180Earlier quoted context omitted.
> For the first two, git is based on content addressable storage, so it makes sense that anything that is every public will never disappear. this isn't quite right content addressable storage is just a mean of access it does - not imply content cannot be deleted - not imply content cannot be access managed you could apply this to a git repo itself (like making some branches private and some not) but more important fo…
You're right that I shouldn't have given the impression that content addressed storage means as a technical matter that public content must never disappear. The phrasing was a bit sloppy. GitHub could, as a technical matter, choose to hide content that had previously been made public. Nonetheless, given that GitHub exists to facilitate both anonymously pulling the entire history of the repository, and given that any…
I don’t think that follows at all. Purging hashes without a link to a commit/repository would be pretty natural.