If you feel like increasing your power as per your post, this is a somewhat decent first LLVM issue, take a look at WebAssemblyCFGStackify.cpp :)

llvm/test/CodeGen/WebAssembly/cfg-stackify-eh.ll and friends are existing tests that you can kinda mangle if you want to get a good reproducer.

Also take a look at https://discourse.llvm.org/t/reverse-iteration-bots/72224

Otherwise, happy to put my reproducer/patch on the bug after you file it!

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.

Not sure if it's a stated goal somewhere official but there's been plenty of fixes of the years moving stuff to be deterministic, e.g https://github.com/llvm/llvm-project/commit/cdbde3aacc1260a7...

The internal programming guide also says which collections to use for deterministic iteration order: https://llvm.org/docs/ProgrammersManual.html#llvm-adt-setvec...

So definitely a bug here.

The PS5 also runs apps (games/browser) under a hypervisor. There was a hypervisor escape though coupled with webkit as an entrypoint:

* https://ps5dev.github.io/ps5-wiki/hypervisor

* https://github.com/PS5Dev/Byepervisor

* https://github.com/PS5Dev/PS5-UMTX-Jailbreak/blob/main/READM...

heh, a friend actually pointed out a typo on a first draft and said "maybe you shouldn't fix it to show it's not LLM written".

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.

You cannot, it doesn't go through the regular OAuth flow. GitHub just automatically grants it a token.

Oh, i see thanks for the reply.

1 and 2 are correct, take a look at the PoC repo here: https://github.com/ammaraskar/github-dev-token-steal-poc/tre...

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.

Thank you, that's a very kind comment.

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.

> instead of clout

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.

That’s most of the why it’s tough to be upset when people just release 0-days on Twitter - especially for big firms.

It definitely reminds me of the stereotypes of big business types stepping on the little guys to climb the ladder.

I hope you get credit where credit is due in future endeavors.