> Although his exploit used some memory corruptions, the vulnerable code was written in a memory-safe programming language: JavaScript! That's not really anyt

> Although his exploit used some memory corruptions, the vulnerable code was written in a memory-safe programming language: JavaScript! That's not really anything new. There was what amounts to an "ACL" issue at the JS level, which exposed the vulnerable C++ code. Sort of like if you have a vulnerable web app behind an improperly configured firewall - you wouldn't say you exploited the firewall though if you owned the service behind it, although you could say that you exploited both. VMs using unsafe languages have always had this problem. QEMU has this, V8, JVM, Flash, etc. > This post looked at a great vulnerability demonstrating that even if you replace existing code with JavaScript, you could still be prone to memory corruption. Well, no one replaced anything with javascript. It's a javascript VM. If it were a C VM the issue wouldn't be any better or worse, "attacker is executing code in the VM" is the assumed situation. So yeah I think it's totally fine and good to say that VMs make for interesting exploit chains across languages and runtimes - that's for sure true and one of the biggest issues with implementing safe VMs (sharing memory across runtimes, needing to keep memory as RWX, all sorts of nutty stuff). But what we see here is exactly the same standard thing we always see - an unsafe C++ program did unsafe things with untrusted input.