TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

GitHub waited 3 months to notify about potential compromise

217 点作者 zwass将近 3 年前
It seems GitHub became aware of the issue around March 2 (or before, since the fix was released on March 2), and waited until June 16 to disclose the problem.<p>See full text below:<p>Hi zwass,<p>We&#x27;re writing to let you know that between 2022-02-25 18:28 UTC and 2022-03-02 20:47 UTC, due to a bug, GitHub Apps were able to generate new scoped installation tokens with elevated permissions. You are an owner of an organization on GitHub with GitHub Apps installed that generated at least one new token during this time period. While we do not have evidence that this bug was maliciously exploited, with our available data, we are not able to determine if a token was generated with elevated permissions.<p>User privacy and security are essential for maintaining trust, and we want to remain as transparent as possible about events like these. GitHub itself did not experience a compromise or data breach that either created or resulted from this event. Read on for more information.<p>* What happened? *<p>GitHub learned via a customer support ticket that GitHub Apps were able to generate scoped installation tokens with elevated permissions. Each of these tokens are valid for up to 1 hour.<p>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.<p>GitHub Apps generate scoped installation tokens based on the scopes and permissions granted when the GitHub App is installed into a user account or organization. For example, if a GitHub App requests and is granted read permission to issues during installation, the scoped installation token the App generates to function would have `issues:read` permission.<p>This bug would potentially allow the above installation to generate a token with `issues:write`, an elevation of permission from the granted `issues:read` permission. The bug did not allow a GitHub App to generate a token with additional scopes that were not already granted, such as `discussions:read` in the above example. The bug did not allow a GitHub App to access any repositories that the App did not already have access to.<p>In order to exploit this bug, the GitHub App author would need to modify their app&#x27;s code to request elevated permissions on generated tokens.<p>* What information was involved? *<p>The following GitHub Apps generated scoped installation tokens during the bug window for your organization(s). We are not able to determine if a token was generated with elevated permissions.<p>Organization: GitHub Apps &lt;redacted&gt;<p>* What GitHub is doing *<p>GitHub immediately began working to fix the bug and started an investigation into the potential impact. However due to the scale and complexity of GitHub Apps and their short-lived tokens, we were unable to determine whether this bug was ever exploited.<p>We are notifying all organization and user account owners that had GitHub Apps installed and had a scoped installation token generated during the bug window so that they can stay informed and perform their own audit of their installed GitHub Apps.<p>As a followup to this investigation, GitHub is looking at ways to improve our logging to enable more in-depth analysis on scoped token generation and GitHub App permissions in the future.<p>* What was the potential impact? *<p>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&#x27;s situation will be unique.<p>* What you can do *<p>While we have updated our systems to resolve this bug and no action is required on your end, we do recommend you review your installed GitHub Apps. You can use the following guidance for assessing GitHub Apps, their permissions, and their access to your private organization repositories:<p>https:&#x2F;&#x2F;docs.github.com&#x2F;en&#x2F;organizations&#x2F;keeping-your-organization-secure

10 条评论

cypherg将近 3 年前
They explained it themselves - there&#x27;s no evidence of abuse&#x2F;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.
评论 #31770535 未加载
评论 #31770335 未加载
评论 #31771341 未加载
评论 #31774269 未加载
评论 #31773510 未加载
评论 #31775189 未加载
_7gt4将近 3 年前
My 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&#x27;t care. And they didn&#x27;t bother to even tell me that they didn&#x27;t care.<p>It&#x27;s a very edge-case issue in Enterprise SSO, so I wasn&#x27;t really able to generate any blowback with disclosure either. But if you find an org with just the right setup it blows a huge hole into the SSO product, to the point of making it useless.<p>There also seems to be an asymmetry between the core product and everything else. GitHub Enterprise has issues that aren&#x27;t even considered UX issues (i.e. notifications showing &quot;3 of 0&quot; notifications if no SAML session exists) that&#x27;d warrant bounties if they were in the core product.<p>[1]: <a href="https:&#x2F;&#x2F;notes.acuteaura.net&#x2F;posts&#x2F;github-enterprise-security&#x2F;" rel="nofollow">https:&#x2F;&#x2F;notes.acuteaura.net&#x2F;posts&#x2F;github-enterprise-security...</a>
评论 #31773127 未加载
评论 #31770042 未加载
lambada将近 3 年前
Given it existed for 5 days and you’re only now finding out about it, it sounds to me like it was perhaps a bug that was fixed without realising the full impact of it, or perhaps without realising it made it to production; and only an audit that happened later caught it.<p>Not ideal by any means. I’d be curious to know if my theory is correct or not.
评论 #31770102 未加载
bearjaws将近 3 年前
I am really curious how SecOps works at GitHub.<p>Why not after remediation inform users of the flaw and potential impact. Then follow up with detailed impact.<p>Instead we get this 3 months later all they can say is &quot;Some of your apps refreshed their tokens during a 5 day period&quot; which is not news...<p>This is also the second time this year there has been significant delay in communication. Granted those involved other third parties so who knows where the delay lived.
评论 #31769816 未加载
评论 #31769796 未加载
smarx007将近 3 年前
I just got it as well and don&#x27;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?
评论 #31770295 未加载
评论 #31770255 未加载
评论 #31773290 未加载
njibhu将近 3 年前
Can somebody tell me if I&#x27;m wrong on my take but this bug&#x2F;issue means:<p>- a github app which had read permission on issues could elevate its permission to write<p>- a github app which had read permissions to discussions could elevate its permissions to write.<p>So far if the org&#x2F;user would have been compromise they would have seen with issues or conversations containing content from the app.<p>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&#x2F;org ?
评论 #31771332 未加载
kenbolton将近 3 年前
In the same minute that I learned GitHub had been acquired by Microsoft, I cancelled my pro subscription and began moving my critical repositories elsewhere. I&#x27;m old enough to remember the MS that tried to choke the life out of GNU&#x2F;Linux and spread FUD about all FLOSS, the one that engaged in anti-competetive behavior during the &quot;Browser Wars&quot;. I&#x27;m not suggesting that this blunder of a delay is related to the Microsoft acquisition, but the abusive &quot;Look at me, I&#x27;m changing&quot; spiel never cut any mustard with me.<p>Vote at the ballot box and with your dollars. Do not reward executives, lawyers, or engineers who dissemble or obfuscate.
评论 #31773242 未加载
评论 #31773029 未加载
评论 #31773327 未加载
评论 #31772987 未加载
throwaway78246将近 3 年前
It was also my experience that it takes GitHub several months to fix issues and inform compromised users.
ghyty将近 3 年前
Does anyone know what type of audit logs or actions we need to look for?
darthrupert将近 3 年前
Yep. As I mentioned elsewhere on the pyright&#x2F;pylance issue: Microsoft are scumbags.