Critical GitHub Copilot Vulnerability Leaks Private Source Code
89 points by saturnyx
89 points by saturnyx
Given that they only disabled image embedding, it feels like this in general is still wildly exploitable in other ways. At least it seems it doesn't affect users that don't use Copilot.
I spent a long time thinking about this problem before this crazy idea struck me. If I create a dictionary of all letters and symbols in the alphabet, pre-generate their corresponding Camo URLs, embed this dictionary into the injected prompt, and then ask Copilot to play a “small game” by rendering the content I want to leak as “ASCII art” composed entirely of images, will Copilot inject valid Camo images that the browser will render by their order? Yes, it will.
That is absolutely genius. So elegant!
The result: Stealing zero days from private repositories
I understood "zero day" to mean a vulnerability that hasn't been reported, yet. Does it mean something else in this sentence?
I think what the author means is that you can exfiltrate private code and look for vulnerabilities that nobody else has access to
The idea seems to be that there's a zero-day vulnerability reported in a private issue (which is not unusual) and this exploit is able to exfiltrate the issue description without having direct access to it, just by someone with access to the issue asking Copilot to summarize a malicious PR to a different public repo.
Why allow HTML comments in the comments at all?
It's a useful feature for some automations. Consider a PR review feature that deploys the code in the PR to hosting somewhere and adds a link in the description that says "Preview URL: https://..." - it's useful to wrap that in <!-- start preview -->...<!-- end preview --> comments so when the system deploys updates it can replace that block of content in the PR reliably.
In addition to the other comments: HTML tags are allowed in Markdown. See https://github.github.com/gfm/#html-blocks.
I often see them used in PR templates with instructions for filling in certain sections. It’s cute that the help text doesn’t render, but not really necessary IMO. Just make the help text content that the author deletes.
GitHub's own GitHub Apps framework uses this feature as a janky key-value store: https://probot.github.io/docs/extensions/#metadata
This is obviously hacky, but super super nice for a subset of apps because it means that you can completely eliminate persistent state handling from the application code. That's now GitHub's problem.
GitHub doesn't care so it's your problem anyway (and desync happens), but at least you have much better chances that updates to the content of the comment and to the metadata happen or fail together.