Live data from Hacker News

GitHub waited 3 months to notify about potential compromise

news.ycombinator.com

21–30 of 83 posts

Re: GitHub waited 3 months to notify about potential compromise

#21
post #20

Earlier quoted context omitted.

> 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.

How much is GitHub overpricing their bad quality services?

Re: GitHub waited 3 months to notify about potential compromise

#22
post #11

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.

> ... 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.

That's true, but feels like these are always judgment calls. We can always armchair quarterback their judgment calls, but none of us have the full info. At least GH is sharing this info, which is a good call for trust building IMO.

Re: GitHub waited 3 months to notify about potential compromise

#23
post #19

Can 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,…

contents:read to contents:write is a big deal! Just to pick out a random widely used project, nodejs [1] has a number of unsigned commits to the main branch. Their commits could have been tampered with during this timeframe.

What about release artifacts?

[1]: https://github.com/nodejs/node/commits/main

Re: GitHub waited 3 months to notify about potential compromise

#24
post #11

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.

I would be commending them if this notice went out March 3 after they had remediated the problem and were aware that they had no logs to determine whether there was abuse.

Re: GitHub waited 3 months to notify about potential compromise

#25
post #23
post #19

Can 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,…

contents:read to contents:write is a big deal! Just to pick out a random widely used project, nodejs [1] has a number of unsigned commits to the main branch. Their commits could have been tampered with during this timeframe. What about release artifacts? [1]: https://github.com/nodejs/node/commits/main

I guess I can see it, but branch protection rules and pull requests reviews would also prevent that to happen in my opinion

(also ability to do it with content:write is just speculation from my side, they don't make it clear if it is possible, that would need to be confirmed by github)

Re: GitHub waited 3 months to notify about potential compromise

#26
post #22

Earlier quoted context omitted.

> ... 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.

That's true, but feels like these are always judgment calls. We can always armchair quarterback their judgment calls, but none of us have the full info. At least GH is sharing this info, which is a good call for trust building IMO.

That's not fully Github's choice to make. They made a judgement call based on seemingly incomplete evidence, and have different incentives that everyone else.

Repository owners may well have a different level of acceptable risk or legal obligations over the integrity of their source code. For example, if I was maintaining security software or a popular package, it would be entirely appropriate to stop everything and look for abuse. Waiting three months makes that harder.

I'm not sure that's trust building.

Re: GitHub waited 3 months to notify about potential compromise

#27

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

It seems like the appropriate thing to do would be to inform anyone who had tokens created during the affected time period, so they could assess if any of the permissions led to undesired changes. Instead of GitHub saying “we don’t have hard proof of anything bad happening” and waiting 3 months, just give the customer the time of relevant token creations.

Re: GitHub waited 3 months to notify about potential compromise

#29
post #20

Earlier quoted context omitted.

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.

How much is GitHub overpricing their bad quality services?

With some price transparency into what companies actually pay for services such as GitHub, maybe we can find out.

Re: GitHub waited 3 months to notify about potential compromise

#30
post #11

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.

> 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.

As someone who works in the reputation management sector, fulling legal requirements is crucial in establishing a presence in key markets. However, oversharing of internal information that's not required by legal requirements can lead to unnecessary reputation damage, which would lead to a decrease in value for key stakeholders.

I think many engineers often overlook the business implication of disclosing security issues, as it would impact multiple business units as well as the board's stance on security, resource allocation, and potentially the stock price too.

>A restaurant has no legal requirement to make this food tasty Food is a core deliverable for a restaurant, whereas information on a potential breach is not for a SaaS service unless it is legally required.

Post reply on HN