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

331–340 of 394 posts

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

#331

Post by _cenw »

I found some obscure instances where user expectation doesn't match reality on GitHub before, and nobody there cares.

If anyone's wondering: Organizations that require SAML are included in your organizations even when you don't have a SAML session when signing in elsewhere via OAuth. Unlike generalized per-organization app authorizations, where GitHub can actually hide organization membership. Only way to find out if a user has a SAML session is for the consuming app to request the membership with your token, and interpret 403 as "no SAML session". As far as I know only Tailscale implemented this. This really sucks for apps like SonarCloud where someone can now view work code from their so cleanly separated personal and professional use GitHub account.

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

#332

Post by [deleted] »

jiggawatts wrote: post #254
cellis wrote: post #231

Earlier quoted context omitted.

Putting keys in repos should not be done, full stop. Even if GitHub forks weren’t public, their _private_ repos could one day be compromised. Instead, store keys in a shared vault, .gitignore the .env and have a .env.example with empty keys.

Any time I hear “shouldn’t be done” I translate that to “will happen regularly”. I do see this regularly in my work. All but one dev team I’ve worked with over the last few years has done this.

[deleted]

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

#333

Post by Eisenstein »

cellis wrote: post #231
jiggawatts wrote: post #217

Earlier quoted context omitted.

> If you published a key Why would anyone think that a private fork is "published"!? This is the footgun here: The UI is telling you that nobody can see the secrets you committed to your private copy , but actually it is widely accessible. A similar example of UI-vs-reality mismatch that I've noticed recently is the Azure Store Account "public" visibility. By default, it uses your authenticated account for RBAC acces…

Putting keys in repos should not be done, full stop. Even if GitHub forks weren’t public, their _private_ repos could one day be compromised. Instead, store keys in a shared vault, .gitignore the .env and have a .env.example with empty keys.

Don't blame the end user for doing something you don't want them to do if it is more convenient to do and works without immediate consequences. Redesign it or rethink your assumptions.

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

#334

Post by barco »

account42 wrote: post #288
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…

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. So…

I reported a variant of this issue that (to me) was unexpected:

* You add someone to your private repo.

* After some time, you revoke their access.

As long as they keep a fork (which you can't control) they can use this same method to access new commits on the repo and commits from other private forks.

Back in 2018, this was a resolved as won't fix, but it also wasn't documented.

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

#335

Post by marcosdumay »

reisse wrote: post #303
pcthrowaway wrote: post #218

Earlier quoted context omitted.

OK but say a company has a private, closed source internal tool, and they want to open-source some part of it. They fork it and start working on cleaning up the history to make it publishable. After some changes which include deleting sensitive information and proprietary code, and squashing all the history to one commit, they change the repo to public. According to this article, any commit on either repo which was m…

> After some changes which include deleting sensitive information and proprietary code, and squashing all the history to one commit, they change the repo to public. I know this might look like a valid approach on the first glance but... it is stupid for anyone who knows how git or GitHub API works? Remote (GitHub's) reflog is not GC'd immediately, you can try to get commit hashes from events history via API, and then…

Yes, even though I expect there to be people that do exactly what the GP describes, if you know git it has severe "do not do that!" vibes.

Do not squash your commits and make the repository public. Instead, make a new repository and add the code there.

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

#337

Post by tptacek »

berdario wrote: post #315
tptacek wrote: post #115

Earlier quoted context omitted.

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…

That's true, but what's stopping a company from documenting a security issue as a known (mis)behaviour/bug? [*] Companies can join/setup a bug bounty program, and just use it as a fig leaf for pretending to care about their own product/service's security. Of course bug bounties can and are abused daily by people who report trivial non-issues in the hope of compensation But in the same way, companies can also be bad a…

No large company cares even a tiny bit about the money they're spending on bug bounties. They would literally lose money trying to cheat, because it would cost them more in labor to argue with people than to pay out. In reality, the bounty teams at Google and Apple are incentivized to maximize payouts, not minimize them.

If you don't trust the company running a bounty, don't participate. There are more lucrative ways to put vulnerability research skill to use.

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

#338

Post by phito »

barnabee wrote: post #325
niam wrote: post #316

Earlier quoted context omitted.

There's got to be a word for these kinds of ridiculous arguments which use personal responsibility as a cudgel against a systematic fix. I agree generally that interfaces have been dumbing down too far, but "private is actually not private and it's on you for not knowing that, idiot B)" is a weird place to be planting that flag.

There should probably also be a word for the belief that when a system doesn't work how you want it to, that is so obviously a systematic problem that needs fixing rather than, for example, evidence of differing goals or priorities that it is reasonable to describe anyone who thinks otherwise as ridiculous.

That means having an opinion

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

#339

Post by tptacek »

raesene9 wrote: post #298
tptacek wrote: post #111

Earlier quoted context omitted.

No large company running a bug bounty cares one iota about stiffing you on a bounty payment. The teams running this programs are internally incentivized to maximize payouts; the payouts are evidence that the system is working. If you're denied a payment --- for a large company, at least --- there's something else going on. The thing to keep in mind is that large-scale bug bounty programs make their own incentive weat…

In my (admittedly limited) experience, whilst payouts for bugs might be seen as a positive internally, payments for bad architecture/configuration choices are less so (perhaps as they're difficult to fix, so it's politically not expedient to raise them internally). To provide one example I reported to a large cloud provider that their managed Kubernetes system exposed the Insecure port to the container network, meani…

Repeating myself: this almost certainly has nothing at all to do with the money they'd have to give you (I assure you, if there's even a whiff of legitimacy to your report, the people managing the bounty would probably strongly prefer to pay you just to get you off their backs) and everything to do with the warped incentives of paying out stuff like this. People forget that the whole point of a bug bounty is that the rewarded bugs get fixed; the bounty is directing engineering effort. If it directs them to expensive work they already made a strategic decision not to do, the bounty is working against them.

You would prefer this company to have made a different strategic choice about what to spend engineering time on, and that's fine. But engineering cycles are finite, so whatever time they'd spend configuring K8s differently is time they wouldn't be spending on some other security goal, which, for all we know, was more important. Software is fathomlessly awful, after all.

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

#340

Post by dumbo-octopus »

UweSchmidt wrote: post #328
dumbo-octopus wrote: post #320

Earlier quoted context omitted.

We are missing the point here. The GP was claiming that delete meant something other than adding a mark to an item that you want to eventually be removed from the system. It doesn’t.

I understand that you describe the status quo in many systems today. However, besides the technical aspect you talked about the "absolute best you could expect when asking for a delete in the UI^". I think this where I, other posters in the thread, most people, and probably the GDPR and other legislature, would disagree. We expect significantly more effort to clean up deleted data. This includes, for example, the abi…

> GDPR and other legislature

Nope. GDPR allows deleted data to be retained in backups so long as there is an expiration process in place. Doesn’t matter how long it is. But certainly nobody has a right to forcing a company to pull all of their backups from cold storage and trove through them all any time any deletion request takes place. That’d be the quickest path to Distributed Denial of Bank Account Funds imaginable. Even the GDPR isn’t that bone-headed.

But yes, it is part of the law that the provider should tell you that your data isn’t actually being erased and instead it will be kept around until they get around to erasing everything as part of their standard timelines. But that knowledge doesn’t do anyone much good.

> CNIL confirmed that you’ll have one month to answer to a removal request, and that you don’t need to delete a backup set in order to remove an individual from it.

https://blog.quantum.com/2018/01/26/backup-administrators-th...

Post reply on HN