3 ms·

it is interesting that most of the CVEs are "use after free". instead of being stuck in an endless cycle of detection and patching, maybe, it's time we consider

• deleted 5y ago
  [deleted]
• saagarjha 5y ago
  Ah, yes, I’m sure the Chrome team is entirely unfamiliar with ways to improve memory safety. Snark aside, every browser vendor is working on this, it’s just that migrating is nontrivial.
  • mcintyre1994 5y ago
    What approaches are being considered here out of interest? I’m only familiar with Firefox’s use of Rust, but haven’t heard anything about other browsers trying to use that particular approach.
    • erk__ 5y ago
      The edge team have talked about it a bit in the following blog posts: https://microsoftedge.github.io/edgevr/posts/Super-Duper-Secure-Mode/ https://microsoftedge.github.io/edgevr/posts/Super-Duper-Sec... https://microsoftedge.github.io/edgevr/posts/Introducing-Enhanced-Security-for-Microsoft-Edge/ https://microsoftedge.github.io/edgevr/posts/Introducing-Enh...
      • PoignardAzur 5y ago
        That's... wow. This is incredible. What they've found is that JIT can be disabled in most sites with no user-visible impact. This, combined with WebAssembly, is a game-changer in waiting for browser security.
    • _0w8t 5y ago
      The biggest coming change is raw_ptr wrapper to replace raw pointers stored in structs and classes. Presently in Chromium it is no-op, but soon will be replaced by a non-trivial implementation that will instantly crash on use-after-free.
      • a1a106ed5 5y ago
        The raw_ptr/BackupRefPtr/MiraclePtr [1] mitigation will change the security industry. It is quite a feat what Chromium is doing. [1] https://chromium.googlesource.com/chromium/src/+/ddc017f9569973a731a574be4199d8400616f5a5/base/memory/raw_ptr.md https://chromium.googlesource.com/chromium/src/+/ddc017f9569...