2 ms·

Most of that information is available in the initial report linked to in the first paragraph of this blog post: https://github.blog/2021-03-08-github-security-u

Most of that information is available in the initial report linked to in the first paragraph of this blog post: https://github.blog/2021-03-08-github-security-update-a-bug-related-to-handling-of-authenticated-sessions/ https://github.blog/2021-03-08-github-security-update-a-bug-...

maddyboo 6y ago
That provides more information but doesn’t fully answer any of my questions. Things that are still unclear: - GitHub provides an estimate of the prevalence at 0.001%, but doesn’t state how many leaked sessions were actually identified. - Is GitHub confident that they identified all leaked user sessions? This has bearing on my question about notification of users whose sessions were leaked; if they did not identify all leaked sessions, they obviously could not contact those users. - GitHub states that this bug could not be intentionally triggered by a malicious party (why?), but they don’t state whether any of the natural occurrences may have been used maliciously. - How long/for how many requests could these sessions have been valid between their leak and when they were definitively revoked on the 8th? - Is it possible that any private user data was leaked? If so, what data? People with technical understanding can infer most of this information, but I think GitHub should issue some straightforward answers rather than beating around the bush. (Correction to my original comment: the bug was live for a cumulative period of “less than 2 weeks”)
- ac29 6y ago
  > GitHub states that this bug could not be intentionally triggered by a malicious party (why?), Because this bug requires two users making authenticated requests at nearly the same time. An attacker cant force their target to perform actions, especially not in the same small time frame that is likely required (milliseconds? less?). I suppose if the malicious party didnt care what account they got swapped into, and github didnt rate limit their requests, perhaps they could trigger this bug with enough time?

maddyboo 6y ago

That provides more information but doesn’t fully answer any of my questions. Things that are still unclear: - GitHub provides an estimate of the prevalence at 0.001%, but doesn’t state how many leaked sessions were actually identified. - Is GitHub confident that they identified all leaked user sessions? This has bearing on my question about notification of users whose sessions were leaked; if they did not identify all leaked sessions, they obviously could not contact those users. - GitHub states that this bug could not be intentionally triggered by a malicious party (why?), but they don’t state whether any of the natural occurrences may have been used maliciously. - How long/for how many requests could these sessions have been valid between their leak and when they were definitively revoked on the 8th? - Is it possible that any private user data was leaked? If so, what data? People with technical understanding can infer most of this information, but I think GitHub should issue some straightforward answers rather than beating around the bush. (Correction to my original comment: the bug was live for a cumulative period of “less than 2 weeks”)

ac29 6y ago
> GitHub states that this bug could not be intentionally triggered by a malicious party (why?), Because this bug requires two users making authenticated requests at nearly the same time. An attacker cant force their target to perform actions, especially not in the same small time frame that is likely required (milliseconds? less?). I suppose if the malicious party didnt care what account they got swapped into, and github didnt rate limit their requests, perhaps they could trigger this bug with enough time?