3 ms·
> No bounds checking exists to make sure that the slots_ array is large enough to accommodate the specified index, because the UnsafeSetReservedSlot function as
by gpm 4y ago
> No bounds checking exists to make sure that the slots_ array is large enough to accommodate the specified index, because the UnsafeSetReservedSlot function assumes, as the name implies, that the caller will pass only suitable objects.
So this is actually exploiting C++ code that you would be unable to write in javascript/the safe subset of rust because they both require bounds checks.
> 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.
I mean, no one thought replacing some code with memory safe languages would eliminate memory safety issues in the remaining code written in memory-unsafe language. That makes no sense.
This is an interesting blogpost, the initial vulnerability (playing with javascript prototypes to get access to APIs you shouldn't have) even lives up to the "non-memory safety security bug" description. But the framing around memory safety is pretty ridiculous.
- sfink 4y agoYeah, I would argue that SpiderMonkey's self-hosted JS is neither JavaScript nor memory safe. It's a different language that reuses much of the JavaScript implementation. It doesn't support either of the statements `foo()` or `obj.prop = 3`. It does support a whole bunch of memory-unsafe operations that JavaScript does not have, through intrinsics. So if you take a language and remove some stuff and add some other stuff, you end up with neither a subset nor a superset—it's just a different (but related) language. (I work on SpiderMonkey. I've even suggested that we more explicitly recognize that self-hosted JS is not JS, and compile it differently such that you could add back some of the missing features with different, safer semantics. But it's not really my area and there's a large design space to choose the right language from, so I'm not claiming that that's the right thing to do.)
- kevincox 4y agoI would even go a step further and say that there was no memory safety bug in the code. The attacker-provided exploit contained the memory safety issue by calling potentially unsafe APIs "incorrectly".