Follow

OMG, am dying!!!

Someone used the bug GitHub refused to fix, that allows you to add a commit to a repo you don’t control... to upload YouTube-dl to the DMCA request repo on GitHub.

github.com/github/dmca/tree/41

@thegibson

ROFL

*immediately mirrors to git.aardwolf.social*

@thegibson do you have a link to any info on the bug itself? Very curious what's that about.

@rysiek I do not, there is a user on hellbird that did this referencing it. I have no knowledge of the reported vuln.

@rysiek @thegibson Has to do with how GH handles different forks of a repo. Seems they're just branches in the parent repo rather than their own intendant repo. (namespaced by username or something) Makes total sense.

The "bug" is that you can fork someone else's repo, push a commit to your fork, and view the commit on the parent repo, (or anyone else's fork of that repo for that matter) hence the commit hash in the URL. If you click on the commit, you'll see a note that the commit you're viewing isn't part of any branch in that repository.

@mr64bit @rysiek

Looks like they consider it more of a feature than a bug... oopsies!

@thegibson @mr64bit this means the fix would require rather deep changes to the underlying infrastructure. Hence hard. Hence unlikely.

@thegibson @mr64bit and best part of it is: it is not even a ToS violation!

Holy cow, the possibilities.

@rysiek @mr64bit And they are obstinate about leaving it as a workflow element...

oh dear.

@bamfic @rysiek @thegibson Bet it already exists somewhere on github. Wouldn't be the strangest thing I've found on there either.
Take this for example.
https://github.com/thamada/lawn

@rysiek @mr64bit

SPECTER AND MELTDOWN AND GIT-COMMIT CANNOT BE PATCHED

@rysiek @thegibson I don't know, you should just be able to follow child commits until you find all the branch HEADs, then only display the page if the commit is part of one of the branches in that user's repo. Linking to files at a certain commit happens all the time on Github, and that's far more complex, cause it's got to walk the tree back to when the file was created, right?

@mr64bit @thegibson fair. I guess we will see how hard it is to do it soon.

@mr64bit @rysiek @thegibson I guess this is also why everyone's forks go away if you destroy your repo.

@thegibson probably not the right thread to make that note but it occurs to me that #Hacktoberfest is still a thing.

@rysiek Perhaps I misread your intent... but perhaps not. :)

@thegibson This right here is the "fuck you" I was waiting for. A two for one fuck you, no less.

@TheGibson How to checkout:
git clone github.com/github/dmca/
git fetch origin 416da574ec0df3388f652e44f7fe71b1e3a4701f
git checkout 416da574ec0df3388f652e44f7fe71b1e3a4701f

@bamfic so does everyone else, I haven’t had a post boosted and faved like this in some time.

@thegibson which bug report was it they refused to fix that was used here?

@thegibson This is the funniest thing I've seen all week, and it's still monday!

@thegibson
The fact that such a bug was even allowed to persist highlights why #DeleteGitHub is so important.

Holy hell!

@thegibson
It's a cute trick, but this is not a " bug that GitHub refuses to fix" -- it's how git forks work fundamentally. The alternative is to either deep-copy each repo on fork, or to calculate reachability on each direct object request. Both options extremely expensive.

@monsieuricon @thegibson Calculating reachability is one of the modes of git itself.

Having two different repos share an object store is a github decision.

@clacke a conscious decision is not a "bug, that GitHub refuses to fix" though. All public forks share objects. Private forks don't.

@thegibson

@monsieuricon @clacke

It is a security vulnerability. Whether or not they decide to fix it.

@thegibson how is it a security vulnerability? The object isn't part of the repo, it's just accessible through an unrelated repo via shared objects. It's confusing, but unless someone copy-pastes from the web interface, it's benign.

@clacke

@monsieuricon @clacke

Because it creates a culture of weak authorization in ever project, and lets people do things like upload Youtube-dl to a repo that isn't theirs?

I mean ultimately we can record it as a feature if you want, but what if someone decided to just start pumping multiple TB of randomized data into a downstream project?

At the very least his reduces github's ability to meet compliance standards, and is a problem for them....

But as we can see right here, it can be very effectively, and practically abused.

I mean I see models of failure due to this lack of downstream control for the maintainer of the attacked repo.

@thegibson

but this hasn't "uploaded Youtube-dl to a repo that isn't theirs," though. If you clone the DMCA repo, you won't find these objects there, because they aren't part of it. This merely allows someone to view objects via arbitrary web paths. It's confusing -- and can be amusing (github.com/torvalds/linux/blob), but it's not really different than using debugfs to show arbitrary inode contents regardless of where you are in the actual FS tree.

@clacke

@thegibson

I agree that it would be best if objects not belonging to that specific tree would return a 404, but until git learns to do this cheaply, this is not feasible for projects like github (or git.kernel.org, for that matter) to do, as this would invite a way to do a very simple and efficient DoS via requesting a bunch of arbitrary object paths and forcing the server end to run a bunch of expensive reachability calculations.

@clacke

Sign in to participate in the conversation
hackers.town

A bunch of technomancers in the fediverse. Keep it fairly clean please. This arcology is for all who wash up upon it's digital shore.