6 ms·

1-Click GitHub Token Stealing via a VSCode Bug

660 points by ammar2 4mo ago

Noumenon72 4mo ago
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.
- ammar2 4mo ago
  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.
zbentley 4mo ago
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.
- owl57 4mo ago
  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?
  - digi59404 4mo ago
    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.
  - ikiris 4mo ago
    Not if they're touch required in a secure enclave like a yubikey
    - dns_snek 4mo ago
      Malware running on your computer can engineer a situation where you would naturally press that without suspecting anything. 1. Malware logs you out of github.com 2. It waits for you to navigate to the login page 3. It initiates an SSH/signing operation requiring physical touch 4. You hit login on github.com, a 2nd FIDO operation is queued up 5. You press the yubikey button, confirming the SSH operation 6. "Nothing happens", so you press it again to log in 7. You're now logged in, and your SSH credentials have just been hijacked. Or it could just inject itself into your shell profile, and do this the next time you ssh anywhere. You never really know what you're confirming so Yubikey's threat model implicitly depends on the host device being trustworthy. This is why hardware wallets for crypto have a physical display to confirm the address and the amount before signing the transaction.
  - ethanhq 4mo ago
    [flagged]
- ammar2 4mo ago
  > 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-codespaces-rce-supply-chain-attack/#h-what-is-the-immediate-impact https://orca.security/resources/blog/hacking-github-codespac...
  - itopaloglu83 4mo ago
    Or they could’ve kept their bounty program running smoothly. But instead they pissed off another security researcher and received a zero days heads-up before public disclosure.
    - st3fan 4mo ago
      There is no excuse. GitHub runs a great program on HackerOne and it should just have been submitted there. Also note that the person who found this was pissed because they had a difficult experience with submitting a bug for VSCode THREE YEARS AGO through MSRC which is _completely different_ than the GitHub H1 program and no doubt much more challenging with a different experience. There is really no excuse for this irresponsible disclosure. They could have at least tried instead of holding a grudge for three years.
      - ammar2 4mo ago
        > GitHub runs a great program on HackerOne I agree, for the record here's my HackerOne profile https://hackerone.com/ammar2/hacktivity?type=user https://hackerone.com/ammar2/hacktivity?type=user Just for context, that 2023 bug was initially reported to GitHub's HackerOne program and they explicitly told me it was out of scope for them and to take it to MSRC: > We have reviewed the report and determined that the vulnerabilities is in VS code and the fix will be implemented by Microsoft. As a result, it is not eligible for reward under the Bug Bounty program. Please follow-up with Microsoft via the report you submitted. There was also an additional bug that allowed an attacker to exfiltrate private repo contents with a github.dev link that MSRC also marked as not having security impact. I absolutely loved working with GitHub folks on the GitHub bug bounty program, they're responsive, go into technical details with you and are awesome to deal with. MSRC is like the polar opposite of that.
- amluto 4mo ago
  > 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.
  - moi2388 4mo ago
    That makes so much more sense.
  - alostpuppy 4mo ago
    Exe.dev has an integrations feature which is similar allowing you to grant access to specific repos without having give the VMs credentials. I think it’s a similar pattern to iron.sh. I have been thinking more and more about how I might use this pattern.
  - namibj 4mo ago
    Jules is heavily restricted in what it can do to your repos.
  - lifis 4mo ago
    You can just fork the repository, give it access to the fork and then merge what you want
    - deleted 4mo ago
      [deleted]
    - amluto 4mo ago
      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.
  - 4mo ago
- ffemac 4mo ago
  > malicious-NPM-package-of-the-week This is going to get worse and worse. I recently noticed AI harness (e.g. OpenCode) downloading random npm packages in the background and litter them everywhere in a few place in ~ and in your project dir, all without telling/asking you. What's worse is that people don't seem to care even the devs.
  - himata4113 4mo ago
    You typically don't want to run opencode outside a sandbox anyway.
    - ffemac 4mo ago
      True, but security breach inside a sandbox/container can cause serious damage too(stealing your code/data/keys, spreading via your code/release etc). And containers aren't for security anyway(e.g. Copy Fail breaching to host https://xint.io/blog/copy-fail-pod-to-host https://xint.io/blog/copy-fail-pod-to-host)
      - himata4113 4mo ago
        It's rare that both of those align and it is very unlikely that both are used at once. Most of the exploits (if not all) just install rce, rat and/or steal env.
- lifis 4mo ago
  I think it's ok to be signed-in when opening your own repositories, but definitely not when opening repositories from other accounts. And also the webview keyboard shortcut thing needs to be fixed to only allow harmless keybinds and NOT propagate to any keydown handler. Also on desktop it should be removed in favor of Electron intercepting directly. And on web it should probably disabled by the default.
- hju22_-3 4mo ago
  You can use SSH keys and GitHub deploy keys to approximate this. Can't speak for the security of it, but I have never set up GitHub with access to every repo. Not sure if there exists approximate functionality in other git forges though.
  - zbentley 4mo ago
    How does this work with the in-browser editor at github.dev?
- maxloh 4mo ago
  I think the problem lies in the fundamental design of VS Code extensions in general. They are essentially Node.js apps with full access to built-in modules, including fs. If the corresponding VS Code instance is launched with your user privileges, extensions can technically read files in ~/.ssh. It is not safe in the sense that for every extension you install, you are essentially installing a new Node.js app with all its bundled dependencies. Even if you trust the publisher, I am sure there are many holes to exploit.
  - zmysysz 4mo ago
    [flagged]
  - zbentley 4mo ago
    My comment had more to do with the in-browser VS Code instance. Regardless of the extension security model, having the github.dev webapp run under your full github.com account's permissions significantly expands the attack surface: if you launch github.dev in one repo and install a malicious extension, that extension can reach and compromise all repos your GitHub user can reach, private or public. Scoping it to one repo would only allow a malicious extension to write code in that repo and not mess with the GitHub API or other repos. Separately, I think the debate around extensions/plugins in general boils down to the same conversation about trust and isolation we have for every third-party software supplier (package managers etc.). Options include: 1. Vetting/blessing certain extensions. 2. Serving built extensions from a central registry/artifact store with security protections 3. Having VSCode organically grow a shitty version of different operating systems' "X wants to access Y; confirm?" permissions access system (a pain in the ass to do in a cross-platform way). 4. Having VSCode somehow run extensions as separate applications according to the OS and leveraging the OS's permission system (still hard, and because it's an IDE, rather a lot of extensions will need--or request because of sloppy extension code--very broad permissions, at which point an extension is one transitive dependency update away from compromising your system). 5. Running the entire VSCode instance in some sort of container/VM/sandbox (the amount of access holes folks poke in the Snap/Flatpak VSCode instances, and the number of common issues for which "stop using the container and install VSCode directly on the system" is the recommended fix does not give me hope that this will be adopted by anyone but the most expert, patient, and paranoid users).
- paulddraper 4mo ago
  > 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. That's...exactly what the AWS CLI does.
fg137 4mo ago
> 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.
- NagatoYuzuru 4mo ago
  [flagged]
- ares623 4mo ago
  "Oh great Mythos, how do I remove all vulnerabilities from my products?" Percolating... Ban all vulnerability researchers
- theguidessuck 4mo ago
  Damn, what a disaster. Then they won't allow him to tell them about the bugs they don't take seriously.
NagatoYuzuru 4mo ago
> 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?
- natpalmer1776 4mo ago
  It was the status quo for a long time, then the pesky security researchers started asking for compensation instead of clout.
  - ammar2 4mo ago
    > 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.
    - natpalmer1776 4mo ago
      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.
    - DANmode 4mo ago
      That’s most of the why it’s tough to be upset when people just release 0-days on Twitter - especially for big firms.
  - opello 4mo ago
    Do it for the exposure! Artists of many stripes have had to combat that for ages.
- guessmyname 4mo ago
  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 not, that being associated with a security bug could reflect poorly on them or affect future promotion opportunities. The result is that by the time the security team attempts to reproduce the report, the vulnerability is already gone. From MSRC’s perspective, all they see is that the provided reproduction steps no longer work. They have no visibility into the internal history of the bug or whether someone already patched it. As a result, the report gets closed as invalid even though the original finding may have been legitimate.
pier25 4mo ago
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 https://www.youtube.com/watch?v=9kxx5xp5nTQ
october8140 4mo ago
If you like VSCode but don't like Microsoft, try Zed (zed.dev).
- dddw 4mo 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.
- ZeroCool2u 4mo 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.
- Quothling 4mo 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.
- arianvanp 4mo ago
  Zed downloads random binaries on startup without any permissions prompts. No thanks.
  - ffemac 4mo 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?
- throwaway041207 4mo 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.
thrdbndndn 4mo 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 4mo ago
  1 and 2 are correct, take a look at the PoC repo here: https://github.com/ammaraskar/github-dev-token-steal-poc/tree/main/.vscode/extensions/my-extension 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.
vladsiu 4mo ago
[dead]
zuzululu 4mo ago
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
- pjot 4mo ago
  > created bunch of fake spam pages and trying to mine crypto Pages like GitHub pages? We’re repos being created in your account? Curious how you discovered that your tokens were pwned
  - zuzululu 4mo ago
    repos created, cloudflare eployed thee websites, edited dns saw a weird spam site, so damn tired went to bed thinking it was some mislick on my side woke up next morning and loaded up my domain, it redirected and panic set in my SEO is probably nuked even though it has been under 24 hours
- worldsavior 4mo ago
  Secret ad to orbstack.
  - zuzululu 4mo ago
    first time I mentioned it on here and no it won't be enough but better than running npms from wild naked just pointing out what I use currently if you know something better/competitor please feel free to advertise them
    - worldsavior 4mo ago
      Maybe...Docker? Orbstack is basically a wrapper over docker, and he advertises the program as something uniquely fast, which is just a docker behind the scens.
antimony51 4mo 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.
selectively 4mo ago
Very unethical behavior combined by very bad security posture from the vendor. Bad.
lavaman131 4mo ago
[dead]
ThanosAkr 4mo 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 4mo ago
  You cannot, it doesn't go through the regular OAuth flow. GitHub just automatically grants it a token.
  - ThanosAkr 4mo ago
    Oh, i see thanks for the reply.
1519035161 4mo ago
[dead]
meszmate 4mo ago
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.
- shinycode 4mo ago
  I noticed that is quite hard to make people change habits regarding software. There is shortcuts to learn and we might feel slow at first which reinforces the feeling of « it’s not better ». It takes a while to get used to nvim, once there it’s faster but that explain why many people stay in their confort zone
  - okayishdefaults 4mo ago
    One of the most important things I've ever read as someone that wants to be able to break out of my comfort zone was from Uiua's website. Foreign != confusing
- ulimn 4mo ago
  I really like Helix. I didn't dig into Neovim much but Helix has pretty nice IDE-like features that I always missed from vim (without riddling it with plugins or using SpaceVim or such). Check it out, maybe you'll like it as well.
- strogonoff 4mo ago
  I stopped using VS Code and switched to Neovim some years ago, once I noticed that the former would automatically install random Python packages with typings for libraries without stock typings. The “feature” (part of Microsoft’s official Python extension, which was the only one that worked acceptably well for me in other regards) ended up installing type definitions for a different version of a library than the one my project would use, seemed wildly insecure as it casually ran third-party unvetted code, and was evidently not configurable. I wish I could add “and I never looked back”, but honestly in the past year or two Neovim started regularly breaking my setup (approximately every upgrade). Had some inklings it might happen eventually… Strictly speaking, 10 years in, nvim is yet to have its first stable version released—which means technically one can’t blame it for instability, but which is useful to keep in mind. Considering going back to plain vim. I’m sure I will lose many niceties, but hopefully it would not require me to troubleshoot broken functionality in the middle of work.
omelas_tech 4mo ago
tl;dr: never press github.dev or open vscode.dev on a repo you don't trust
- minitech 4mo ago
  and don’t open links like https://tinyurl.com/2s3twstw https://tinyurl.com/2s3twstw either, or any other page on the internet that’s able to redirect you to github.dev
- simonw 4mo ago
  That's a hard rule to follow when any website on the internet might redirect a browser tab to a URL on one of those domains.
parable 4mo 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 4mo 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.
  - jeremyjh 4mo 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-exploits-is-a-dumpster-fire-of-their-own-making-0946117940a4 https://doublepulsar.com/microsofts-stance-on-zero-day-explo...
  - ammar2 4mo ago
    It's not just based on that, if you read the linked report from 2023 (https://blog.ammaraskar.com/vscode-rce/ 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.
    - nicce 4mo ago
      I thought that the general issue was that they ignore the submissions and do not fix them - but the actual problem is that they give different severity and may not give fame or money? I think disclosure for those reasons is highly in gray area from ethical perspective. Regardless if it was clearly in the scope of the bug bounty program or not. That is distinct problem and does not justify public disclosure without warning with enough time.
AgentReinAi 4mo ago
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.
- crimsonnoodle58 4mo ago
  > is undetectable without network monitoring Even with network monitoring, exfil to Github itself can be very hard to stop unless you SSL intercept and have very strict URL allow lists. Best is to move away from Github, move to self hosted internal Gitlab/Forgejo and block Github completely.
Asfand3099 4mo ago
[dead]
imron 4mo ago
I love vanilla vim.
JessieJanie 4mo ago
Thank you for all your efforts and detail here, noted.
notlibrary 4mo ago
And when what it does with it?
NoahZuniga 4mo 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.)
Webhix 4mo ago
This is a very good writeup.
devmanjoe 4mo ago
[flagged]
delis-thumbs-7e 4mo ago
Ok, I really need to look into Kate and maybe Neovim. Fuck this shit, honestly.
jonnyysmith 4mo ago
GitHub does not currently provide a built-in repository setting to disable github.dev Very cool.
outageroom 4mo ago
[dead]
assanineass 4mo ago
[dead]
volume_tech 4mo ago
[dead]
ammar2 4mo ago
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 https://github.com/microsoft/vscode/pull/319705). That's probably one of the fastest responses I've seen from a vendor.
EMM_386 4mo ago
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.
- ammar2 4mo ago
  heh, a friend actually pointed out a typo on a first draft and said "maybe you shouldn't fix it to show it's not LLM written".
lionkor 4mo 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 4mo 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.
warm_soup 4mo ago
Excellent write up explaining all the steps with screenshots. It must have taken significant time to do this POC.
sandeepkd 4mo ago
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.
cyh555 4mo ago
the title should be changed to '1-Click GitHub Token Stealing via a VSCode Bug in the websites vscode.dev and github.dev* only'
Ember_Wipe 4mo ago
[dead]

660 points by ammar2 4mo ago

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.

ammar2 4mo ago
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.

zbentley 4mo ago

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.

owl57 4mo ago
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?
- digi59404 4mo ago
  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.
- ikiris 4mo ago
  Not if they're touch required in a secure enclave like a yubikey
  - dns_snek 4mo ago
    Malware running on your computer can engineer a situation where you would naturally press that without suspecting anything. 1. Malware logs you out of github.com 2. It waits for you to navigate to the login page 3. It initiates an SSH/signing operation requiring physical touch 4. You hit login on github.com, a 2nd FIDO operation is queued up 5. You press the yubikey button, confirming the SSH operation 6. "Nothing happens", so you press it again to log in 7. You're now logged in, and your SSH credentials have just been hijacked. Or it could just inject itself into your shell profile, and do this the next time you ssh anywhere. You never really know what you're confirming so Yubikey's threat model implicitly depends on the host device being trustworthy. This is why hardware wallets for crypto have a physical display to confirm the address and the amount before signing the transaction.
- ethanhq 4mo ago
  [flagged]
ammar2 4mo ago
> 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-codespaces-rce-supply-chain-attack/#h-what-is-the-immediate-impact https://orca.security/resources/blog/hacking-github-codespac...
- itopaloglu83 4mo ago
  Or they could’ve kept their bounty program running smoothly. But instead they pissed off another security researcher and received a zero days heads-up before public disclosure.
  - st3fan 4mo ago
    There is no excuse. GitHub runs a great program on HackerOne and it should just have been submitted there. Also note that the person who found this was pissed because they had a difficult experience with submitting a bug for VSCode THREE YEARS AGO through MSRC which is _completely different_ than the GitHub H1 program and no doubt much more challenging with a different experience. There is really no excuse for this irresponsible disclosure. They could have at least tried instead of holding a grudge for three years.
    - ammar2 4mo ago
      > GitHub runs a great program on HackerOne I agree, for the record here's my HackerOne profile https://hackerone.com/ammar2/hacktivity?type=user https://hackerone.com/ammar2/hacktivity?type=user Just for context, that 2023 bug was initially reported to GitHub's HackerOne program and they explicitly told me it was out of scope for them and to take it to MSRC: > We have reviewed the report and determined that the vulnerabilities is in VS code and the fix will be implemented by Microsoft. As a result, it is not eligible for reward under the Bug Bounty program. Please follow-up with Microsoft via the report you submitted. There was also an additional bug that allowed an attacker to exfiltrate private repo contents with a github.dev link that MSRC also marked as not having security impact. I absolutely loved working with GitHub folks on the GitHub bug bounty program, they're responsive, go into technical details with you and are awesome to deal with. MSRC is like the polar opposite of that.
amluto 4mo ago
> 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.
- moi2388 4mo ago
  That makes so much more sense.
- alostpuppy 4mo ago
  Exe.dev has an integrations feature which is similar allowing you to grant access to specific repos without having give the VMs credentials. I think it’s a similar pattern to iron.sh. I have been thinking more and more about how I might use this pattern.
- namibj 4mo ago
  Jules is heavily restricted in what it can do to your repos.
- lifis 4mo ago
  You can just fork the repository, give it access to the fork and then merge what you want
  - deleted 4mo ago
    [deleted]
  - amluto 4mo ago
    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.
- 4mo ago
ffemac 4mo ago
> malicious-NPM-package-of-the-week This is going to get worse and worse. I recently noticed AI harness (e.g. OpenCode) downloading random npm packages in the background and litter them everywhere in a few place in ~ and in your project dir, all without telling/asking you. What's worse is that people don't seem to care even the devs.
- himata4113 4mo ago
  You typically don't want to run opencode outside a sandbox anyway.
  - ffemac 4mo ago
    True, but security breach inside a sandbox/container can cause serious damage too(stealing your code/data/keys, spreading via your code/release etc). And containers aren't for security anyway(e.g. Copy Fail breaching to host https://xint.io/blog/copy-fail-pod-to-host https://xint.io/blog/copy-fail-pod-to-host)
    - himata4113 4mo ago
      It's rare that both of those align and it is very unlikely that both are used at once. Most of the exploits (if not all) just install rce, rat and/or steal env.
lifis 4mo ago
I think it's ok to be signed-in when opening your own repositories, but definitely not when opening repositories from other accounts. And also the webview keyboard shortcut thing needs to be fixed to only allow harmless keybinds and NOT propagate to any keydown handler. Also on desktop it should be removed in favor of Electron intercepting directly. And on web it should probably disabled by the default.
hju22_-3 4mo ago
You can use SSH keys and GitHub deploy keys to approximate this. Can't speak for the security of it, but I have never set up GitHub with access to every repo. Not sure if there exists approximate functionality in other git forges though.
- zbentley 4mo ago
  How does this work with the in-browser editor at github.dev?
maxloh 4mo ago
I think the problem lies in the fundamental design of VS Code extensions in general. They are essentially Node.js apps with full access to built-in modules, including fs. If the corresponding VS Code instance is launched with your user privileges, extensions can technically read files in ~/.ssh. It is not safe in the sense that for every extension you install, you are essentially installing a new Node.js app with all its bundled dependencies. Even if you trust the publisher, I am sure there are many holes to exploit.
- zmysysz 4mo ago
  [flagged]
- zbentley 4mo ago
  My comment had more to do with the in-browser VS Code instance. Regardless of the extension security model, having the github.dev webapp run under your full github.com account's permissions significantly expands the attack surface: if you launch github.dev in one repo and install a malicious extension, that extension can reach and compromise all repos your GitHub user can reach, private or public. Scoping it to one repo would only allow a malicious extension to write code in that repo and not mess with the GitHub API or other repos. Separately, I think the debate around extensions/plugins in general boils down to the same conversation about trust and isolation we have for every third-party software supplier (package managers etc.). Options include: 1. Vetting/blessing certain extensions. 2. Serving built extensions from a central registry/artifact store with security protections 3. Having VSCode organically grow a shitty version of different operating systems' "X wants to access Y; confirm?" permissions access system (a pain in the ass to do in a cross-platform way). 4. Having VSCode somehow run extensions as separate applications according to the OS and leveraging the OS's permission system (still hard, and because it's an IDE, rather a lot of extensions will need--or request because of sloppy extension code--very broad permissions, at which point an extension is one transitive dependency update away from compromising your system). 5. Running the entire VSCode instance in some sort of container/VM/sandbox (the amount of access holes folks poke in the Snap/Flatpak VSCode instances, and the number of common issues for which "stop using the container and install VSCode directly on the system" is the recommended fix does not give me hope that this will be adopted by anyone but the most expert, patient, and paranoid users).
paulddraper 4mo ago
> 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. That's...exactly what the AWS CLI does.

fg137 4mo ago

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

NagatoYuzuru 4mo ago
[flagged]
ares623 4mo ago
"Oh great Mythos, how do I remove all vulnerabilities from my products?" Percolating... Ban all vulnerability researchers
theguidessuck 4mo ago
Damn, what a disaster. Then they won't allow him to tell them about the bugs they don't take seriously.

NagatoYuzuru 4mo ago

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

natpalmer1776 4mo ago
It was the status quo for a long time, then the pesky security researchers started asking for compensation instead of clout.
- ammar2 4mo ago
  > 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.
  - natpalmer1776 4mo ago
    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.
  - DANmode 4mo ago
    That’s most of the why it’s tough to be upset when people just release 0-days on Twitter - especially for big firms.
- opello 4mo ago
  Do it for the exposure! Artists of many stripes have had to combat that for ages.
guessmyname 4mo ago
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 not, that being associated with a security bug could reflect poorly on them or affect future promotion opportunities. The result is that by the time the security team attempts to reproduce the report, the vulnerability is already gone. From MSRC’s perspective, all they see is that the provided reproduction steps no longer work. They have no visibility into the internal history of the bug or whether someone already patched it. As a result, the report gets closed as invalid even though the original finding may have been legitimate.

pier25 4mo ago

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 https://www.youtube.com/watch?v=9kxx5xp5nTQ

october8140 4mo ago

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

dddw 4mo 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.
ZeroCool2u 4mo 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.
Quothling 4mo 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.
arianvanp 4mo ago
Zed downloads random binaries on startup without any permissions prompts. No thanks.
- ffemac 4mo 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?
throwaway041207 4mo 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.

thrdbndndn 4mo 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 4mo ago
1 and 2 are correct, take a look at the PoC repo here: https://github.com/ammaraskar/github-dev-token-steal-poc/tree/main/.vscode/extensions/my-extension 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.

vladsiu 4mo ago

[dead]

zuzululu 4mo ago

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

pjot 4mo ago
> created bunch of fake spam pages and trying to mine crypto Pages like GitHub pages? We’re repos being created in your account? Curious how you discovered that your tokens were pwned
- zuzululu 4mo ago
  repos created, cloudflare eployed thee websites, edited dns saw a weird spam site, so damn tired went to bed thinking it was some mislick on my side woke up next morning and loaded up my domain, it redirected and panic set in my SEO is probably nuked even though it has been under 24 hours
worldsavior 4mo ago
Secret ad to orbstack.
- zuzululu 4mo ago
  first time I mentioned it on here and no it won't be enough but better than running npms from wild naked just pointing out what I use currently if you know something better/competitor please feel free to advertise them
  - worldsavior 4mo ago
    Maybe...Docker? Orbstack is basically a wrapper over docker, and he advertises the program as something uniquely fast, which is just a docker behind the scens.

antimony51 4mo 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.

selectively 4mo ago

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

lavaman131 4mo ago

[dead]

ThanosAkr 4mo 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 4mo ago
You cannot, it doesn't go through the regular OAuth flow. GitHub just automatically grants it a token.
- ThanosAkr 4mo ago
  Oh, i see thanks for the reply.

1519035161 4mo ago

[dead]

meszmate 4mo ago

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.

shinycode 4mo ago
I noticed that is quite hard to make people change habits regarding software. There is shortcuts to learn and we might feel slow at first which reinforces the feeling of « it’s not better ». It takes a while to get used to nvim, once there it’s faster but that explain why many people stay in their confort zone
- okayishdefaults 4mo ago
  One of the most important things I've ever read as someone that wants to be able to break out of my comfort zone was from Uiua's website. Foreign != confusing
ulimn 4mo ago
I really like Helix. I didn't dig into Neovim much but Helix has pretty nice IDE-like features that I always missed from vim (without riddling it with plugins or using SpaceVim or such). Check it out, maybe you'll like it as well.
strogonoff 4mo ago
I stopped using VS Code and switched to Neovim some years ago, once I noticed that the former would automatically install random Python packages with typings for libraries without stock typings. The “feature” (part of Microsoft’s official Python extension, which was the only one that worked acceptably well for me in other regards) ended up installing type definitions for a different version of a library than the one my project would use, seemed wildly insecure as it casually ran third-party unvetted code, and was evidently not configurable. I wish I could add “and I never looked back”, but honestly in the past year or two Neovim started regularly breaking my setup (approximately every upgrade). Had some inklings it might happen eventually… Strictly speaking, 10 years in, nvim is yet to have its first stable version released—which means technically one can’t blame it for instability, but which is useful to keep in mind. Considering going back to plain vim. I’m sure I will lose many niceties, but hopefully it would not require me to troubleshoot broken functionality in the middle of work.

omelas_tech 4mo ago

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

minitech 4mo ago
and don’t open links like https://tinyurl.com/2s3twstw https://tinyurl.com/2s3twstw either, or any other page on the internet that’s able to redirect you to github.dev
simonw 4mo ago
That's a hard rule to follow when any website on the internet might redirect a browser tab to a URL on one of those domains.

parable 4mo 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 4mo 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.
- jeremyjh 4mo 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-exploits-is-a-dumpster-fire-of-their-own-making-0946117940a4 https://doublepulsar.com/microsofts-stance-on-zero-day-explo...
- ammar2 4mo ago
  It's not just based on that, if you read the linked report from 2023 (https://blog.ammaraskar.com/vscode-rce/ 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.
  - nicce 4mo ago
    I thought that the general issue was that they ignore the submissions and do not fix them - but the actual problem is that they give different severity and may not give fame or money? I think disclosure for those reasons is highly in gray area from ethical perspective. Regardless if it was clearly in the scope of the bug bounty program or not. That is distinct problem and does not justify public disclosure without warning with enough time.

AgentReinAi 4mo ago

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.

crimsonnoodle58 4mo ago
> is undetectable without network monitoring Even with network monitoring, exfil to Github itself can be very hard to stop unless you SSL intercept and have very strict URL allow lists. Best is to move away from Github, move to self hosted internal Gitlab/Forgejo and block Github completely.

Asfand3099 4mo ago

[dead]

imron 4mo ago

I love vanilla vim.

JessieJanie 4mo ago

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

notlibrary 4mo ago

And when what it does with it?

NoahZuniga 4mo 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.)

Webhix 4mo ago

This is a very good writeup.

devmanjoe 4mo ago

[flagged]

delis-thumbs-7e 4mo ago

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

jonnyysmith 4mo ago

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

outageroom 4mo ago

[dead]

assanineass 4mo ago

[dead]

volume_tech 4mo ago

[dead]

ammar2 4mo ago

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 https://github.com/microsoft/vscode/pull/319705). That's probably one of the fastest responses I've seen from a vendor.

EMM_386 4mo ago

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.

ammar2 4mo ago
heh, a friend actually pointed out a typo on a first draft and said "maybe you shouldn't fix it to show it's not LLM written".

lionkor 4mo 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 4mo 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.

warm_soup 4mo ago

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

sandeepkd 4mo ago

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.

cyh555 4mo ago

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

Ember_Wipe 4mo ago

[dead]