4 ms·

I hope this works out. A memory safe browser would be a huge win for security.

• brabel 4y ago
  Are there many exploits caused by memory issues in Chromium?
  • staticassertion 4y ago
    Yes, I believe literally every single 'in the wild' exploit has abused memory unsafety, as well as hundreds of vulnerabilities every year.
    • brabel 4y ago
      That's strange... if they'd written the code in a memory safe language, say, Java... there wouldn't be any vulnerability? I don't know... I see plenty of vulnerabilities in the Java world, no memory unsafety needed.
      • UncleMeat 4y ago
        Vulns exist in Java applications. Logic bugs can open all sorts of doors to exploitation. But empirically we observe that a huge portion of real vulnerabilities in applications written in C or C++ are memory errors. We've spent decades trying to get people to write C and C++ applications without these errors and utterly failed. A browser written in a memory safe language won't be free from vulns but it will be free from a huge class of recurring and very serious vulns.
      • staticassertion 4y ago
        The question was if the exploits were due to memory safety. The answer is, yes, 100% of them are due to memory safety. As for Java, quite a lot of the exploits against it (when it was a browser plugin) were in fact memory safety issues in the VM. But more recently what we see are serialization issues, which Rust also does not have.
      • pornel 4y ago
        Yes, if they used Java then a whole class of use-after-free exploits wouldn't be possible. Security is not a binary yes/no. There are many many ways in which programs can be insecure. Eliminating one class of bugs helps reduce total amount of issues and their severity. It's like car crashes: cars with seatbelts, airbags, and auto-braking systems kill way fewer people than they used to, but are still deadly.
      • dgb23 4y ago
        A security related bug often comes down to violating the principle of least power either in a technical way by introducing a leak that can be exploited with crafted input, or via design, where a human participant is assumed to be trustworthy. I think wider memory safety, SQL injection and things like log4j are related to the former. Some aggregation of data that should be dumb and restricted is given too much trust, so data can be lifted to code and code is too powerful. In essence they are all similar, even though we don't use the same technical terms for each of them. And yes, if a given programming environment restricts a class of operations, it is given less power so the attack surface is qualitatively smaller. Languages that restrict memory management are an example. Another one would be file/disk access, network access and so on.
      • throwaway894345 4y ago
        Security isn't a binary, and the vulnerabilities that are possible in a memory safe language are a subset of those possible in a memory unsafe language. We want to minimize the number of possible vulnerabilities. Yes, the above is a bit oversimplified: most memory-safe languages have an "unsafe" escape hatch, so technically these vulnerabilities are possible; however, these escape hatches are rarely used, explicitly opted-into, and clearly demarcated in the source code such that the number of vulnerabilities in "memory safe" languages is far smaller than "memory unsafe" languages.
        • brabel 4y ago
          I was not the one claiming security is binary. The opposite of that (I happen to work in security)... people just casually claiming that 100% of the vulnerabilities in Chromium are due to memory unsafety are implicitly claiming that none of them were logic bugs and what follows is that had the same code been written in Java, Rust, even Python for that matter, none of those vulnerabilities would've been possible - which means there would be no vulnerabilities at all!? I would expect people commenting here to have basic understanding of propositional logic.
          • staticassertion 4y ago
            100% of exploited vulnerabilities leveraged memory unsafety. 70% of vulnerabilities discovered are from memory unsafety.
  • imron 4y ago
    About 70% of all exploits: https://www.chromium.org/Home/chromium-security/memory-safety/ https://www.chromium.org/Home/chromium-security/memory-safet...
    • staticassertion 4y ago
      Just to clarify, exploit generally refers to software that takes advantage of vulnerabilities, vulnerabilities are the flaws themselves. As in, one writes code to "exploit" a "vulnerability". 70% of all vulnerabilities reported to them are memory safety issues. To my knowledge, 100% of exploits against Chrome in the wild leverage memory unsafety.
      • imron 4y ago
        Good point!
      • selfmodruntime 4y ago
        How anyone can read a survey like this and still argue that the benefits of Rust (or any language with the ownership model) don't outweigh the risks / negative aspects is beyond me.
        • staticassertion 4y ago
          Most developers understand virtually nothing about security.
        • comment500 4y ago
          One caveat here is that many of the vulns used in the wild are in V8 and related to JIT code generation. Unfortunately rewriting in Rust can't really help with this.
          • staticassertion 4y ago
            Yes, that's a really good point. The vulnerabilities are across a number of components (skia, for example, is another big one) but memory safety in VMs is particularly tricky. Still, my personal, somewhat unfounded belief is that Rust has a lot of potential there.