[zbentley]

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.

[ammar2]

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

[itopaloglu83]

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]

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]

> GitHub runs a great program on HackerOne

I agree, for the record here's my HackerOne profile 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.

[ffemac]

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

You typically don't want to run opencode outside a sandbox anyway.

[ffemac]

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)

[himata4113]

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.

[maxloh]

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.

[zbentley]

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

[lifis]

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.

[amluto]

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

[lifis]

You can just fork the repository, give it access to the fork and then merge what you want

[amluto]

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.

[alostpuppy]

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.

[ndegwaduncan]

the scope problem is actually worse with agents than with github.dev. the architectural answer is the same though: the credential the agent operates with should be scoped to the task and expire when the task ends.

[namibj]

Jules is heavily restricted in what it can do to your repos.

[moi2388]

That makes so much more sense.

[hju22_-3]

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]

How does this work with the in-browser editor at github.dev?

[paulddraper]

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

[owl57]

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]

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]

Not if they're touch required in a secure enclave like a yubikey

[dns_snek]

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.