3 ms·
> A 30 second glance at the source code makes it looks like this exploit pivots to attacker-controlled memory on the heap, and spawns a thread using kernel32.dl
by ryuuchin 10y ago
> A 30 second glance at the source code makes it looks like this exploit pivots to attacker-controlled memory on the heap, and spawns a thread using kernel32.dll. As EMET has hardening against attacks like this, I am curious if this exploit works at all on EMET-enabled Windows systems.
EMET can be bypassed so it's no guarantee that it would stop the exploit (but it would probably stop THIS exploit). I don't know if some modification would be able to bypass EMET or other mitigations.
A better solution would be to run javascript in a sandbox (as is done in Chrome/Chromium based browser) which has a much higher barrier to exit.
- micaksica 10y ago> A better solution would be to run javascript in a sandbox (as is done in Chrome/Chromium based browser) which has a much higher barrier to exit. Sure, but we can't get TBB rewritten overnight to work instantly with Chromium, and I'm sure there'd be a lot of push back on that.
- splesjaz 10y agoWell yea but this isn't something that we discovered today it's been years sadly :(
- TD-Linux 10y agoAn easier solution would be to enable e10s. It should be on by default in the next ESR, and I know TBB has been working to make their patches compatible with it.
- gcp 10y agoNot just e10s, they also need to enable the sandboxing, i.e. it requires Firefox 50 at least. It should actually be easier for Tor to enable stricter sandboxing than in the default Firefox, though, as presumably they have to care less about compatibility.
- MikeHolman 10y agoI don't know much about EMET. How would they mitigate this? After all, it's obviously valid for a VM to call CreateThread.
- micaksica 10y agoEMET has mitigations against stack pivoting.