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.
> it'd be awesome if the in-browser IDE launched with a temporary per-repo permission scope
That's actually exactly what they do for codespaces. The token only has read/write on the repo you activated for the codespace [1]. They should definitely consider doing that for github.dev as well.
If the malicious-npm-package-of-the-week is reading arbitrary files on your workstation, isn't it usually able to run git clone/push/whatever with your current credentials anyway?
Yes, but also no. For example in GitLab a user who’s infected could push code to a branch. Then it could even make a merge request to pull that branch into main (if main is protected).
But then someone else on the team should have to manually approve that MR to allow it to be merged to main.
This kind of defeats the ability of malware to push stuff out automatically.
Very good write up but I lost it a little at the end. Could someone clarify for me?
The author said:
You can 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 install a local workspace extension which binds another 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 know about the specifics of this case but I have managed bug bounty programs in the past via Bountysource and HackerOne. What often happens is that the bug report is somehow leaked to the development team responsible for the code before the bug report is fully assessed by the security team, MSRC in this case, and so one developer decides to quietly fix the problem due to an irrational fear that if others around them realize they were the cause of the security problem, then it could potentially affect their promotion.
I'm catching up on the infosec twitter side but it seems like it was even worse. A lot of people have the same story as me in 2023 of "they silently patch the bug and don't even credit you" which really stinks.
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 have no interest in selling these vulnerabilities or sitting on them. At the same time, it feels really bad to have a vendor disrespect the hours it can take to make a proof-of-concept by just patching it silently and not crediting you or acknowledging it.
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.
> it'd be awesome if the in-browser IDE launched with a temporary per-repo permission scope
That's actually exactly what they do for codespaces. The token only has read/write on the repo you activated for the codespace [1]. They should definitely consider doing that for github.dev as well.
[1] https://orca.security/resources/blog/hacking-github-codespac...
> 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.
If the malicious-npm-package-of-the-week is reading arbitrary files on your workstation, isn't it usually able to run git clone/push/whatever with your current credentials anyway?
Yes, but also no. For example in GitLab a user who’s infected could push code to a branch. Then it could even make a merge request to pull that branch into main (if main is protected).
But then someone else on the team should have to manually approve that MR to allow it to be merged to main.
This kind of defeats the ability of malware to push stuff out automatically.
Very good write up but I lost it a little at the end. Could someone clarify for me?
The author said:
You can 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 install a local workspace extension which binds another 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?
> 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 about the specifics of this case but I have managed bug bounty programs in the past via Bountysource and HackerOne. What often happens is that the bug report is somehow leaked to the development team responsible for the code before the bug report is fully assessed by the security team, MSRC in this case, and so one developer decides to quietly fix the problem due to an irrational fear that if others around them realize they were the cause of the security problem, then it could potentially affect their promotion.
It was the status quo for a long time, then the pesky security researchers started asking for compensation instead of clout.
> instead of clout
I'm catching up on the infosec twitter side but it seems like it was even worse. A lot of people have the same story as me in 2023 of "they silently patch the bug and don't even credit you" which really stinks.
It definitely reminds me of the stereotypes of big business types stepping on the little guys to climb the ladder.
I hope you get credit where credit is due in future endeavors.
Do it for the exposure! Artists of many stripes have had to combat that for ages.
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.
Thank you, that's a very kind comment.
I have no interest in selling these vulnerabilities or sitting on them. At the same time, it feels really bad to have a vendor disrespect the hours it can take to make a proof-of-concept by just patching it silently and not crediting you or acknowledging it.
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
> 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.
If you like VSCode but don't like Microsoft, try Zed (zed.dev).
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.