Top
Best
New

Posted by ammar2 1 day ago

1-Click GitHub Token Stealing via a VSCode Bug(blog.ammaraskar.com)
600 points | 89 commentspage 2
thrdbndndn 14 hours ago|
Very good write up but I lost it a little at the end. Could someone clarify for me?

The author said:

You cannot just use the shortcut trick to install the evil extension directly because of new publisher trust system;

You can bypass this by using local workspace extensions which has no publisher screening, but CSP blocks it;

The solution seems to be that installing a local workspace extension which binds a shortcut of 'install extension without checking publisher'.

So I assume it means:

1. you need two extensions, 1st one is local and only for the keybinding, and 2nd one is the 'real' evil one and it doesn't need to (actually can't, because of CSP) be local anymore?

2. the CSP only prevents the JS in local extension but nothing about its package.json (or the ability to add shortcuts), right?

ammar2 13 hours ago|
1 and 2 are correct, take a look at the PoC repo here: https://github.com/ammaraskar/github-dev-token-steal-poc/tre...

We can try to just put a `my-extension/extension.js` for the most direct execution but the CSP blocks that. It's only a script-src CSP blocking it though, so fetching the package.json is still kosher. So we end up using it to contribute a keybinding instead.

parable 11 hours ago||
Kudos for the public disclosure. Too many people haven't been happy with MSRC and it's starting to boil over (see the Nightmare Eclipse situation, too). Maybe all of these disclosures will cause them to do some introspection and realize they're the problem. I highly doubt that, but one can dream.
nicce 10 hours ago|
I am not sure if this is still the best approach. They did not even try to submit based on expected "low" ranking when comparing to existing XSS submission. They should at least try or let them know many days before disclosing. You never know.
ammar2 2 hours ago|||
It's not just based on that, if you read the linked report from 2023 (https://blog.ammaraskar.com/vscode-rce/), I had a bug with the exact same impact of token exfiltration (It did need one additional click on the VSCode interface). They marked it as low severity, fixed it silently, didn't acknowledge that it had security impact and did not provide me any credit much less a bounty.
jeremyjh 6 hours ago|||
Its not just one issue they mishandled. It is a pattern. I think this makes sense if you believe long-term security requires leadership change at MSRC.

https://doublepulsar.com/microsofts-stance-on-zero-day-explo...

lionkor 4 hours ago||
I 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.

insanitybit 4 hours ago|
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.
NoahZuniga 8 hours ago||
> The only way to allow this behavior is to have the two web pages in the different origins cooperate with each other using the Window.postMessage() API

Small nitpick, but it's also possible to communicate by changing the location.anchor property (by either the iframe or its parent window.)

warm_soup 3 hours ago||
Excellent write up explaining all the steps with screenshots. It must have taken significant time to do this POC.
october8140 14 hours ago||
If you like VSCode but don't like Microsoft, try Zed (zed.dev).
arianvanp 11 hours ago||
Zed downloads random binaries on startup without any permissions prompts. No thanks.
ffemac 10 hours ago||
I looked into Zed because popular harness (OpenCode/KiloCode) just random downloads npm packages in the background and didn't tell you. But then I found out reports of Zed doing the same. Why we can't have nice things?
Quothling 12 hours ago|||
I heard that Zed came with a lot of integrated AI and team sharing features that phone home, so that's an issue for anyone working with stuff like NIS2 compliance. Not that VSCode isn't a compliance nightmare as well.
throwaway041207 8 hours ago|||
Zed is nice, but the project wide search (sidebar based) in VS Code and diff viewer in VS Code are still better IMO and unfortunately since I no longer code, those are my most used features of an editor. Still using it instead of VS Code but I sure wish it improved those views.
karimf 6 hours ago||
I've been using Zed for a few weeks now and these two are also my main complaints as well.
ZeroCool2u 14 hours ago|||
Zed is excellent. I know it's weird, but the last thing holding me back is being able to have a browser based Zed session the same as VSCode.
dddw 12 hours ago||
If you like vs. but not M$. Use VsCodium. I did, but now preffer zed, which replaced my use of vscodium and sublimetext in 1 swoop.
jonnyysmith 7 hours ago||
GitHub does not currently provide a built-in repository setting to disable github.dev

Very cool.

antimony51 13 hours ago||
> if you had some other XSS in a webview that you can get a victim to open, you get effectively full RCE on their computer.

Github creds or the computer, can't decide which one is worse.

ThanosAkr 11 hours ago||
I am a bit confused. What if I just revoked OAuth access to github.dev? Wouldn't that just make the token unusable?
ammar2 5 hours ago|
You cannot, it doesn't go through the regular OAuth flow. GitHub just automatically grants it a token.
JessieJanie 9 hours ago|
Thank you for all your efforts and detail here, noted.
More comments...