3 ms·

I’m very impressed by the level of detail provided in this post mortem, but it leaves me with a few questions. What we know based on this report: - This bug w

I’m very impressed by the level of detail provided in this post mortem, but it leaves me with a few questions. What we know based on this report: - This bug was live in production for at least 3 days. - It was common enough to happen numerous times in the wild. - GitHub says that they identified some specific user sessions that may have been impacted by this bug by analyzing their logs. What we do not know: - How many leaked user sessions were identified in the followup investigation? - Is GitHub confident that they identified all leaked user sessions? - Was there any evidence of malicious use of these sessions? - Did GitHub notify the users whose sessions were leaked? - 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?

dfcowell 6y ago
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?
azernik 6y ago
> - Is GitHub confident that they identified all leaked user sessions? Given that they revoked all current logins, rather than just the affected ones, I assume that they have no way to tell which sessions were affected.
Boltgolt 6y ago
GitHub says there could have been sessions that were leaked but can't be identified now: "While our log analysis, conducted from March 5 through March 8, confirmed that this was a rare issue, it could not rule out the possibility that a session had been incorrectly returned but then never used." Those sessions are now invalidated and apparently never used

dfcowell 6y ago

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?

azernik 6y ago

> - Is GitHub confident that they identified all leaked user sessions? Given that they revoked all current logins, rather than just the affected ones, I assume that they have no way to tell which sessions were affected.

Boltgolt 6y ago

GitHub says there could have been sessions that were leaked but can't be identified now: "While our log analysis, conducted from March 5 through March 8, confirmed that this was a rare issue, it could not rule out the possibility that a session had been incorrectly returned but then never used." Those sessions are now invalidated and apparently never used