6 ms·

Why not a memory safe language, to avoid those 70% of CVEs? (67% of 0-days last year: https://news.ycombinator.com/item?id=31085539 https://news.ycombinator.co

Why not a memory safe language, to avoid those 70% of CVEs? (67% of 0-days last year: https://news.ycombinator.com/item?id=31085539 https://news.ycombinator.com/item?id=31085539)

infamouscow 4y ago
Because Ruby is already memory safe and JIT miscompilation is a logic bug.
- carlmr 4y ago
  How is JIT miscompilation or vulnerabilities in the JIT compiler not an issue?
  - infamouscow 4y ago
    A Ruby program can delete all of the files on a computer, insert arbitrary rows into a database, drop a table, send email with attachments, etc. Am I correct that you're concerned the Ruby JIT itself will have a security vulnerability in the act of JIT compiling Ruby code? This seems extremely myopic.
    - criticaltinker 4y ago
      JS engines have had many serious vulnerabilities in their JIT optimizers, it’s not myopic at all and is a well known technique in the industry. I agree that some folks aren’t executing untrusted ruby code so they wouldn’t have to worry about this - but how many PaaS/SaaS products out there are? Or how about third party dev tools that are blindly downloaded and executed on local workstations or CI pipelines?
      - infamouscow 4y ago
        > JS engines have had many serious vulnerabilities in their JIT optimizers, it’s not myopic at all and is a well known technique in the industry. HotSpot and V8 are both written in C++ and get more use than any other JIT on Earth. Can you provide a link to a CVE caused by JIT miscompilation and explain how Rust would have been able to prevent the bug in a way that C++ wouldn't? > I agree that some folks aren’t executing untrusted ruby code so they wouldn’t have to worry about this - but how many PaaS/SaaS products out there are? This is what Xen, KVM, and Hyper-V do. > Or how about third party dev tools that are blindly downloaded and executed on local workstations or CI pipelines? Are you suggesting a Ruby JIT shouldn't generate machine code that corresponds to the Ruby program, but somehow magically prevent stupid developers from doing stupid things?
    - bastawhiz 4y ago
      It's a bad look if a malicious HTTP request to your Rails app can trigger RCE on your server. It's not about running code that's malicious, it's about bad data triggering a code path in the VM that is able to change the function of the application.
      - infamouscow 4y ago
        What you're describing is a logic bug. JITs write instructions to memory in a manner that's only slightly different than writing bytes to a file. The generation of those instructions can either be correct or incorrect and happens regardless of programming language. A JIT written in Python is equally capable of generating bad code as a JIT written in C or Rust or Lisp. A perfect port of a buggy JIT written in language A will generate the same buggy code even after being ported to language B.
- pizza234 4y ago
  The fact that a language is memory safe doesn't imply that the underlying virtual machine/interpreter is. On the other hand, it's definitely true that the ASM generated is as unsafe as it gets, but the first point still stands. The memory unsafety of the VM is simply an additional attack vector.
- Tobu 4y ago
  Rust's type system is enough to get rid of memory safety and UB, but it does that by enforcing more invariants, invariants which you also use to encode properties you care about. 70% percent of vulnerabilities are memory unsafety which is impossible in safe Rust etc etc, but a better type system, a language that doesn't disclaim commonly found code as unsupported, more productive errors, lower cognitive load… also tends to help with the rest of the bugs.

Why not a memory safe language, to avoid those 70% of CVEs? (67% of 0-days last year: https://news.ycombinator.com/item?id=31085539 https://news.ycombinator.com/item?id=31085539)

infamouscow 4y ago

Because Ruby is already memory safe and JIT miscompilation is a logic bug.

carlmr 4y ago
How is JIT miscompilation or vulnerabilities in the JIT compiler not an issue?
- infamouscow 4y ago
  A Ruby program can delete all of the files on a computer, insert arbitrary rows into a database, drop a table, send email with attachments, etc. Am I correct that you're concerned the Ruby JIT itself will have a security vulnerability in the act of JIT compiling Ruby code? This seems extremely myopic.
  - criticaltinker 4y ago
    JS engines have had many serious vulnerabilities in their JIT optimizers, it’s not myopic at all and is a well known technique in the industry. I agree that some folks aren’t executing untrusted ruby code so they wouldn’t have to worry about this - but how many PaaS/SaaS products out there are? Or how about third party dev tools that are blindly downloaded and executed on local workstations or CI pipelines?
    - infamouscow 4y ago
      > JS engines have had many serious vulnerabilities in their JIT optimizers, it’s not myopic at all and is a well known technique in the industry. HotSpot and V8 are both written in C++ and get more use than any other JIT on Earth. Can you provide a link to a CVE caused by JIT miscompilation and explain how Rust would have been able to prevent the bug in a way that C++ wouldn't? > I agree that some folks aren’t executing untrusted ruby code so they wouldn’t have to worry about this - but how many PaaS/SaaS products out there are? This is what Xen, KVM, and Hyper-V do. > Or how about third party dev tools that are blindly downloaded and executed on local workstations or CI pipelines? Are you suggesting a Ruby JIT shouldn't generate machine code that corresponds to the Ruby program, but somehow magically prevent stupid developers from doing stupid things?
  - bastawhiz 4y ago
    It's a bad look if a malicious HTTP request to your Rails app can trigger RCE on your server. It's not about running code that's malicious, it's about bad data triggering a code path in the VM that is able to change the function of the application.
    - infamouscow 4y ago
      What you're describing is a logic bug. JITs write instructions to memory in a manner that's only slightly different than writing bytes to a file. The generation of those instructions can either be correct or incorrect and happens regardless of programming language. A JIT written in Python is equally capable of generating bad code as a JIT written in C or Rust or Lisp. A perfect port of a buggy JIT written in language A will generate the same buggy code even after being ported to language B.
pizza234 4y ago
The fact that a language is memory safe doesn't imply that the underlying virtual machine/interpreter is. On the other hand, it's definitely true that the ASM generated is as unsafe as it gets, but the first point still stands. The memory unsafety of the VM is simply an additional attack vector.
Tobu 4y ago
Rust's type system is enough to get rid of memory safety and UB, but it does that by enforcing more invariants, invariants which you also use to encode properties you care about. 70% percent of vulnerabilities are memory unsafety which is impossible in safe Rust etc etc, but a better type system, a language that doesn't disclaim commonly found code as unsupported, more productive errors, lower cognitive load… also tends to help with the rest of the bugs.