7 ms·

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 s

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 not? To me it looks like similar to what happens with Google Play/Apple store to decide whether or not an app can be uploaded/distributed through them. Edit: I popped this up because to me is absolutely miserable from a big company to just say: "Thanks, but we were aware of this".

deleted 2y ago
[deleted]
kayodelycaon 2y ago
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 us. We aren't large enough to get the attention of anyone competent.
- ipaddr 2y ago
  For both sides it turns into a net negative. Better to keep your bugs and use them when needed or sell them to others to use if possible. Lets get back to what we had before when multiple people can find the same bug and exploit if needed. Now we have the one person who finds the bug it gets patched and they don't get paid.
- giobox 2y ago
  > 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 the behaviour flies so against the grain, just publishing it in a help doc is not enough I'd argue. The linked article makes the exact same argument: > "The average user views the separation of private and public repositories as a security boundary, and understandably believes that any data located in a private repository cannot be accessed by public users. Unfortunately, as we documented above, that is not always true. Whatsmore, the act of deletion implies the destruction of data. As we saw above, deleting a repository or fork does not mean your commit data is actually deleted."
  - tptacek 2y ago
    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 is a best-practices response to commiting hazmat to a repository: revoke the hazmat, so that its disclosure no long matters. You have to do this anyways. If you can't, you should be in contact with Github directly to remove it.
    - Cpoll 2y ago
      Is "git" relevant here? Forking isn't a git concept, and none of this behaviour has much to do with git; it's all GitHub. Also, you can revoke an API key, but you can't revoke a company-proprietary algorithm that you implemented into a fork of a public project.
      - tptacek 2y ago
        Like I said: if you can't revoke the thing you committed, you need to get in touch with Github and have them remove it. That's a thing they do.
        Cpoll 2y ago
        Sure, but the whole point of the article is that people don't know their "private" forks aren't private. You can't get in touch with GitHub if you've never had any indication that anything's wrong. The solution for that is better UX.
      - schrodinger 2y ago
        aside: I think it's questionable to say that forking isn't a git concept. it's just a branch on a different upstream. Those two upstreams could simply be two different folders on your machine, or shared server. I supposed the branding and UI for it could be a counter argument, but then again Github allows regular branch creation / committing / merging in their UI. Their main value add (not downplaying it—it's huge) on top of git (besides ancillary things like CI / linters) is the ability to comment on a branch's diff, i.e. a PR Review.
- oxfordmale 2y ago
  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
  - account42 2y ago
    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.
    - oxfordmale 2y ago
      This is about access to private repos, not public ones: "Anyone can access deleted and private repository data on GitHub"
jonahx 2y ago
Not defending GH here (their position is indefensible imo) but, as the article notes, they document these behaviors clearly and publicly: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/what-happens-to-forks-when-a-repository-is-deleted-or-changes-visibility https://docs.github.com/en/pull-requests/collaborating-with-... I don't think they're being underhanded exactly... they're just making a terrible decision. Quoting from the article: > The average user views the separation of private and public repositories as a security boundary, and understandably believes that any data located in a private repository cannot be accessed by public users. Unfortunately, as we documented above, that is not always true. Whatsmore, the act of deletion implies the destruction of data. As we saw above, deleting a repository or fork does not mean your commit data is actually deleted.
- andersa 2y ago
  Based on some (admittedly not very thorough) search, this documentation was posted in 2021, three years after my report.
  - YetAnotherNick 2y ago
    But that would still means they didn't intend to fix it, hence not giving bounty is fair.
    - malfist 2y ago
      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
      - madeofpalk 2y ago
        The point of a bug bounty is for companies to find new security problems. If the (class of) problem is already known, it’s not worth rewarding.
93po 2y ago
companies vary wildly in their honesty and cooperation with bug bounties and develop reputations as a result. if they have a shit reputation, people stop doing free work for them and instead focus on more honest companies
- account42 2y ago
  Not all free work is wanted. Discouraging frivolous reports is exactly what is being accomplished by not paying for them.
  - 93po 2y ago
    there are endless examples of reports that, by the judgement of the community, are entirely valid and unknown security concerns and fit within the guidelines of a company's bug bounty program, and do not ever result in payment
deleted 2y ago
[deleted]
andersa 2y ago
I didn't find anything mentioning it online at the time. But there wasn't much time and dedication involved either, to be fair. I discovered it completely on accident when I combined a commit hash from my local client with the wrong repository url and it ended up working.
cyrnel 2y ago
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.
- aaron695 2y ago
  [dead]
- TheDong 2y ago
  Security disclosures are like telling someone they have a spot on their face. It's not always welcome, and there's no obligation on anyone to do so, nor anyone to return the favor. In this case, the spot turned out to be a freckle, which everyone involved already knew was a freckle (since it was documented), and if anyone owes anyone anything, it's the researcher that owes github for wasting their time.
- account42 2y ago
  > 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.
nyrikki 2y ago
For moral reasons, historically I never wrote POCs or threatened disclosure. For companies like Microsoft, which a CSRB audit showed that their security culture 'inadequate', the risk of disclosure with a POC is about the only tool we have to enforce their side of the Shared Responsibility Model. Even the largest IT spender in the world, the US government has moved more from the carrot to the stick model. If they have to do it so do we. Unfortunately as publishing a 'bad practices' list by us doesn't invoke the risk of EULA busting gross negligence claims, responsible disclosure is one of the few tools we have.
tptacek 2y ago
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 weather. People game the hell out of them. If you ack and fix sev:info bugs, people submit lots more sev:info bugs, and now your security program has been reoriented around the dumbest bugs --- the opposite of what you want a bounty program to do.
- raesene9 2y ago
  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, meaning that anyone with access to one container automatically got cluster-admin rights. That pretty clearly seems like not a good security choice, but probably hard to fix if they were relying on that behaviour (which I'm guessing they were). Their response was to say it was a "best practice" behaviour (no bounty applicable) and that they'd look to fix and asked me not to publicly mention it. Then they deprecated the entire product 6 months later :D That's one example but I've seen similar behaviour multiple times for things that are more architecture choices than direct bugs, which makes me think reporting such things isn't always welcome by the program owners.
  - tptacek 2y ago
    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.
hluska 2y ago
The issue had been reported at least twice and was clearly documented. GitHub knew about this and had known for years. Their replies to the two notifications were even very similar. GitHub clearly knew. Would you prefer that a vendor lie?
account42 2y ago
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.
- andersa 2y ago
  I wasn't really expecting a bounty, more so hoping they'd fix the issue. For example, to this day I keep having to tell people to never fork the Unreal Engine repository, instead making a manual copy, just in case. This causes lots of problems for repositories that are private with the expectation that companies will make private forks with their own private changes. Someone once pushed a bunch of console SDKs (under strict NDA) to a private fork without knowing this. Now that code is just there, if you can guess the commit hash, forever. Literally nothing can be done to remove it. Great.
- barco 2y ago
  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.
whoknew1122 2y ago
It's not just GitHub and it's not just because they don't want to pay bug hunters. In my career, I have escalated multiple bugs to my employer(s) in which the response was 'working as intended'. And they wouldn't have to pay me another cent if they acknowledged the issue. In my experience, there was two reasons for this behavior: 1. They don't want to spin dev cycles on something that isn't directly related to revenue (e.g. security) 2. Developers don't have the same mindset as someone who's whole job is security. So they think something is fine when it's really not.

deleted 2y ago

[deleted]

kayodelycaon 2y ago

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 us. We aren't large enough to get the attention of anyone competent.

ipaddr 2y ago
For both sides it turns into a net negative. Better to keep your bugs and use them when needed or sell them to others to use if possible. Lets get back to what we had before when multiple people can find the same bug and exploit if needed. Now we have the one person who finds the bug it gets patched and they don't get paid.
giobox 2y ago
> 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 the behaviour flies so against the grain, just publishing it in a help doc is not enough I'd argue. The linked article makes the exact same argument: > "The average user views the separation of private and public repositories as a security boundary, and understandably believes that any data located in a private repository cannot be accessed by public users. Unfortunately, as we documented above, that is not always true. Whatsmore, the act of deletion implies the destruction of data. As we saw above, deleting a repository or fork does not mean your commit data is actually deleted."
- tptacek 2y ago
  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 is a best-practices response to commiting hazmat to a repository: revoke the hazmat, so that its disclosure no long matters. You have to do this anyways. If you can't, you should be in contact with Github directly to remove it.
  - Cpoll 2y ago
    Is "git" relevant here? Forking isn't a git concept, and none of this behaviour has much to do with git; it's all GitHub. Also, you can revoke an API key, but you can't revoke a company-proprietary algorithm that you implemented into a fork of a public project.
    - tptacek 2y ago
      Like I said: if you can't revoke the thing you committed, you need to get in touch with Github and have them remove it. That's a thing they do.
      - Cpoll 2y ago
        Sure, but the whole point of the article is that people don't know their "private" forks aren't private. You can't get in touch with GitHub if you've never had any indication that anything's wrong. The solution for that is better UX.
    - schrodinger 2y ago
      aside: I think it's questionable to say that forking isn't a git concept. it's just a branch on a different upstream. Those two upstreams could simply be two different folders on your machine, or shared server. I supposed the branding and UI for it could be a counter argument, but then again Github allows regular branch creation / committing / merging in their UI. Their main value add (not downplaying it—it's huge) on top of git (besides ancillary things like CI / linters) is the ability to comment on a branch's diff, i.e. a PR Review.
oxfordmale 2y ago
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
- account42 2y ago
  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.
  - oxfordmale 2y ago
    This is about access to private repos, not public ones: "Anyone can access deleted and private repository data on GitHub"

jonahx 2y ago

Not defending GH here (their position is indefensible imo) but, as the article notes, they document these behaviors clearly and publicly: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/what-happens-to-forks-when-a-repository-is-deleted-or-changes-visibility https://docs.github.com/en/pull-requests/collaborating-with-... I don't think they're being underhanded exactly... they're just making a terrible decision. Quoting from the article: > The average user views the separation of private and public repositories as a security boundary, and understandably believes that any data located in a private repository cannot be accessed by public users. Unfortunately, as we documented above, that is not always true. Whatsmore, the act of deletion implies the destruction of data. As we saw above, deleting a repository or fork does not mean your commit data is actually deleted.

andersa 2y ago
Based on some (admittedly not very thorough) search, this documentation was posted in 2021, three years after my report.
- YetAnotherNick 2y ago
  But that would still means they didn't intend to fix it, hence not giving bounty is fair.
  - malfist 2y ago
    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
    - madeofpalk 2y ago
      The point of a bug bounty is for companies to find new security problems. If the (class of) problem is already known, it’s not worth rewarding.

93po 2y ago

companies vary wildly in their honesty and cooperation with bug bounties and develop reputations as a result. if they have a shit reputation, people stop doing free work for them and instead focus on more honest companies

account42 2y ago
Not all free work is wanted. Discouraging frivolous reports is exactly what is being accomplished by not paying for them.
- 93po 2y ago
  there are endless examples of reports that, by the judgement of the community, are entirely valid and unknown security concerns and fit within the guidelines of a company's bug bounty program, and do not ever result in payment

deleted 2y ago

[deleted]

andersa 2y ago

I didn't find anything mentioning it online at the time. But there wasn't much time and dedication involved either, to be fair. I discovered it completely on accident when I combined a commit hash from my local client with the wrong repository url and it ended up working.

cyrnel 2y ago

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.

aaron695 2y ago
[dead]
TheDong 2y ago
Security disclosures are like telling someone they have a spot on their face. It's not always welcome, and there's no obligation on anyone to do so, nor anyone to return the favor. In this case, the spot turned out to be a freckle, which everyone involved already knew was a freckle (since it was documented), and if anyone owes anyone anything, it's the researcher that owes github for wasting their time.
account42 2y ago
> 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.

nyrikki 2y ago

For moral reasons, historically I never wrote POCs or threatened disclosure. For companies like Microsoft, which a CSRB audit showed that their security culture 'inadequate', the risk of disclosure with a POC is about the only tool we have to enforce their side of the Shared Responsibility Model. Even the largest IT spender in the world, the US government has moved more from the carrot to the stick model. If they have to do it so do we. Unfortunately as publishing a 'bad practices' list by us doesn't invoke the risk of EULA busting gross negligence claims, responsible disclosure is one of the few tools we have.

tptacek 2y ago

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 weather. People game the hell out of them. If you ack and fix sev:info bugs, people submit lots more sev:info bugs, and now your security program has been reoriented around the dumbest bugs --- the opposite of what you want a bounty program to do.

raesene9 2y ago
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, meaning that anyone with access to one container automatically got cluster-admin rights. That pretty clearly seems like not a good security choice, but probably hard to fix if they were relying on that behaviour (which I'm guessing they were). Their response was to say it was a "best practice" behaviour (no bounty applicable) and that they'd look to fix and asked me not to publicly mention it. Then they deprecated the entire product 6 months later :D That's one example but I've seen similar behaviour multiple times for things that are more architecture choices than direct bugs, which makes me think reporting such things isn't always welcome by the program owners.
- tptacek 2y ago
  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.

hluska 2y ago

The issue had been reported at least twice and was clearly documented. GitHub knew about this and had known for years. Their replies to the two notifications were even very similar. GitHub clearly knew. Would you prefer that a vendor lie?

account42 2y ago

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.

andersa 2y ago
I wasn't really expecting a bounty, more so hoping they'd fix the issue. For example, to this day I keep having to tell people to never fork the Unreal Engine repository, instead making a manual copy, just in case. This causes lots of problems for repositories that are private with the expectation that companies will make private forks with their own private changes. Someone once pushed a bunch of console SDKs (under strict NDA) to a private fork without knowing this. Now that code is just there, if you can guess the commit hash, forever. Literally nothing can be done to remove it. Great.
barco 2y ago
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.

whoknew1122 2y ago

It's not just GitHub and it's not just because they don't want to pay bug hunters. In my career, I have escalated multiple bugs to my employer(s) in which the response was 'working as intended'. And they wouldn't have to pay me another cent if they acknowledged the issue. In my experience, there was two reasons for this behavior: 1. They don't want to spin dev cycles on something that isn't directly related to revenue (e.g. security) 2. Developers don't have the same mindset as someone who's whole job is security. So they think something is fine when it's really not.