Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Anyone can access deleted and private repository data on GitHub

trufflesecurity.com

Post reply on HN
Print view View original

281–290 of 394 posts

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

#281

Post by hnbad »

dncornholio wrote: post #271
majorchord wrote: post #173

Earlier quoted context omitted.

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

There's nothing to be fixed though.

If people are surprised by this - and clearly a non-trivial number of people are - then even if the behavior works as intended it should be indicated in the UI at critical points.

GitHub is not simply a UI to actual git repositories it hosts. It also carries a lot of data that is not stored in the repository itself. The UI deliberately blends the two types of interactions. There's no such thing as "creating a pull request" in git, for example.

It's not at all unreasonable for a user to assume "forking" merely creates a copy with an upstream origin. Read through the steps again:

    1. You fork a public repository
    2. You commit code to your fork
    3. You delete your fork
Note that from a user's point of view, they only committed code to their "copy" of the repository, i.e. their own repository. They never pushed it upstream or created a pull request that references it. That abstraction is clearly wrong if you look at what actually happens but it's not difficult to see why a user might think this way, especially given that "a fork" often simply means "a copy", i.e. something standalone that then goes on to diverge from its origins (e.g. "Edge is a fork of Chromium" or "MariaDB is a fork of MySQL").

Of course the mistake is that the fork is not a copy. The fork isn't a fork (i.e. a separate copy that shares the original's history), it's a view of the original repository with its own refs. The commits are added to the same repository, only the refs that reference them aren't. This makes sense architecturally but it means most metaphors and analogies people likely bring to the table break down because they assume a fork is a copy, not a collection of refs layered over a shared repository of commits - after all "allowing stranges to add commits to the repository" is what PRs are for. Except of course that's not what PRs do then, PRs actually allow strangers to add references to commits to your branches.

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

#282

Post by InsomniacL »

er4hn wrote: post #103
thih9 wrote: 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?

One can safely assume they will find a way to follow the law rather than mumble about technically this is working as intended.

> One can safely assume

With something as nuance as this, I wouldn't safely assume all processes, especially one from a compliance (none-technical) department account for it.

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

#283

Post by brazzledazzle »

rocqua wrote: post #259
rkagerer wrote: post #241

Earlier quoted context omitted.

Am I the only one who finds this conceptually confusing?

Nope, me too. The whole Repo network thing is not User facing at all. It is an internal thing at GitHub to allow easier pull requests between repo's. But it isn't a concept git knows, and it doesn't affect GitHub users at all except for this one weird thing.

I may be recalling incorrectly but I seem to remember it having some storage deduplication benefits on the backend.

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

#284

Post by K0balt »

malfist wrote: post #84
YetAnotherNick wrote: post #76

Earlier quoted context omitted.

But that would still means they didn't intend to fix it, hence not giving bounty is fair.

It's a bug bounty, not a "only if we have time to fix it" bounty. He found a security problem, they decided not to act on it, but it was still an acknowledged security problem

The property (“bug”) in question is an inherent and intentional property of meekly-tree type storage systems such as git.

Calling this a bug is like reporting that telnet sends information unencrypted.

The actual bug is in the way that their UX paradigm sets user expectations.

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

#285

Post by noname120 »

ilikehurdles wrote: post #33
cxr wrote: post #6

> The implication here is that any code committed to a public repository may be accessible forever That's exactly how you should treat anything made available to the public (and there's no need for the subsequent qualifier that appears in the article—" as long as there is at least one fork of that repository ").

Sometimes I wonder if all the security features GitHub slathers on top of `git` lull people into a false sense of security when fundamentally they're working in a fully distributed version control system with no centralized authority. If your key is leaked the solution is to invalidate the key not just synthetically alter your version of history to pretend it never happened.

Unless you specifically know and understand the ramifications of this GitHub idiosyncrasy, you have no way to tell that your key was possibly leaked. GitHub never informs you that someone accessed a commit created in your private fork.

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

#287

Post by hmottestad »

umpalumpaaa wrote: post #118
pants2 wrote: post #80

Earlier quoted context omitted.

Any time you make a private repo public it’s best to just copy that code into a new public repo and leave the private repo private. Otherwise have to audit every previous commit and every commit on every fork of your private code.

If I understand the issue correctly if you make the original repo public any private forks from other users are also effectively public. Right?

Seems to be the case yes. And I guess that the authors of those repos will not get a notification of any sort.

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

#288

Post by account42 »

liendolucas wrote: post #25
andersa wrote: post #4

I reported this on their HackerOne many years ago (2018 it seems) and they said it was working as intended. Conclusion: don't use private forks. Copy the repository instead. Here is their full response from back then: > Thanks for the submission! We have reviewed your report and validated your findings. After internally assessing the finding we have determined it is a known low risk issue. We may make this functional…

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…

Disagree. This is obviously a deliberate design choice with obvious implications. Expecting a bounty for reporting this is unreasonable. These kind of beg bounties are exactly what gives security "researchers" a bad name.

The security implications are also minor. The only problem really is with making a fork of a private repo public - that should only make what exists in that fork public and not any other objects. Something that was already public staying public even when you delete it from your repo is not a security issue at all. Keys you have ever been pushed to a public repo should be revoked no matter what, with or without this GitGub feature.

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

#289

Post by account42 »

oxfordmale wrote: post #179
kayodelycaon wrote: post #31

Earlier quoted context omitted.

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

The expectations for AWS and public repository hosting are not the same. If you leaked something to a public GitHub repo you should assume that it has been cloned the second you pushed it.

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

#290

Post by account42 »

cyrnel wrote: post #69
liendolucas wrote: post #25

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…

Security disclosures are like giving someone an unsolicited gift. The receiver is obligated to return the favor. But if you buy someone non-refundable tickets to a concert they already have tickets for, you aren't owed compensation.

> Security disclosures are like giving someone an unsolicited gift.

Exactly.

> The receiver is obligated to return the favor.

Not at all. This is a very toxic expectation.

Post reply on HN