3 ms·
That's fair and I now know more. I'm not convinced that this is the biggest issue with JS engines/browsers, but I certainly have more evidence against me :). I
by Quekid5 7y ago
That's fair and I now know more. I'm not convinced that this is the biggest issue with JS engines/browsers, but I certainly have more evidence against me :).
It's interesting how many of those are labeled OOB. Does that mean that we're talking JIT flaws that allow OOB access to memory? Is it's actually tricking the JIT itself into allowing OOB access, or is it actually OOB'ing the JIT?
I wonder what the performance impact of all JIT code being forced to do bounds-checking would be...
- saagarjha 7y ago> Is it's actually tricking the JIT itself into allowing OOB access, or is it actually OOB'ing the JIT? What's the difference between the two? Many JavaScript exploits abuse the interaction between strange features of the language to get around bounds checks (often, because a length was checked but invalidated by later JavaScript executing in an unexpected way, or a bound not forseen as needing a check) leading to an out-of-bounds. And I'm assuming many of these are heap corruptions where someone messes with a length that lets them get out-of-bounds.
- deleted 7y ago[deleted]
- Quekid5 7y agoIt's not much of a difference in terms of consequences, but always-on bounds checking could alleviate OOB'ing the JIT at least.