They explained it themselves - there's no evidence of abuse/exploitation.
They literally have no legal requirement to even tell you as much as they did.
You should be commending them for filling you in at all.
GitHub waited 3 months to notify about potential compromise
11–20 of 83 posts
Re: GitHub waited 3 months to notify about potential compromise
#12I just got it as well and don't understand what I can do. Can I somehow force all generated tokens to be revoked and get apps to generate new tokens to be on the safe side? Or, rather, is there a way to do this without uninstalling the apps and installing them again?
Aren't these very time limited anyways (hours vs days)? So once they fix the bug and wait an hour the old tokens are gone anyways?
Re: GitHub waited 3 months to notify about potential compromise
#13My recent experience with GitHub regarding a security issue was not very positive either.[1] It turned out, unlike two vendors I notified that were affected, they just didn't care. And they didn't bother to even tell me that they didn't care. It's a very edge-case issue in Enterprise SSO, so I wasn't really able to generate any blowback with disclosure either. But if you find an org with just the right setup it blows…
My guess is that GitHub ignores issues so they don't have to pay out bug bounties.
I find these takes so silly. Bug bunties are a rounding error in the companies budgets, even if they paid out much more freely. There are many I think much more obvious reasons orgs are slow on issues - everything from figuring what is an issue, trying to chase down impacts and more.
Re: GitHub waited 3 months to notify about potential compromise
#14I just got it as well and don't understand what I can do. Can I somehow force all generated tokens to be revoked and get apps to generate new tokens to be on the safe side? Or, rather, is there a way to do this without uninstalling the apps and installing them again?
>Each of these tokens are valid for up to 1 hour.
> GitHub quickly fixed the issue and established that this bug was recently introduced, existing for approximately 5 days between 2022-02-25 18:28 UTC and 2022-03-02 20:47 UTC.
It doesn't sound like there is anything you can or need to do with respect to these tokens (whether they were used to take action with elevated permissions is a different thing, but it doesn't sound like that was the case either)
Re: GitHub waited 3 months to notify about potential compromise
#15I just got it as well and don't understand what I can do. Can I somehow force all generated tokens to be revoked and get apps to generate new tokens to be on the safe side? Or, rather, is there a way to do this without uninstalling the apps and installing them again?
Aren't these very time limited anyways (hours vs days)? So once they fix the bug and wait an hour the old tokens are gone anyways?
Per the email:
> Each of these tokens are valid for up to 1 hour.
So these tokens would've been expired for 3 months now, according to when the fix was deployed.
Re: GitHub waited 3 months to notify about potential compromise
#16They explained it themselves - there's no evidence of abuse/exploitation. They literally have no legal requirement to even tell you as much as they did. You should be commending them for filling you in at all.
> ... we were unable to determine whether this bug was ever exploited.
> ...
> Due to the variety of GitHub Apps, their possible scopes, and the repositories they may have been given access to, we are unable to advise on any potential impacts as each customer's situation will be unique.
Absence of evidence is not evidence of absence.
Re: GitHub waited 3 months to notify about potential compromise
#17They explained it themselves - there's no evidence of abuse/exploitation. They literally have no legal requirement to even tell you as much as they did. You should be commending them for filling you in at all.
> ... we were unable to determine whether this bug was ever exploited. > ... > Due to the variety of GitHub Apps, their possible scopes, and the repositories they may have been given access to, we are unable to advise on any potential impacts as each customer's situation will be unique. Absence of evidence is not evidence of absence.
[deleted]
Re: GitHub waited 3 months to notify about potential compromise
#18They explained it themselves - there's no evidence of abuse/exploitation. They literally have no legal requirement to even tell you as much as they did. You should be commending them for filling you in at all.
> They literally have no legal requirement to even tell you as much as they did.
Is ‘fulfilling legal requirements’ all you look for in a business relationship?
A restaurant has no legal requirement to make this food tasty but it’s what I’m looking for when choosing where to go.
Re: GitHub waited 3 months to notify about potential compromise
#19Can somebody tell me if I'm wrong on my take but this bug/issue means:
- a github app which had read permission on issues could elevate its permission to write
- a github app which had read permissions to discussions could elevate its permissions to write.
So far if the org/user would have been compromise they would have seen with issues or conversations containing content from the app.
Since these are only examples, I can imagine the case with major impact would be a contents:read elevate to content write. But again with commit signing, this would also be caught by the user. What did I miss where the impact would have not been visible to the end user/org ?
Re: GitHub waited 3 months to notify about potential compromise
#20They explained it themselves - there's no evidence of abuse/exploitation. They literally have no legal requirement to even tell you as much as they did. You should be commending them for filling you in at all.
> They literally have no legal requirement to even tell you as much as they did. Is ‘fulfilling legal requirements’ all you look for in a business relationship? A restaurant has no legal requirement to make this food tasty but it’s what I’m looking for when choosing where to go.
Since almost every popular tech company is a quasi monopoly, they use this "fulfilling legal requirements" strategy to abuse the market providing overpriced services with bad quality.
Unfortunately, people got used to this practice and gladly accept when such companies fulfill all their legal obligations, even when this hurt them or their business.