5 ms·

> But it is a language that will possibly give Mozilla the world's most secure web browser by a significant margin if they succeed in writing the most bug prone

> But it is a language that will possibly give Mozilla the world's most secure web browser by a significant margin if they succeed in writing the most bug prone components in Rust. A memory safe language alone isn't enough. Look at Java. Isn't that supposed to be a memory safe language? And yet it's constantly got security issues.

pcwalton 12y ago
> A memory safe language alone isn't enough. Look at Java. Isn't that supposed to be a memory safe language? And yet it's constantly got security issues. Sure. Nobody is claiming (or should claim) that memory safety is a solution to all security problems. That's independent of the claim that memory safety is an effective defense against common vulnerabilities in C and C++ programs.
MichaelGG 12y ago
I don't think Java proves your point. The major impacting bugs in Java itself tend to surround the idea of running arbitrary code with a complicated sandbox. The embedded CLR-in-the-browser also suffered many (in fact, out of all the severe MS CVEs that aren't memory related, most were sandbox escapes). So that's probably more of an indication not to build complicated sandboxes that rely on fine-grained classloading permissions systems. The other Java bugs are ones that'd plague any language: SQL injection, rules-engines-gone-wild, etc.
- mike_hearn 12y ago
  > So that's probably more of an indication not to build complicated sandboxes that rely on fine-grained classloading permissions systems Web sandboxes are full of holes too. That's why modern browsers have sandboxes within sandboxes. I don't think an HTML5 sandbox is less complicated than the JVM sandbox.
mbrubeck 12y ago
A large number of the Java CVEs you're thinking of are bugs in the Oracle JVM, meaning they are bugs in C++ code, which is not in a memory-safe language.
- tedunangst 12y ago
  Actually, I think a lot of the CVEs are in the shipped java classes. But it's sometimes hard to tell, with such fine descriptions as Unspecified vulnerability in Oracle Java SE 6u85, 7u72, and 8u25 allows local users to affect confidentiality, integrity, and availability via unknown vectors related to Deployment.
  - mbrubeck 12y ago
    Yeah, I started to look through OpenJDK commit history to get a better sense of the proportions here, but I haven't gotten far enough to have any useful data.
pserwylo 12y ago
I would suggest that the security issues in Java are due to bugs in the various JVM implementations, which are likely written in C, right? Not to say that Java is going to eliminate all bugs. However, it should eliminate all bugs to do with, e.g., reading/writing out of the bounds of an array and resulting in RCE due to bugs introduced in the application code. Reading/writing out of the bounds of an array will still be a bug, but not one that allows arbitrary code execution (at least not in the same way as it may for a language like C.
- MichaelGG 12y ago
  And many of them, from a quick glance, are actually due to complicated sandboxing policies. That is, RCE was an explicit feature, but they found it hard to get right. In fact, one of the first real security holes I've ever found was in 1.0 version of the CLR. You could load a function pointer to an un-JIT'd function, then later on use that to safely jump to other code. This is technically a RCE, but the user has to be executing your code first anyways. That is, if the CLR and Java didn't set out to run "partially trusted" code with no help from the OS, these wouldn't have been problems at all. Other languages like C, Ruby, etc. simply don't have this "partially trusted" concept so there's nothing to attack. (Well I guess things like Native Client or VMware qualify, but they're at a better abstraction later than JVM or CLR permissions.)
  - seanmcdirmid 12y ago
    When I was an undergrad at UW, I engineered a vacuum bug that took advantage of a JDK1.1 bug in constant pool verification to suck out the user's in memory environment configuration (so like PATH variables and such). http://www.cs.cornell.edu/People/egs/kimera/flaws/vacuum/ http://www.cs.cornell.edu/People/egs/kimera/flaws/vacuum/ But most security holes these days are not flaws in the JVM/CLR, but logical errors made in the application; e.g. allocate a buffer and reuse it, this says nothing about memory safety at the VM level at all! And at that, no one really trusts JVM security anymore, preferring to sandbox the entire operating environment in a heavyweight or lightweight VM.
    - 12y ago
lmm 12y ago
> A memory safe language alone isn't enough. Look at Java. Isn't that supposed to be a memory safe language? And yet it's constantly got security issues. Has it? I can't remember the last time I saw a security advisory for Tomcat or Jetty (there are some but they're rare), in stark contrast to Apache or Nginx.

pcwalton 12y ago

> A memory safe language alone isn't enough. Look at Java. Isn't that supposed to be a memory safe language? And yet it's constantly got security issues. Sure. Nobody is claiming (or should claim) that memory safety is a solution to all security problems. That's independent of the claim that memory safety is an effective defense against common vulnerabilities in C and C++ programs.

MichaelGG 12y ago

I don't think Java proves your point. The major impacting bugs in Java itself tend to surround the idea of running arbitrary code with a complicated sandbox. The embedded CLR-in-the-browser also suffered many (in fact, out of all the severe MS CVEs that aren't memory related, most were sandbox escapes). So that's probably more of an indication not to build complicated sandboxes that rely on fine-grained classloading permissions systems. The other Java bugs are ones that'd plague any language: SQL injection, rules-engines-gone-wild, etc.

mike_hearn 12y ago
> So that's probably more of an indication not to build complicated sandboxes that rely on fine-grained classloading permissions systems Web sandboxes are full of holes too. That's why modern browsers have sandboxes within sandboxes. I don't think an HTML5 sandbox is less complicated than the JVM sandbox.

mbrubeck 12y ago

A large number of the Java CVEs you're thinking of are bugs in the Oracle JVM, meaning they are bugs in C++ code, which is not in a memory-safe language.

tedunangst 12y ago
Actually, I think a lot of the CVEs are in the shipped java classes. But it's sometimes hard to tell, with such fine descriptions as Unspecified vulnerability in Oracle Java SE 6u85, 7u72, and 8u25 allows local users to affect confidentiality, integrity, and availability via unknown vectors related to Deployment.
- mbrubeck 12y ago
  Yeah, I started to look through OpenJDK commit history to get a better sense of the proportions here, but I haven't gotten far enough to have any useful data.

pserwylo 12y ago

I would suggest that the security issues in Java are due to bugs in the various JVM implementations, which are likely written in C, right? Not to say that Java is going to eliminate all bugs. However, it should eliminate all bugs to do with, e.g., reading/writing out of the bounds of an array and resulting in RCE due to bugs introduced in the application code. Reading/writing out of the bounds of an array will still be a bug, but not one that allows arbitrary code execution (at least not in the same way as it may for a language like C.

MichaelGG 12y ago
And many of them, from a quick glance, are actually due to complicated sandboxing policies. That is, RCE was an explicit feature, but they found it hard to get right. In fact, one of the first real security holes I've ever found was in 1.0 version of the CLR. You could load a function pointer to an un-JIT'd function, then later on use that to safely jump to other code. This is technically a RCE, but the user has to be executing your code first anyways. That is, if the CLR and Java didn't set out to run "partially trusted" code with no help from the OS, these wouldn't have been problems at all. Other languages like C, Ruby, etc. simply don't have this "partially trusted" concept so there's nothing to attack. (Well I guess things like Native Client or VMware qualify, but they're at a better abstraction later than JVM or CLR permissions.)
- seanmcdirmid 12y ago
  When I was an undergrad at UW, I engineered a vacuum bug that took advantage of a JDK1.1 bug in constant pool verification to suck out the user's in memory environment configuration (so like PATH variables and such). http://www.cs.cornell.edu/People/egs/kimera/flaws/vacuum/ http://www.cs.cornell.edu/People/egs/kimera/flaws/vacuum/ But most security holes these days are not flaws in the JVM/CLR, but logical errors made in the application; e.g. allocate a buffer and reuse it, this says nothing about memory safety at the VM level at all! And at that, no one really trusts JVM security anymore, preferring to sandbox the entire operating environment in a heavyweight or lightweight VM.
  - 12y ago

lmm 12y ago

> A memory safe language alone isn't enough. Look at Java. Isn't that supposed to be a memory safe language? And yet it's constantly got security issues. Has it? I can't remember the last time I saw a security advisory for Tomcat or Jetty (there are some but they're rare), in stark contrast to Apache or Nginx.