Caesarsage / Caesarsage/microcks-vscode
Arbitrary code execution from an untrusted workspace via microcks.cliPath
- Dominant language
- TypeScript
- Stars
- 1
- Forks
- 1
- Avg merge
- 2d 17h
- Merged PRs (30d)
- 1
Description
Severity: high, I think. Something like CVSS 7.8 (AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H) but don't take my scoring too seriously. Tested on 0.1.0, looks like it's been there since the beginning.
## What's wrong
Short version: a repo can put `microcks.cliPath` in its own `.vscode/settings.json`, and the extension will happily spawn whatever is at that path. It does this on activation, so the user doesn
### a) the setting has no scope
`package.json`, around line 243:
```json
"microcks.cliPath": {
"type": "string",
"default": "",
"description": "Path to a Microcks CLI executable. If empty, the extension uses its managed CLI when installed, then microcks on PATH."
}
```
No scope means VS Code treats it as window, and window scoped settings can be written by a folder's .vscode/settings.json. So the value isn't really coming from the user, it's coming from whoever wrote the repo.
Anything that resolves to an executable is normally declared machine or machine-overridable for this exact reason. git.path in the built-in git extension does it, so does python.defaultInterpreterPath.
Also noticed there's no capabilities.untrustedWorkspaces block anywhere in package.json, which matters for the mitigation part below.
Related: package.json also does not declare a capabilities.untrustedWorkspaces entry, so the extension has no documented trust posture and no reduced-functionality mode.
While looking at this I also found a couple of other things (optional checksum in the managed CLI installer, and some unescaped fields in the Inspector webview). Happy to file those separately if you'd prefer, or I can add them here, whatever's easier for you
Contributor guide
No contributing guide indexed for this repository
Research direction
Start with package.json around the microcks.cliPath setting and inspect the extension activation path that spawns the configured executable. Review how untrusted workspaces are represented in package.json and how the setting can come from .vscode/settings.json. Done means an untrusted repository cannot cause an executable to be spawned through this setting, with the extension's trust posture declared.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript, vscode
- Domain
- devtools, security
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100