Live data from Hacker News

Anyone can access deleted and private repository data on GitHub

trufflesecurity.com

171–180 of 394 posts

Re: Anyone can access deleted and private repository data on GitHub

#171
post #99

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?

I've seen bots make that kind of PR spam a few times. They'll make a PR that adds a random HTML or markdown file or whatever containing gambling spam or whatever and then presumably post links to github.com/$yourorg/$yourrepo/blob/$sha/thatfile I can't link an example because all the ones I know about were nuked by GH Support.

Re: Anyone can access deleted and private repository data on GitHub

#172
post #106

Earlier 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…

Yeah, and we can blame a lot of that on the Git developers, but they never use words like ‘public’ and ‘private’ to indicate things they’re not.

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

#173

This is not new. Many people have noticed this before, e.g. https://hikari.noyu.me/blog/2020-05-05-github-private-repos-...

No but I think attention should still be raised to it in the hopes they will fix it. The squeaky wheel gets the grease.

https://xkcd.com/1053

Re: Anyone can access deleted and private repository data on GitHub

#174

Earlier 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…

> The incentives you create by paying for every random non-vulnerability are really bad.

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

#175
post #99

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?

It can be used to make it look like another project posted the content (though there is a warning: "This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.").

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

#176
post #99

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?

>Can this be used to host illegal content?

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

#177

Users 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

> I'll be calling "private" repos "unlisted"

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

#178
post #17

Surprised 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.

> I've used github for a long time, would not have expected these results, and was unnerved by them.

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

#179

Earlier 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…

As the author pointed out, the documentation was written three years after he reported it.

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

#180

Earlier 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…

> it is very natural that GitHub would take the "once public always public" line

I don’t think that follows at all. Purging hashes without a link to a commit/repository would be pretty natural.

Post reply on HN