This is a very good writeup.

Zooming way out (perhaps to the point of useless observation), it's a pity that the web embedded VSCode editor is signed into GitHub at all. Defense-in-depth or not, a huge vulnerability surface arises from that original sin. It'd be like if you had a god-permissioned GitHub API token stored in world-readable plaintext on your workstation for the malicious-NPM-package-of-the-week to find.

In a perfect world, it'd be awesome if the in-browser IDE launched with a temporary per-repo permission scope or token that allowed only pull and push to the repo in question; no github.com web session whatsoever. If you want the full GitHub web UI experience, well .... go back to github.com; make github.dev a single-repo service.

I'm assuming that's a) inconvenient for users, b) hard to implement, and c) a historical assumption baked into a lot of the github.dev tooling, though. Ah well.

Update 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.

> 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?

Thank you for essentially donating the time you spent on this exploit to raise awareness on improving VS Code's security response. You could have just given up on them but you're still trying to help.

I had this happen to me recently

github token got stolen and also cloudflare tokens

guys even if you take security seriously you are going to get hit on a long enough time frame

best thing to do is segregate and control damage

trust no one, nothing, use orbstack, and always operate under the assumption that your token is going to get leaked at some point

it knocked off my entire momentum. fortunately seemed like it was just a spam bot that took my tokens and created bunch of fake spam pages and trying to mine crypto

the biggest feeling is the one of feeling violated

take care fellow travelers

The attack surface that makes this particularly nasty is that VSCode extensions run with the same trust level as the editor itself, and most developers have dozens installed without reviewing their permissions. A malicious or compromised extension silently exfiltrating GitHub tokens is undetectable without network monitoring. This is a good argument for running extensions in isolated profiles.

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.

The MSRC situation is really unbelievable.

There are probably better sources but I think this video by The Primeagen is a good introduction.

https://www.youtube.com/watch?v=9kxx5xp5nTQ

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?

I don’t really understand why more devs don’t try Neovim.

Maybe it’s just my preference, but I like having a small setup where I know what is installed and what is running. With VSCode, browser IDEs, extensions, sync, tokens, and random plugins, it gets hard to tell what actually has access to what.

This 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.

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.

> 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.)

The more I think about it, I feel sad about this state of things. More than likely chances are that there are people in Github who already knew about this behavior, unfortunately raising issues can be seen as introducing more friction to product/feature and it certainly does not puts anyone in good light so they either kept quiet or the more vocal voices drowned them.

Very unethical behavior combined by very bad security posture from the vendor. Bad.

> 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.

Excellent write up explaining all the steps with screenshots. It must have taken significant time to do this POC.

I am a bit confused. What if I just revoked OAuth access to github.dev? Wouldn't that just make the token unusable?

GitHub does not currently provide a built-in repository setting to disable github.dev

Very cool.

the title should be changed to '1-Click GitHub Token Stealing via a VSCode Bug in the websites vscode.dev and github.dev* only'

If you like VSCode but don't like Microsoft, try Zed (zed.dev).

Thank you for all your efforts and detail here, noted.

This is a very good writeup.

I love vanilla vim.

Ok, I really need to look into Kate and maybe Neovim. Fuck this shit, honestly.

[dead]

[dead]

[dead]

[dead]

[dead]

[dead]

[flagged]

[dead]

[dead]

tl;dr: never press github.dev or open vscode.dev on a repo you don't trust

And when what it does with it?

> To those folks, I am sorry, but this is one of the few levers I have to try to influence MSRC and the security posture of VSCode

Someone is going to be blacklisted by Microsoft.