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

341–350 of 394 posts

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

#341

Post by thrdbndndn »

Rizz wrote: post #299
thrdbndndn wrote: post #219

I cannot access the commit https://github.com/trufflesecurity/trufflehog/commit/7bc0b shown in one of the pictures in the article (right before "Where do you get these hash values") despite this repo is even public. What gives?

As mentioned it works for valid short hashes, if there are multiple commits with those first 5 characters then you need to make it more specific by bruteforcing, appending a 2, 4, 7, or 8 will lead to a valid commit.

But the author can visit it fine as shown in the picture? https://framerusercontent.com/images/B0wRJU4mjHvmKdy7mpZ3Z3w...

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

#343

Post by dumbo-octopus »

8organicbits wrote: post #329
dumbo-octopus wrote: post #322

Earlier quoted context omitted.

Going back to the point of the the thread, we agree the deleted data is not erased. The user is unable to access it through normal mechanisms, but the existence of side channels that could reveal it does not negate the idea that it has truly been “deleted”, especially when one looks at the historical context surrounding that word.

What? I don't agree with that. Can you point to an example of a modern database that "supports deletion" but keeps the data around forever? Maybe I've just used different tools than you. Knowing modern data retention concerns I'd be surprised if such a thing existed.

Who said anything about that? We’re talking about side channels and eventual^TM deletion. Given enough time no information will remain anywhere, sure. But that’s not very relevant.

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

#344

Post by hunter2_ »

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

Earlier quoted context omitted.

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

But GitHub is keeping this stuff indefinitely. No long expiration, no probability of eventual disk overwriting, nothing. All they're doing is shutting the front door without shutting the side door.

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

#345

Post by oasisaimlessly »

K0balt wrote: post #284
malfist wrote: post #84

Earlier quoted context omitted.

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.

s/meekly/Merkle/g

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

#346

Post by ajross »

beezlewax wrote: post #94
ajross wrote: post #55

Most of this report is just noise. GitHub repos are public. Public stuff can be shared. Public stuff shared previously and then deleted is "still available", but it was shared previously and not really subject to security analysis. The one thing they seem to be able to show is that commits in private branches show up in the parent repository if you know the SHAs. And that seems like a real vulnerability. But AFAICT i…

There's a whole section here about how to brute force the hashs. You don't even need the full hash... just a shortened version using the first few chars.

I'm dubious. Searching for globally unique commit IDs is still a least a million+ request operation. That's easy enough in a cryptographic sense but the attack in question requires banging a web UI, which is 100% for sure going to hit some abuse detector. I really don't think you can do this in practice, and the article certainly doesn't demonstrate it.

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

#348

Post by dttocs »

ahpook wrote: post #158

Hubber here (same username on github.com). We in GitHub's OSPO have been working on an open source GitHub App to address the use case where organizations want to keep a private mirror of an upstream public fork so they can review code and remove IP/secrets/keys that get committed and squash history before any of those changes are made public. Getting a beta release this week, in fact - check it out, I'm curious what…

Looks like a promising tool and workflow to mitigate the risks we are discussing here. If you haven’t already done so, it might help the discussion here if you could highlight how this app deals with the issues outlined. Is the intent of the mirror repo creation that it’s more-or-less equivalent to “git clone —mirror”? I took a quick look at the code, and didn’t see a direct correspondence with “git clone —mirror” when creating the mirror repository.

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

#349

Post by 8organicbits »

dumbo-octopus wrote: post #343
8organicbits wrote: post #329

Earlier quoted context omitted.

What? I don't agree with that. Can you point to an example of a modern database that "supports deletion" but keeps the data around forever? Maybe I've just used different tools than you. Knowing modern data retention concerns I'd be surprised if such a thing existed.

Who said anything about that? We’re talking about side channels and eventual^TM deletion. Given enough time no information will remain anywhere, sure. But that’s not very relevant.

I think we are trying to define the word "delete". You found an archaic definition and are trying to use it in a modern technical setting. You've claimed that modern databases delete without actually removing data but haven't pointed to which systems you are talking about. I'm familiar with tombstoning, either as a "soft-delete" or as part of an eventual deletion process. But I've never seen that called deletion as that would be very confusing.

Pointing to which database you are talking about should clear this up quickly.

I don't think it's reasonable to talk about backups here. A backup is external to the database so it inherently cannot delete it. Similar to how a piece of paper cannot destroy a photograph of the paper, but burning the paper destroys it.

Post reply on HN