One of the things I noticed when getting this toy to work was that Emscripten &'s the values of function pointers in the function table. That actually made the exploit more effective since I could effectively concatenate the secret string. Is there a reason for doing this though? One approach to ASLR could be XOR'ing with a token, leaving any malicious value to likely read out of bounds.
On Sunday, April 24, 2016 at 3:43:12 PM UTC-7, Alon Zakai wrote: > > ASLR for function pointers is an interesting idea. Sounds easy to do, just > create a much larger function table than needed, and fill it with aborting > stubs, and randomize the location of the actual function pointers in there. > This would have some overhead, though. > > On Sun, Apr 24, 2016 at 3:33 PM, Charles Vaughn <[email protected] > <javascript:>> wrote: > >> 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]> 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] <javascript:>. >> 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.
