Brion does a better job than I did conveying what I was looking at. This is about what a malicious input attack would look like on Emscripten. This particular is interesting since it shows how, in the right circumstances, an attacker can redirect control flow, though in a greatly restricted way compared to C/C++ running on a native machine. It would be interesting to look into something ASLR like for function pointers, though not sure how that would look.
On Sunday, April 24, 2016 at 2:35:48 AM UTC-7, Brion Vibber wrote: > > On Sunday, April 24, 2016, juj j <[email protected] <javascript:>> wrote: > >> Right, agreed, there is no security that asm.js offers here, and it is >> not any kind of goal of asm.js either. Users can tamper with their asm.js >> pages just fine if they want, like they can tamper with the handwritten JS >> pages they are visiting. >> > > This sort of thing can often be triggered from off-site web pages by > injecting input data via the URL, or through a believed to be secure iframe > postMessage API. Or by submitting data from one user to the application's > server, that is then shown to another user and run through the asm.js'd > code. > > Compare with standard XSS and CSRF vulnerabilities on the web; I would > consider this a related class of attack vectors. > > >> In the first message, I read the word "vulnerability" from the >> perspective of "browser vulnerability", and wanted to point out that asm.js >> does not have any specialties there. >> > > Yeah, the vulnerability is in the JS code, doesn't allow escaping the > browser's JS sandboxing. > > But the addition of C-based code into the JS code on a site does add > buffer overflow and related classes of errors that handwritten JS doesn't > usually have, and this example confirms they can be used to overwrite > function pointers in a potentially exploitable way against an application. > So it's something developers ought to consider in their security planning > and reviews, when writing or selecting C/C++ code to use via emscripten. > > Lack of address space randomization in the function pointer table also > means that an attacker can hardcode the target function pointer override in > their attack data, whereas attacking native code you might need to scan or > make multiple attempts. > > -- brion > > > >> 2016-04-24 11:20 GMT+03:00 Brion Vibber <[email protected]>: >> >>> On Sunday, April 24, 2016, juj j <[email protected]> wrote: >>> >>>> Indeed it is possible to nuke the function pointer table, but I don't >>>> think this is a vulnerability. In order to be a security issue, it would >>>> mean there would have to be some kind of escalation to occur. Handwritten >>>> JavaScript and asm.js C/C++ code should be viewed at the same security >>>> level or arena in a sense, since the developer is in control of the both. >>>> Asm.js does not propose a new security layer where handwritten JS outside >>>> to the asm.js module could be allowed to considered untrusted, but the >>>> usual web security imposed via domain rules applies here. >>>> >>> >>> There's no need for untrusted handwritten js here; you just need some >>> function in the asm.js module that you can call that does something you as >>> an attacker want and has the same call signature as the function pointer >>> that gets overwritten. >>> >>> The rough equivalent in native code is things like forcing a call or >>> return into another part of the executable or standard library that happens >>> to do something the attacker finds useful. >>> >>> Getting something useful out of the exploit might well piggyback on some >>> further vector once you're inside, such as producing malicious html that >>> later gets inserted into the document by code outside the emscripten module >>> (or could you manage to call something more directly via embind::val etc?) >>> -- but that's not code the attacker has to inject previously ... If they >>> could do that, no need to bother with buffer overflows in the asm.js. >>> >>> -- brion >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "emscripten-discuss" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "emscripten-discuss" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> > -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
