Not sure if it opens up that much on them as far as their security processors go. Modern consoles already treat DRAM as completely untrusted (an attacker could just sit on the DRAM bus and sniff/issue requests there).
The Xbox One for example encrypts all the DRAM it uses after it gets out of the main CPU die. See this part of Tony Chen's presentation https://youtu.be/U7VwtOrwceo?t=956
In the README it talks about accessing and modifying the code of the Platform Security Processor including accessing the keys, how is what is on an Xbox different?
The Xbox does not use AMD's Platform Security Processor, they have their own custom controller on die with Microsoft hardware and their own custom BootROM. This custom security processor actually has its own bit of RAM entirely in the die and doesn't even go out to the DRAM at all.
But the million dollar question is, do they rotate the IV per block or do they opt for speed as AMD and Intel both did by deriving it from the address and thus are vulnerable to someone sniffing the bus? (Note that older Intel server hardware wasn't vulnerable in this way but tracking IVs slowed everything down so they did away with it.)
wouldn't request after DRAM controller be unencrypted ? Would need to have different key per memory type and even then you could do some damage as realistically it won't have number of keys equal to running processes
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...
I'm gonna have to file the bug without a minimal reproduction case. The issue seems to be those try_table blocks getting nondeterministically reordered at link time (is it using machine pointers for iteration order?). Sadly I'm observing this with a local checkout of binaryen, so it may take a while for you to find the minimal reproduction case.
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.
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.
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.
The Xbox One for example encrypts all the DRAM it uses after it gets out of the main CPU die. See this part of Tony Chen's presentation https://youtu.be/U7VwtOrwceo?t=956
Also see this bit on the Apple Secure Enclave in the "Memory Protection Engine" section which also explains how they encrypt stuff stored in DRAM: https://support.apple.com/guide/security/the-secure-enclave-...