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.
You have a great point here though that if one is developing a site that accepts outside JS code and executes it, then content in asm.js modules are no more safe than other content in any other piece of handwritten JS on that site. If we do consider in the above code snippet that the handwritten JS is the unsafe attacker code, and asm.js side is the assumed "secure" content, then to pull the string topsecret, one does not need to call any function in the asm.js module, but one can directly scan the heap of the asm.js module by iterating through HEAP8, and search for any string data in it. (essentially doing https://en.wikipedia.org/wiki/Strings_(Unix)). This will find the characters of the variable topsecret quite easily. If you did want to hide a top secret value (the master 4K UHD Bluray encryption keys perhaps) in to the asm.js heap, I would recommend storing it in individual bytes across multiple functions as local data, so that it does not end up in the heap as contiguous memory. This would give at least some obfuscation so that the attacker should likely execute code through to identify where the key is scattered to, unless they can pinpoint the location appropriately where it is assembled together. Even though it is an obfuscation step, it improves the attacker challenge from being able to print out the contents of a typed array to needing to be able to reverse engineer minified asm.js code, which is a good step up in the required effort level. This is parallel to native programs, where the strings tool can easily scan through the data section of any plain sight values. Cheers, Jukka 2016-04-23 1:31 GMT+03:00 Charles Vaughn <[email protected]>: > First of all, let me preface this by saying the security of Emscripten > running in a modern browser is excellent, stack smashing and ROP are > totally mitigated by the fact that Emscripen runs on top of the JavaScript > VM. Emscripten, even with inline JavaScript is compatible with CSP, which > can further clamp down on attack surfaces. > > That being said, code written for Emscripten can harbor potential security > issues. The source code for the toy is here: > > https://gist.github.com/hackcasual/413277eb8f2c19c5b3e6bac0303b083c > > The ordinary flow of the program is a user's name and password is loaded > into a buffer, then handed off to one of a few possible login methods. > There is a function of interest "send_ajax_request", but it is not a > candidate for a login handler. > > Here is a fiddle showing the vulnerability being exploited. > > https://jsfiddle.net/qx2mmdyz > > By overflowing the buffer, the exploit changes the function pointer to > "send_ajax_request", as well as pulling in the secret token. The > effectiveness of this type of attack is limited in Emscripten by needing to > replace a function pointer with one of the exact same signature. > > Hopefully this is an interesting PoC. I'd be interested to hear about > other potential interesting vulnerable coding patterns. > > -- > 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.
