10 ms·

> Not much is known, at least publicly, at this stage about CVE-2022-1096 other than it is a "Type Confusion in V8." This refers to the JavaScript engine employ

by _Nat_ 5y ago

> Not much is known, at least publicly, at this stage about CVE-2022-1096 other than it is a "Type Confusion in V8." This refers to the JavaScript engine employed by Chrome. Is there a safer JavaScript engine folks can use without having to worry about this sorta thing? Even if it's slower, less compatible, more resource-intensive, etc.? I feel like, in most cases, I could make due with JavaScript being 10x or even 100x slower, taking up 10x the RAM, lacking some uncommon features, and so forth -- if it meant being able to enable it without needing to worry about new zero-days.

kerng 5y ago
Microsoft has added some mitigtions to Edge a few months ago as defense in depth - wondering now if this is actually exploitable on Edge or if their mitigations prevent it? Any Microsoft/Edge security people on here? Update: found the original blog from Microsoft, they call it Super Duper Secure Mode: https://microsoftedge.github.io/edgevr/posts/Super-Duper-Secure-Mode/ https://microsoftedge.github.io/edgevr/posts/Super-Duper-Sec...
Ourgon 5y ago
> I feel like, in most cases, I could make due with JavaScript being 10x or even 100x slower, taking up 10x the RAM, lacking some uncommon features, and so forth -- if it meant being able to enable it without needing to worry about new zero-days. Not on the "modern web" you wouldn't, even the current speedy versions of V8 and ${whatever}monkey now used by Firefox the thing often is brought to a crawl by the deluge of Javascript. Imagine your current browser, only 100 times slower and 10 times more memory-hungry. Nope, the solution lies in getting rid of most of the Javascript on most pages. uBlock and uMatrix can help a bit but the real solution lies with web developers. If and when that goal is achieved it would be possible to browse the web using a slow-but-'safe' browser. Some pages (e.g. SPAs) really depend on all that Javascript and as such won't be useable withour 'modern' JS engines but there is no reason for e.g. your bank or payment processor's pages to depend on near-native speed Javascript engines.
- bastawhiz 5y ago
  > it would be possible to browse the web using a slow-but-'safe' browser. Some pages (e.g. SPAs) really depend on all that Javascript and as such won't be useable withour 'modern' JS engines but there is no reason for e.g. your bank or payment processor's pages to depend on near-native speed Javascript engines. I don't plan on my bank trying to 0day my browser. If anything, I trust them not to do anything malicious more than the sites that actually need to go fast.
  - Ourgon 5y ago
    You don't seem to understand what I wrote so I'll explain it: - imagine a slow-but-secure browser, 10 to 100 times as slow and using 10 times as much memory as stated by the parent poster - imagine your bank and payment processor using a minimal amount of Javascript on their sites to make it possible to use that secure-but-slow browser without incurring too big a performance penalty Do you now see what I mean? It is not that your financial institutions would zero-day you, it is that you'd use the secure-but-slow browser (or browser mode) to access those sites. Secure, because you're dealing with financial data. Slow because that is what the parent poster stated as the price he'd be willing to pay for a secure browser. You can you your insecure-but-speedy browser to watch cat videos where the H4CkZ0Rz can try to zero-day you to their hearts content because that browser does not have access to sensitive data. You could try to watch those cat videos with the secure-but-slow browser but that'd transport you back to the late 90's with single-digit frame rates (cat slide shows?).
    - tedunangst 5y ago
      The dangerous assumption here is that whatever sandbox you put the bad browser in actually contains it.
      - d110af5ccf 5y ago
        Particularly given the Project Zero KVM vulnerability published a couple of days ago. It was suitable to achieve a full VM escape. https://googleprojectzero.blogspot.com/2021/06/an-epyc-escape-case-study-of-kvm.html https://googleprojectzero.blogspot.com/2021/06/an-epyc-escap...
gruez 5y ago
>Is there a safer JavaScript engine folks can use without having to worry about this sorta thing? Even if it's slower, less compatible, more resource-intensive, etc.? You can disable JIT in firefox[1], which makes it fall back to an interpreter. That should theoretically make it safer as there are less optimizations going on and less generated code being directly executed by the CPU. [1] https://github.com/arkenfox/user.js/blob/b4225baaf2f8d15f856efbaea7c936d218e5ed7d/user.js#L1057-L1064 https://github.com/arkenfox/user.js/blob/b4225baaf2f8d15f856...
- rurban 5y ago
  you can also install Fennec on Android, which has much more privacy extensions, and a better JavaScript engine (a Firefox fork). on the PC Firefox is good enough.
  - 28304283409234 5y ago
    And ublock.
- zamadatix 5y ago
  You can disable jit in Chromium browsers via flag as well. Chromium Edge has this exposed in the UI as "Super Duper Secure Mode". I'm not sure if there is a way to do this on Safari.
  - ______-_-______ 5y ago
    I found this comparison of JIT vs non-JIT. https://microsoftedge.github.io/edgevr/posts/Super-Duper-Secure-Mode/ https://microsoftedge.github.io/edgevr/posts/Super-Duper-Sec... If you take those charts at face value, they're pretty incredible. The JIT ends up worse than the interpreter for most (real-world non-synthetic) use cases for power usage, memory usage, and startup time. Page load time is a wash. And this is after Google has poured $billions into optimizing V8.
    - gnu8 5y ago
svenfaw 5y ago
For Windows, IE11/Trident. This may sound ridiculous, but if you think about it, it's still maintained security-wise (and will be forever, as per MS), and since its codebase has been frozen a few years ago, its attack surface can only shrink with time. So if you're OK with the limited compatibility, it might be worth considering.
- gruez 5y ago
  >it's still maintained security-wise (and will be forever, as per MS), Source? According to microsoft: >Please note that the Internet Explorer (IE) 11 desktop application will end support for certain operating systems starting June 15, 2022 >Customers are encouraged to move to Microsoft Edge with IE mode. IE mode enables backward compatibility and will be supported through at least 2029. Additionally, Microsoft will provide notice one year prior to retiring IE mode. Your best bet right now for IE 11 is an installation of windows server 2022, which contains IE 11 and will be supported till Oct 14, 2031. Still, it's unknown whether IE 11 would be supported by then.
  - zamadatix 5y ago
    A lot of confusion between various comments so far so this is my attempt to re-baseline: - Chakra is the JavaScript engine in I.E. 11 (and later forked for the old MS Edge), Trident (MSHTML) was the browser engine (forked into EdgeHTML for the old MS Edge). - The I.E. 11 desktop application is just that, the desktop application. It is not all of I.E. 11 or it's engines, the rest of which are still in Windows 11 even. - I.E. mode is the first party way to access the remaining portions of I.E. 11 via the current Chromium Edge, this is what allowed them to sunset the I.E. desktop application. All that said I don't particularly buy this as being particularly more secure. Sure, it's only getting security fixes but that doesn't inherently mean it is more secure or getting more security fixes than modern solutions. It could just be becoming an outdated security architecture that is only patched often enough to keep the minute userbase happy enough.
- asddubs 5y ago
  i think the problem with IE11 is going to be the rendering moreso than the javascript engine. it doesn't support css variables and only a custom version of the grid syntax, so sites are only going to get more broken
azornathogron 5y ago
If you're worried about browser vulnerabilities in the javascript engine, have you considered disabling javascript by default and enabling it per-site on just the sites that you trust?
- _Nat_ 5y ago
  Yup, that's the current strategy. However, I'd prefer to have a secure JavaScript-engine that could be kept on by default, then enable a fast JavaScript-engine on a per-site basis. For example, I have an exception on here for HackerNews to use JavaScript. But the JavaScript HackerNews uses is trivial; a naive JavaScript engine that's 1000x slower and uses 100x the RAM probably wouldn't even make an observable difference, would it? Except if it's secure, then I could've just had JavaScript on by default (without needing to add an exception), and then I wouldn't have to worry about stuff like if HackerNews gets compromised one day. A lot of sites seem to do really little things with JavaScript, but break if it's disabled -- some blog sites won't even load posts without JavaScript enabled. It'd be nice to just have a secure browser to view such things with.
flotzam 5y ago
Maybe JIT-less V8: https://v8.dev/blog/jitless https://v8.dev/blog/jitless
meibo 5y ago
What you're asking for will probably put you more at risk than V8 does: 1) JavaScript engines with any kind of usable performance are inherently complex 2) V8 is hardened, battle-tested and fuzzed/verified by the best engineers at Google and indepentently by third party researchers, since inception - the engine you will be using probably won't be All of this is really a side-effect of Chrome's popularity and Google's resources, even the CVE itself. You would be relying on security by obscurity(in which obscurity = no big userbase = not a high value target). Have a look at payouts for RCE-capable V8 bugs.
- _Nat_ 5y ago
  I'd prefer a [provably secure](https://en.wikipedia.org/wiki/Provable_security https://en.wikipedia.org/wiki/Provable_security ) JavaScript-engine as a default. Or, if provable-security would be a bit much for a near-term project, something more heavily based in a simple engine-design, without trying to optimize stuff and perhaps including seemingly-redundant run-time checks. Ya know, stuff like type-checking arguments, using stronger restrictions on async-calls to avoid potential race-conditions, more parameter-validation, relying on automatic-memory-management to avoid bugs, always bound-checking on array-accesses, always overflow-checking math, and so forth. In general, code that's designed to be simple and plainly correct, resisting the temptation to optimize. Don't get me wrong, I appreciate that a lot of security-folks do good work trying to help identify-and-patch vulnerabilities in V8/etc.. And I appreciate that that enables a balance between performance and security that might be right for some applications. However, there're a lot of cases where I'd prefer a heavier focus on security.
  - relaunched 5y ago
    I've been in the security field a while, what exactly do you mean by provably secure?
    - stjohnswarts 5y ago
      What he wants is basically impossible for software projects as big as v8 or chrome, but I guess one can dream :)
azornathogron 5y ago
There are certainly other javascript implementations. For example, here's one I stumbled upon recently that's written in plain Go: https://github.com/dop251/goja https://github.com/dop251/goja Of course, it won't help you since it's not built into a web browser.
paxys 5y ago
You are making the assumption that an engine with fewer optimizations that runs slower will be safer by default, but I fail to see the connection between the two.
- chlorion 5y ago
  According to this analysis from Mozilla, over half of "in the wild" exploited vulnerabilities in chrome use bugs in the javascript JIT compiler. https://docs.google.com/spreadsheets/d/1FslzTx4b7sKZK4BR-DpO45JZNB1QZF9wuijK3OxBwr0/edit#gid=865365202 https://docs.google.com/spreadsheets/d/1FslzTx4b7sKZK4BR-DpO... https://docs.google.com/spreadsheets/d/1FslzTx4b7sKZK4BR-DpO45JZNB1QZF9wuijK3OxBwr0/edit#gid=0 https://docs.google.com/spreadsheets/d/1FslzTx4b7sKZK4BR-DpO... (these links were found here https://microsoftedge.github.io/edgevr/posts/Super-Duper-Secure-Mode/ https://microsoftedge.github.io/edgevr/posts/Super-Duper-Sec...) So it does appear that there is a fairly heavy connection between the two things. I am not an expert in JITs or JIT related security issues, but from my understanding, since JITs get to bypass the normal W^X memory restrictions, it makes it a really nice target for exploits and RCE.
- _Nat_ 5y ago
  For a simple example, [integer-overflow attacks](https://www.sciencedirect.com/topics/computer-science/integer-overflow https://www.sciencedirect.com/topics/computer-science/intege... ) could be trivially prevented by always bounds-checking integers. For another simple example, [buffer-overflow attacks](https://en.wikipedia.org/wiki/Buffer_overflow#Exploitation https://en.wikipedia.org/wiki/Buffer_overflow#Exploitation ) could be trivially prevented through the same sorts of checks. A popular website for programmers, [StackOverflow](https://stackoverflow.com/ https://stackoverflow.com/ ), was named after this sort of thing. Then there're memory-management errors that could be prevented through automated-memory-management (e.g., [use-after-free](https://en.wikipedia.org/wiki/Dangling_pointer#Security_holes_involving_dangling_pointers https://en.wikipedia.org/wiki/Dangling_pointer#Security_hole... )), invalid-parameter exploits that could be prevented by parameter-validation, format-exploits that could be prevented by proper encoding (e.g., [SQL injection](https://en.wikipedia.org/wiki/SQL_injection https://en.wikipedia.org/wiki/SQL_injection )), etc.. Likewise, the current zero-day affecting Google's Chrome presumably could've been prevented with more robust type-checking on everything (assuming the bug is as-reported in the article). Such type-checking might be a bit slower, and possibly require a bit more RAM if objects weren't already carrying type-identifiers, but then no such zero-days, either. A specific optimization that might be faulted for this zero-day in Google's Chrome, etc., might be describable as [type erasure](https://en.wikipedia.org/wiki/Type_erasure https://en.wikipedia.org/wiki/Type_erasure ). Presumably this was done because carrying type-identifiers (basically a tag that says what type an object is) requires more RAM (to store the type-identifiers) and more computation (to check that type-identifiers are correct/etc.). However, other optimizations may've been factors in this zero-day too.
charcircuit 5y ago
Don't forget that there is a sandbox. Even if there is a vulnerability with V8 you need to pair it with a vulnerability with the sandbox to exploit the system.
lcall 5y ago
I like that in chrome one can turn off javascript and images by default, then re-enable it for select sites only, or leave a tab open to re-enable it temporarily only.

by _Nat_ 5y ago

kerng 5y ago

Microsoft has added some mitigtions to Edge a few months ago as defense in depth - wondering now if this is actually exploitable on Edge or if their mitigations prevent it? Any Microsoft/Edge security people on here? Update: found the original blog from Microsoft, they call it Super Duper Secure Mode: https://microsoftedge.github.io/edgevr/posts/Super-Duper-Secure-Mode/ https://microsoftedge.github.io/edgevr/posts/Super-Duper-Sec...

Ourgon 5y ago

> I feel like, in most cases, I could make due with JavaScript being 10x or even 100x slower, taking up 10x the RAM, lacking some uncommon features, and so forth -- if it meant being able to enable it without needing to worry about new zero-days. Not on the "modern web" you wouldn't, even the current speedy versions of V8 and ${whatever}monkey now used by Firefox the thing often is brought to a crawl by the deluge of Javascript. Imagine your current browser, only 100 times slower and 10 times more memory-hungry. Nope, the solution lies in getting rid of most of the Javascript on most pages. uBlock and uMatrix can help a bit but the real solution lies with web developers. If and when that goal is achieved it would be possible to browse the web using a slow-but-'safe' browser. Some pages (e.g. SPAs) really depend on all that Javascript and as such won't be useable withour 'modern' JS engines but there is no reason for e.g. your bank or payment processor's pages to depend on near-native speed Javascript engines.

bastawhiz 5y ago
> it would be possible to browse the web using a slow-but-'safe' browser. Some pages (e.g. SPAs) really depend on all that Javascript and as such won't be useable withour 'modern' JS engines but there is no reason for e.g. your bank or payment processor's pages to depend on near-native speed Javascript engines. I don't plan on my bank trying to 0day my browser. If anything, I trust them not to do anything malicious more than the sites that actually need to go fast.
- Ourgon 5y ago
  You don't seem to understand what I wrote so I'll explain it: - imagine a slow-but-secure browser, 10 to 100 times as slow and using 10 times as much memory as stated by the parent poster - imagine your bank and payment processor using a minimal amount of Javascript on their sites to make it possible to use that secure-but-slow browser without incurring too big a performance penalty Do you now see what I mean? It is not that your financial institutions would zero-day you, it is that you'd use the secure-but-slow browser (or browser mode) to access those sites. Secure, because you're dealing with financial data. Slow because that is what the parent poster stated as the price he'd be willing to pay for a secure browser. You can you your insecure-but-speedy browser to watch cat videos where the H4CkZ0Rz can try to zero-day you to their hearts content because that browser does not have access to sensitive data. You could try to watch those cat videos with the secure-but-slow browser but that'd transport you back to the late 90's with single-digit frame rates (cat slide shows?).
  - tedunangst 5y ago
    The dangerous assumption here is that whatever sandbox you put the bad browser in actually contains it.
    - d110af5ccf 5y ago
      Particularly given the Project Zero KVM vulnerability published a couple of days ago. It was suitable to achieve a full VM escape. https://googleprojectzero.blogspot.com/2021/06/an-epyc-escape-case-study-of-kvm.html https://googleprojectzero.blogspot.com/2021/06/an-epyc-escap...

gruez 5y ago

>Is there a safer JavaScript engine folks can use without having to worry about this sorta thing? Even if it's slower, less compatible, more resource-intensive, etc.? You can disable JIT in firefox[1], which makes it fall back to an interpreter. That should theoretically make it safer as there are less optimizations going on and less generated code being directly executed by the CPU. [1] https://github.com/arkenfox/user.js/blob/b4225baaf2f8d15f856efbaea7c936d218e5ed7d/user.js#L1057-L1064 https://github.com/arkenfox/user.js/blob/b4225baaf2f8d15f856...

rurban 5y ago
you can also install Fennec on Android, which has much more privacy extensions, and a better JavaScript engine (a Firefox fork). on the PC Firefox is good enough.
- 28304283409234 5y ago
  And ublock.
zamadatix 5y ago
You can disable jit in Chromium browsers via flag as well. Chromium Edge has this exposed in the UI as "Super Duper Secure Mode". I'm not sure if there is a way to do this on Safari.
- ______-_-______ 5y ago
  I found this comparison of JIT vs non-JIT. https://microsoftedge.github.io/edgevr/posts/Super-Duper-Secure-Mode/ https://microsoftedge.github.io/edgevr/posts/Super-Duper-Sec... If you take those charts at face value, they're pretty incredible. The JIT ends up worse than the interpreter for most (real-world non-synthetic) use cases for power usage, memory usage, and startup time. Page load time is a wash. And this is after Google has poured $billions into optimizing V8.
  - gnu8 5y ago

svenfaw 5y ago

For Windows, IE11/Trident. This may sound ridiculous, but if you think about it, it's still maintained security-wise (and will be forever, as per MS), and since its codebase has been frozen a few years ago, its attack surface can only shrink with time. So if you're OK with the limited compatibility, it might be worth considering.

gruez 5y ago
>it's still maintained security-wise (and will be forever, as per MS), Source? According to microsoft: >Please note that the Internet Explorer (IE) 11 desktop application will end support for certain operating systems starting June 15, 2022 >Customers are encouraged to move to Microsoft Edge with IE mode. IE mode enables backward compatibility and will be supported through at least 2029. Additionally, Microsoft will provide notice one year prior to retiring IE mode. Your best bet right now for IE 11 is an installation of windows server 2022, which contains IE 11 and will be supported till Oct 14, 2031. Still, it's unknown whether IE 11 would be supported by then.
- zamadatix 5y ago
  A lot of confusion between various comments so far so this is my attempt to re-baseline: - Chakra is the JavaScript engine in I.E. 11 (and later forked for the old MS Edge), Trident (MSHTML) was the browser engine (forked into EdgeHTML for the old MS Edge). - The I.E. 11 desktop application is just that, the desktop application. It is not all of I.E. 11 or it's engines, the rest of which are still in Windows 11 even. - I.E. mode is the first party way to access the remaining portions of I.E. 11 via the current Chromium Edge, this is what allowed them to sunset the I.E. desktop application. All that said I don't particularly buy this as being particularly more secure. Sure, it's only getting security fixes but that doesn't inherently mean it is more secure or getting more security fixes than modern solutions. It could just be becoming an outdated security architecture that is only patched often enough to keep the minute userbase happy enough.
asddubs 5y ago
i think the problem with IE11 is going to be the rendering moreso than the javascript engine. it doesn't support css variables and only a custom version of the grid syntax, so sites are only going to get more broken

azornathogron 5y ago

If you're worried about browser vulnerabilities in the javascript engine, have you considered disabling javascript by default and enabling it per-site on just the sites that you trust?

_Nat_ 5y ago
Yup, that's the current strategy. However, I'd prefer to have a secure JavaScript-engine that could be kept on by default, then enable a fast JavaScript-engine on a per-site basis. For example, I have an exception on here for HackerNews to use JavaScript. But the JavaScript HackerNews uses is trivial; a naive JavaScript engine that's 1000x slower and uses 100x the RAM probably wouldn't even make an observable difference, would it? Except if it's secure, then I could've just had JavaScript on by default (without needing to add an exception), and then I wouldn't have to worry about stuff like if HackerNews gets compromised one day. A lot of sites seem to do really little things with JavaScript, but break if it's disabled -- some blog sites won't even load posts without JavaScript enabled. It'd be nice to just have a secure browser to view such things with.

flotzam 5y ago

Maybe JIT-less V8: https://v8.dev/blog/jitless https://v8.dev/blog/jitless

meibo 5y ago

What you're asking for will probably put you more at risk than V8 does: 1) JavaScript engines with any kind of usable performance are inherently complex 2) V8 is hardened, battle-tested and fuzzed/verified by the best engineers at Google and indepentently by third party researchers, since inception - the engine you will be using probably won't be All of this is really a side-effect of Chrome's popularity and Google's resources, even the CVE itself. You would be relying on security by obscurity(in which obscurity = no big userbase = not a high value target). Have a look at payouts for RCE-capable V8 bugs.

_Nat_ 5y ago
I'd prefer a [provably secure](https://en.wikipedia.org/wiki/Provable_security https://en.wikipedia.org/wiki/Provable_security ) JavaScript-engine as a default. Or, if provable-security would be a bit much for a near-term project, something more heavily based in a simple engine-design, without trying to optimize stuff and perhaps including seemingly-redundant run-time checks. Ya know, stuff like type-checking arguments, using stronger restrictions on async-calls to avoid potential race-conditions, more parameter-validation, relying on automatic-memory-management to avoid bugs, always bound-checking on array-accesses, always overflow-checking math, and so forth. In general, code that's designed to be simple and plainly correct, resisting the temptation to optimize. Don't get me wrong, I appreciate that a lot of security-folks do good work trying to help identify-and-patch vulnerabilities in V8/etc.. And I appreciate that that enables a balance between performance and security that might be right for some applications. However, there're a lot of cases where I'd prefer a heavier focus on security.
- relaunched 5y ago
  I've been in the security field a while, what exactly do you mean by provably secure?
  - stjohnswarts 5y ago
    What he wants is basically impossible for software projects as big as v8 or chrome, but I guess one can dream :)

azornathogron 5y ago

There are certainly other javascript implementations. For example, here's one I stumbled upon recently that's written in plain Go: https://github.com/dop251/goja https://github.com/dop251/goja Of course, it won't help you since it's not built into a web browser.

paxys 5y ago

You are making the assumption that an engine with fewer optimizations that runs slower will be safer by default, but I fail to see the connection between the two.

chlorion 5y ago
According to this analysis from Mozilla, over half of "in the wild" exploited vulnerabilities in chrome use bugs in the javascript JIT compiler. https://docs.google.com/spreadsheets/d/1FslzTx4b7sKZK4BR-DpO45JZNB1QZF9wuijK3OxBwr0/edit#gid=865365202 https://docs.google.com/spreadsheets/d/1FslzTx4b7sKZK4BR-DpO... https://docs.google.com/spreadsheets/d/1FslzTx4b7sKZK4BR-DpO45JZNB1QZF9wuijK3OxBwr0/edit#gid=0 https://docs.google.com/spreadsheets/d/1FslzTx4b7sKZK4BR-DpO... (these links were found here https://microsoftedge.github.io/edgevr/posts/Super-Duper-Secure-Mode/ https://microsoftedge.github.io/edgevr/posts/Super-Duper-Sec...) So it does appear that there is a fairly heavy connection between the two things. I am not an expert in JITs or JIT related security issues, but from my understanding, since JITs get to bypass the normal W^X memory restrictions, it makes it a really nice target for exploits and RCE.
_Nat_ 5y ago
For a simple example, [integer-overflow attacks](https://www.sciencedirect.com/topics/computer-science/integer-overflow https://www.sciencedirect.com/topics/computer-science/intege... ) could be trivially prevented by always bounds-checking integers. For another simple example, [buffer-overflow attacks](https://en.wikipedia.org/wiki/Buffer_overflow#Exploitation https://en.wikipedia.org/wiki/Buffer_overflow#Exploitation ) could be trivially prevented through the same sorts of checks. A popular website for programmers, [StackOverflow](https://stackoverflow.com/ https://stackoverflow.com/ ), was named after this sort of thing. Then there're memory-management errors that could be prevented through automated-memory-management (e.g., [use-after-free](https://en.wikipedia.org/wiki/Dangling_pointer#Security_holes_involving_dangling_pointers https://en.wikipedia.org/wiki/Dangling_pointer#Security_hole... )), invalid-parameter exploits that could be prevented by parameter-validation, format-exploits that could be prevented by proper encoding (e.g., [SQL injection](https://en.wikipedia.org/wiki/SQL_injection https://en.wikipedia.org/wiki/SQL_injection )), etc.. Likewise, the current zero-day affecting Google's Chrome presumably could've been prevented with more robust type-checking on everything (assuming the bug is as-reported in the article). Such type-checking might be a bit slower, and possibly require a bit more RAM if objects weren't already carrying type-identifiers, but then no such zero-days, either. A specific optimization that might be faulted for this zero-day in Google's Chrome, etc., might be describable as [type erasure](https://en.wikipedia.org/wiki/Type_erasure https://en.wikipedia.org/wiki/Type_erasure ). Presumably this was done because carrying type-identifiers (basically a tag that says what type an object is) requires more RAM (to store the type-identifiers) and more computation (to check that type-identifiers are correct/etc.). However, other optimizations may've been factors in this zero-day too.

charcircuit 5y ago

Don't forget that there is a sandbox. Even if there is a vulnerability with V8 you need to pair it with a vulnerability with the sandbox to exploit the system.

lcall 5y ago

I like that in chrome one can turn off javascript and images by default, then re-enable it for select sites only, or leave a tab open to re-enable it temporarily only.