[wasm] Illegal reuse of contexts |
||||||||||
Issue descriptionWe bake in the context in several location in wasm code: 1) boxing/unboxing in WASM_TO_JS and JS_TO_WASM 2) Throwing in stack checks 3) Throwing for traps (1) is no issue since code for these stubs is recompiled on every instantiation. For (2) and (3) the context is baked into the code of actual wasm functions, and is reused when instantiated in different contexts (via compilation cache for asm.js function, maybe also after deserialization). This gives access to foreign contexts. We currently see two options to fix this: 1) Patch references to the context in all code objects during instantiation. 2) Don't directly include in the context in wasm code, instead call to stubs for throwing errors / triggering stack check errors. Solution (2) has two advantages: 1) If we just recompile those stubs at instantiation, we never have to patch contexts anywhere. 2) We probably also reduce code size, since runtime calls are quite long (around 20 bytes on x64, where a raw call is just 5 bytes).
,
Dec 20 2016
clemensh can you help us triage this bug? - is wasm enabled by default on any chrome channel and if so, which ones? Can this issue be triggered from the web or does it require local access? Do you know who could look at this? Do you know what an attacker would be able to do with "foreign contexts" - is this just an infoleak or would it allow arbitrary code execution?
,
Dec 21 2016
This happens due to caching of asm.js code. What happens is that V8 keeps a shared function info cache which is isolate-wide. When we compile asm.js code, we store a stub and asm-wasm data on the module function of the asm.js code. That asm-wasm data has a compiled WebAssembly module. That WebAssembly module has code objects that embed the context corresponding to the context when the asm.js module was first verified and compiled. That means that subsequent invocations of the module from other contexts could, e.g. call a WASM function that throws an exception, giving the other context access to an WebAssembly.RuntimeError object from the original context; that's bad. We should fix this by including the context in the WasmCompiledModule (soon to be called WasmSpecializedCode) and patching the context for each new instantiation of the WASM module.
,
Dec 28 2016
,
Dec 28 2016
,
Dec 28 2016
,
Dec 29 2016
titzer@: Are you okay to own this, or else assign it to a better owner?
,
Jan 4 2017
titzer: Uh oh! This issue still open and hasn't been updated in the last 14 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers? If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one? If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started. Thanks for your time! To disable nags, add the Disable-Nags label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jan 12 2017
,
Jan 12 2017
The following revision refers to this bug: https://chromium.googlesource.com/v8/v8.git/+/ddbfbefc0b6482399121ac4afa41d8784d868332 commit ddbfbefc0b6482399121ac4afa41d8784d868332 Author: clemensh <clemensh@chromium.org> Date: Thu Jan 12 18:30:17 2017 [wasm] Patch the native context embedded in compiled code R=titzer@chromium.org BUG= chromium:673297 Review-Url: https://codereview.chromium.org/2623203003 Cr-Commit-Position: refs/heads/master@{#42282} [modify] https://crrev.com/ddbfbefc0b6482399121ac4afa41d8784d868332/src/wasm/wasm-module.cc [add] https://crrev.com/ddbfbefc0b6482399121ac4afa41d8784d868332/test/mjsunit/regress/regress-673297.js [modify] https://crrev.com/ddbfbefc0b6482399121ac4afa41d8784d868332/test/mjsunit/wasm/asm-wasm-stack.js
,
Jan 12 2017
,
Jan 13 2017
,
Jan 24 2017
,
Apr 21 2017
This bug has been closed for more than 14 weeks. Removing security view restrictions. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot |
||||||||||
►
Sign in to add a comment |
||||||||||
Comment 1 by clemensh@chromium.org
, Dec 12 2016Repro (execute with --validate-asm --stress-opt): function generateAsmJs() { 'use asm'; function fun() { fun(); } return fun; } assertThrows(generateAsmJs(), RangeError); Symptom: Throws RangeError from wrong context, therefore the check in assertThrows fails.