[dead]
1-Click GitHub Token Stealing via a VSCode Bug
81–90 of 116 posts
Re: 1-Click GitHub Token Stealing via a VSCode Bug
#82[dead]
Re: 1-Click GitHub Token Stealing via a VSCode Bug
#83> the last time I interacted with MSRC regarding reporting a VSCode bug, it was a horrible experience where they silently fixed the bug Classic MSRC. It has figured out that researchers will report for free regardless. Why change?
MSRC doesn’t fix bugs. I don’t know the specifics of this case, but I’ve managed bug bounty programs in the past through Bountysource and HackerOne. One thing that occasionally happens is that a report makes its way to the development team before the security team has fully assessed it, in this case MSRC. At that point, a developer may decide to quietly fix the issue. Sometimes that’s driven by a concern, rational or…
Your post reads like "This doesn't happen, except when it happens and the person has no recourse and it does in fact happen." - why make the post at all? If your internal workings fuck over someone externally prepare for your department to take the blame even if its "not your fault" - you work at the company that just fucked them over.
Re: 1-Click GitHub Token Stealing via a VSCode Bug
#84I am a bit confused. What if I just revoked OAuth access to github.dev? Wouldn't that just make the token unusable?
You cannot, it doesn't go through the regular OAuth flow. GitHub just automatically grants it a token.
Re: 1-Click GitHub Token Stealing via a VSCode Bug
#85Update as of 3rd June: Microsoft has fixed this with a stopgap fix by adding a confirmation when opening notebooks in web VSCode and not allowing trusted publisher to be skipped by commands (https://github.com/microsoft/vscode/pull/319705).
That's probably one of the fastest responses I've seen from a vendor.
Re: 1-Click GitHub Token Stealing via a VSCode Bug
#86This is an excellent and very interesting write-up.
It's so refreshing to read technical articles that are clearly written by a knowledgeable human and explained perfectly like this. By walking the reader through this with the example screenshots it unfolds and gets more interesting as you continue reading.
It's also strange to realize that these days, most articles are not like this.
Re: 1-Click GitHub Token Stealing via a VSCode Bug
#87I understand that there's frustration with MSRC, but surely the right move is to keep doing things right to the best of your abilities.
Like, disclose it, wait a week, publish it. That seems, to me, like it would avoid almost all the bad press this is getting, and shows that the researcher DOES care about actual security and not just recognition from MSFT.
Re: 1-Click GitHub Token Stealing via a VSCode Bug
#88Earlier quoted context omitted.
> temporary per-repo permission scope or token that allowed only pull and push to the repo in question How about pull from the repo but only push to a staging area from which the user, but not the token, can push for real? Frankly, LLM agents should do this too. Letting your LLM push seems foolhardy to me.
You can just fork the repository, give it access to the fork and then merge what you want
[deleted]
Re: 1-Click GitHub Token Stealing via a VSCode Bug
#89I understand that there's frustration with MSRC, but surely the right move is to keep doing things right to the best of your abilities. Like, disclose it, wait a week, publish it. That seems, to me, like it would avoid almost all the bad press this is getting, and shows that the researcher DOES care about actual security and not just recognition from MSFT.
It's up to the researcher to make the call. Maybe they feel that it's best to disclose to bring attention to the MSRC problem - arguably, that'll be massively better for security longer term vs a point in time vuln disclosure.
Re: 1-Click GitHub Token Stealing via a VSCode Bug
#90Earlier quoted context omitted.
> temporary per-repo permission scope or token that allowed only pull and push to the repo in question How about pull from the repo but only push to a staging area from which the user, but not the token, can push for real? Frankly, LLM agents should do this too. Letting your LLM push seems foolhardy to me.
You can just fork the repository, give it access to the fork and then merge what you want
This is a piece of cake using GitHub’s excellent permission system.
(I’m joking, of course. Service accounts are nowhere to be seen. OAuth can’t even scope to an organization, let alone a repository. And this whole github.dev thing illustrates that you don’t even need to explicitly grant permission to issue broadly scoped tokens.)
Also, forking is pretty heavyweight just to launch something that, for all anyone knows before starting actual work, is being used as a read only viewer.