Of note, even that 97% of original code that is now "safe in the rust sense" could violate invariants through safe blocks that cause memory-safety issues. I can't say exactly how the LLM-ported Rust code made use of unsafe but see https://www.ralfj.de/blog/2016/01/09/the-scope-of-unsafe.htm...
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.
It's not just based on that, if you read the linked report from 2023 (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.
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).
That's probably one of the fastest responses I've seen from a vendor.
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.
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.
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'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.
Also, the Github enterprise code is "obfuscated" but it uses a trivially reversible method just meant to be a minor roadblock. After you get past that you get the full ruby source code, no minification or anything.
For a while the key was literally:
> This obfuscation is intended to discourage GitHub Enterprise customers from making modifications to the VM. We know this 'encryption' is easily broken.
Could you elaborate on this bit on why Github's secret masking doesn't work here:
> GitHub Actions' built-in secret masker matches registered values as exact substrings. When the exception message is rendered by Symfony Console it may wrap, embed in In BaseIO.php line N: framing, or interleave with ANSI control sequences. So the masker does not redact, and the plaintext token reaches the log.
What does this log rendering look like such that the token from that code snippet becomes interleaved enough to not be a substring match?
I'm not familiar with composer/Symfony but I would expect something like:
I haven't trudged through Chromium's commit statistics but has Microsoft been upstreaming many contributions? I'm skeptical that they are ready to take on the full brunt of Chromium maintenance on a whim, it would take a decent while to build up the teams and expertise for it.
Glad this feature is built into most modern operating systems these days.
For MacOS (Sequoia+) you can just forget the network and reconnect to get a new MAC address [1].
Android's documentation for if it decides to generate a new address per connection is a little vague [2], but I'm guessing forgetting and reconnecting works as well, you may also need to flip the "Wi-Fi non-persistent MAC randomization" bit in developer settings.
On Windows, flipping the "Random hardware address" switch seems to cause it to generate a new seed/address for me.