6 ms·

Not defending GH here (their position is indefensible imo) but, as the article notes, they document these behaviors clearly and publicly: https://docs.github.c

by 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.
      - berdario 2y ago
        I can see this argument making a bit of sense, but if they documented this 3 years after the issue was reported, they don't have a way to demonstrate that they truly already knew. At the end it boils down to: is Github being honest and fair in answering the bug bounty reports? If you think it is, cool. If you don't, maybe it's not worth playing ball with Github's bug bounty process
        tptacek 2y ago
        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 really bad. The subtext of this thread is that companies should reward any research that turns up surprising or user-hostile behavior in products. It's good to want things. But that is not the point of a security bug bounty.
        cycomanic 2y ago
        I would argue that even if the behaviour was as intended, at least the fact that it was not documented was a bug (and a pretty serious one at that).
        tptacek 2y ago
        Again: you don't generally get bounties for finding "bugs"; you get them exclusively for finding qualified vulnerabilities.
        lolinder 2y ago
        > The incentives you create by paying for every random non-vulnerability are really bad. So much this. It's pretty clear that most people commenting on this thread have never been involved in a bug bounty program on the company's side. Bug bounty programs get a lot of reports, most of which are frankly useless and many of which are cases of intended behavior subjectively perceived as problematic. Sifting through that mess is a lot of work, and if you regularly pay out on unhelpful reports you end up with many more unhelpful reports. This particular case definitely feels like one where the intended behavior is horribly broken, but there are absolutely many cases where "this is intended" is the only valid answer to a report.
    - coldtea 2y ago
      >It's a bug bounty, not a "only if we have time to fix it" bounty It's only a bug if it's not intended
      - ethbr1 2y ago
        Do some companies intend for their platform to feature remote code execution?
        jen20 2y ago
        Remote code execution is literally a feature of GitHub…
        ethbr1 2y ago
        Sandboxed code execution is a bit different than RCE.
        coldtea 2y ago
        Some might very well do. E.g. a company with a service for training hackers and security researchers. In this case the question is moot, as this doesn't involve remote code execution.
        ethbr1 2y ago
        Make a general point, get a general answer. If the criteria for bug is "not intended", and that's solely judged by the company, then broken auth et al. suddenly become part of their product design. If it quacks like a bug, it's a bug.
      - bmitc 2y ago
        I think a lot of developers and companies interpret "that's the way the code or process works" as intentional behavior, which is not always the case.
    - K0balt 2y ago
      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.
      - oasisaimlessly 2y ago
        s/meekly/Merkle/g
        K0balt 2y ago
        lol. Someday autocorrect is going to take over my social media entirely.
      - yencabulator 2y ago
        Don't blame Git for Github decisions. Github chooses to store all "Github forks" in the same repository, and allow accessing things in that repository even when they are not reachable by the refs in the namespace of one "fork". That is purely a Github decision.
        K0balt 2y ago
        They could have split forks off into new repos, but then they wouldn’t be forks, in the repository sense. It was never hard to just copy a repo instead of forking it. The UX just leads people into holding it wrong.
jowea 2y ago
Shouldn't that be on the config page for the repo below the "private" button with a note saying private is not actually private if it's a fork? And ditto for delete?
jiggawatts 2y ago
From the article: "We surveyed a few (literally 3) commonly-forked public repositories from a large AI company and easily found 40 valid API keys from deleted forks." This is how your customers get their entire cloud taken over, because you made a stupid, stupid decision and instead of fixing it when warned (repeatedly!) you instead decide to just blame the customer for not reading page 537 paragraph 3 subsection B about the counter-intuitive security footgun you've left in your product. This is negligence, pure and simple.
- ndriscoll 2y ago
  If you published a key, you must assume someone copied it and that deleting references to it is not sufficient. You must rotate that key now, and should check whether it was used improperly. This is pretty basic incident response. The thing about exposing commits that were only ever in a private repo is pretty indefensible, but not garbage collecting public commits on delete shouldn't matter.
  - jiggawatts 2y ago
    > 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 access checks, so if you click around it'll say something like "you don't have browse access". This looks secure, but attempting access anonymously would have succeeded! I had a customer recently where this happened -- they clicked through every Storage Account to "check" them, convinced themselves they were secure, meanwhile they had database backups with PII accessible to world+dog!
    - cellis 2y ago
      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.

by jonahx 2y ago

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.
    - berdario 2y ago
      I can see this argument making a bit of sense, but if they documented this 3 years after the issue was reported, they don't have a way to demonstrate that they truly already knew. At the end it boils down to: is Github being honest and fair in answering the bug bounty reports? If you think it is, cool. If you don't, maybe it's not worth playing ball with Github's bug bounty process
      - tptacek 2y ago
        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 really bad. The subtext of this thread is that companies should reward any research that turns up surprising or user-hostile behavior in products. It's good to want things. But that is not the point of a security bug bounty.
        cycomanic 2y ago
        I would argue that even if the behaviour was as intended, at least the fact that it was not documented was a bug (and a pretty serious one at that).
        tptacek 2y ago
        Again: you don't generally get bounties for finding "bugs"; you get them exclusively for finding qualified vulnerabilities.
        lolinder 2y ago
        > The incentives you create by paying for every random non-vulnerability are really bad. So much this. It's pretty clear that most people commenting on this thread have never been involved in a bug bounty program on the company's side. Bug bounty programs get a lot of reports, most of which are frankly useless and many of which are cases of intended behavior subjectively perceived as problematic. Sifting through that mess is a lot of work, and if you regularly pay out on unhelpful reports you end up with many more unhelpful reports. This particular case definitely feels like one where the intended behavior is horribly broken, but there are absolutely many cases where "this is intended" is the only valid answer to a report.
  - coldtea 2y ago
    >It's a bug bounty, not a "only if we have time to fix it" bounty It's only a bug if it's not intended
    - ethbr1 2y ago
      Do some companies intend for their platform to feature remote code execution?
      - jen20 2y ago
        Remote code execution is literally a feature of GitHub…
        ethbr1 2y ago
        Sandboxed code execution is a bit different than RCE.
      - coldtea 2y ago
        Some might very well do. E.g. a company with a service for training hackers and security researchers. In this case the question is moot, as this doesn't involve remote code execution.
        ethbr1 2y ago
        Make a general point, get a general answer. If the criteria for bug is "not intended", and that's solely judged by the company, then broken auth et al. suddenly become part of their product design. If it quacks like a bug, it's a bug.
    - bmitc 2y ago
      I think a lot of developers and companies interpret "that's the way the code or process works" as intentional behavior, which is not always the case.
  - K0balt 2y ago
    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.
    - oasisaimlessly 2y ago
      s/meekly/Merkle/g
      - K0balt 2y ago
        lol. Someday autocorrect is going to take over my social media entirely.
    - yencabulator 2y ago
      Don't blame Git for Github decisions. Github chooses to store all "Github forks" in the same repository, and allow accessing things in that repository even when they are not reachable by the refs in the namespace of one "fork". That is purely a Github decision.
      - K0balt 2y ago
        They could have split forks off into new repos, but then they wouldn’t be forks, in the repository sense. It was never hard to just copy a repo instead of forking it. The UX just leads people into holding it wrong.

jowea 2y ago

Shouldn't that be on the config page for the repo below the "private" button with a note saying private is not actually private if it's a fork? And ditto for delete?

jiggawatts 2y ago

From the article: "We surveyed a few (literally 3) commonly-forked public repositories from a large AI company and easily found 40 valid API keys from deleted forks." This is how your customers get their entire cloud taken over, because you made a stupid, stupid decision and instead of fixing it when warned (repeatedly!) you instead decide to just blame the customer for not reading page 537 paragraph 3 subsection B about the counter-intuitive security footgun you've left in your product. This is negligence, pure and simple.

ndriscoll 2y ago
If you published a key, you must assume someone copied it and that deleting references to it is not sufficient. You must rotate that key now, and should check whether it was used improperly. This is pretty basic incident response. The thing about exposing commits that were only ever in a private repo is pretty indefensible, but not garbage collecting public commits on delete shouldn't matter.
- jiggawatts 2y ago
  > 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 access checks, so if you click around it'll say something like "you don't have browse access". This looks secure, but attempting access anonymously would have succeeded! I had a customer recently where this happened -- they clicked through every Storage Account to "check" them, convinced themselves they were secure, meanwhile they had database backups with PII accessible to world+dog!
  - cellis 2y ago
    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.