3 ms·

Though I would love to agree with you, Java also promised to fully protect us from arbitrary code execution. In some ways even stronger than Rust. But as we all

by tinco 10y ago

Though I would love to agree with you, Java also promised to fully protect us from arbitrary code execution. In some ways even stronger than Rust. But as we all know Java has been riddled with code execution bugs. Now I wouldn't dare accuse Rust developers to be as terrible at writing secure code as the average K&R worshipper, and unlike the JVM most (all?) of Rust is actually written in Rust I hear, but I wouldn't flat out claim there won't ever be an arbitrary code execution vulnerability in a Rust project.

conradev 10y ago
I'm actually curious now – is it possible to deliberately introduce an RCE vulnerability into Rust code with `#![forbid(unsafe_code)]`? Has anyone done it?
- deleted 10y ago
  [deleted]
- pcwalton 10y ago
  Sure, that's easy: just write a Rust program that spawns a root shell connected to port 1337. This isn't a flippant response: I suspect most RCEs in Rust software are likely to be high-level vulnerabilities like that.
  - whyever 10y ago
    You can also use /proc to violate memory safety in safe rust.
    - tedunangst 10y ago
      http://marc.info/?l=full-disclosure&m=141272606521280&w=2 http://marc.info/?l=full-disclosure&m=141272606521280&w=2
    - duaneb 10y ago
      If you have access to /proc, it's not much of an rce threat.
- tinco 10y ago
  Well this particular project this comment thread is about does not actually implement any cryptographic operations, those are all done by libsodium[1] a project written in C. Imagine now it is possible to construct an argument to those libsodium functions that satisfies the constraints of the Rust wrappers, but still manages to crash libsodium and execute some part of the argument, which is not unheard of since libsodium is written in C and it operates on blobs of data. Now the only mistake the implementor of thrussh has to make is to allow for that input to be passed into the rust libsodium wrapper through the protocol implementation. [1] https://github.com/jedisct1/libsodium https://github.com/jedisct1/libsodium
duaneb 10y ago
> but I wouldn't flat out claim there won't ever be an arbitrary code execution vulnerability in a Rust project. If you note the OP, he expressed it in terms of "high confidence" not a "claim there won't ever be an arbitrary code execution vulnerability in a Rust project". Which would be absurd. And it's also as good as it gets: you can't avoid vulnerabilities.
pcwalton 10y ago
> But as we all know Java has been riddled with code execution bugs. Most of those are of the form "malicious code delivered as Java applet can break out of the JVM sandbox". That is, they crucially rely on running untrusted code. By contrast, the threat model here involves attackers subverting existing, trusted code. Memory safety holes in Rust overwhelmingly rely on bizarre carefully crafted code that nobody would accidentally write. There are some exceptions: Java is affected by serialization issues along the lines of the Rails YAML vulnerability, for instance. But most of those don't apply to Rust either for various reasons.
- tinco 10y ago
  True enough, definitely with untrusted code your surface is that much larger. What I remember from the few JVM bugs I looked at is that they were always at points where the JVM would call into the operating system or otherwise interact with native code. I would imagine Rust code might be vulnerable at those same points, though obviously much less easily.
  - teacup50 10y ago
    There are basically three major classes of Java code execution bugs: 1) Bugs in native code (generally image processing, compression, etc). This code tends to be derived from existing libraries, and so shares common vulnerabilities. 2) Bugs in sandboxing when running untrusted code. Java's sandbox model is fundamentally flawed and I don't believe it can ever be secured. 3) Executing untrusted external user input within the JVM context, e.g., by evaluating external data using your internal scripting language that has access to the JVM or relies on JVM sandboxing. Of those: 1) Not much you can do, but issues are relatively rare. 2) Can be avoided by not running untrusted code in a JVM-enforced sandbox (applets are dead, sorry). 3) You'll be fine if you steer clear of libraries that even go near eval() of untrusted user input. The culprits here are serial offenders due to architectural/design issues, and are easy to avoid (e.g. Apache Struts.)
- fpoling 10y ago
  Another source of Java bugs is improper input sanitation when untrusted input eventually feed into various interpreters like embedded JavaScript or SQL. That, of cause, can happen with any language, but at least with Rust it is much harder to accidentally call into some framework that exposes an interpreter capable of arbitrary code execution.

by tinco 10y ago

conradev 10y ago

I'm actually curious now – is it possible to deliberately introduce an RCE vulnerability into Rust code with `#![forbid(unsafe_code)]`? Has anyone done it?

deleted 10y ago
[deleted]
pcwalton 10y ago
Sure, that's easy: just write a Rust program that spawns a root shell connected to port 1337. This isn't a flippant response: I suspect most RCEs in Rust software are likely to be high-level vulnerabilities like that.
- whyever 10y ago
  You can also use /proc to violate memory safety in safe rust.
  - tedunangst 10y ago
    http://marc.info/?l=full-disclosure&m=141272606521280&w=2 http://marc.info/?l=full-disclosure&m=141272606521280&w=2
  - duaneb 10y ago
    If you have access to /proc, it's not much of an rce threat.
tinco 10y ago
Well this particular project this comment thread is about does not actually implement any cryptographic operations, those are all done by libsodium[1] a project written in C. Imagine now it is possible to construct an argument to those libsodium functions that satisfies the constraints of the Rust wrappers, but still manages to crash libsodium and execute some part of the argument, which is not unheard of since libsodium is written in C and it operates on blobs of data. Now the only mistake the implementor of thrussh has to make is to allow for that input to be passed into the rust libsodium wrapper through the protocol implementation. [1] https://github.com/jedisct1/libsodium https://github.com/jedisct1/libsodium

duaneb 10y ago

> but I wouldn't flat out claim there won't ever be an arbitrary code execution vulnerability in a Rust project. If you note the OP, he expressed it in terms of "high confidence" not a "claim there won't ever be an arbitrary code execution vulnerability in a Rust project". Which would be absurd. And it's also as good as it gets: you can't avoid vulnerabilities.

pcwalton 10y ago

> But as we all know Java has been riddled with code execution bugs. Most of those are of the form "malicious code delivered as Java applet can break out of the JVM sandbox". That is, they crucially rely on running untrusted code. By contrast, the threat model here involves attackers subverting existing, trusted code. Memory safety holes in Rust overwhelmingly rely on bizarre carefully crafted code that nobody would accidentally write. There are some exceptions: Java is affected by serialization issues along the lines of the Rails YAML vulnerability, for instance. But most of those don't apply to Rust either for various reasons.

tinco 10y ago
True enough, definitely with untrusted code your surface is that much larger. What I remember from the few JVM bugs I looked at is that they were always at points where the JVM would call into the operating system or otherwise interact with native code. I would imagine Rust code might be vulnerable at those same points, though obviously much less easily.
- teacup50 10y ago
  There are basically three major classes of Java code execution bugs: 1) Bugs in native code (generally image processing, compression, etc). This code tends to be derived from existing libraries, and so shares common vulnerabilities. 2) Bugs in sandboxing when running untrusted code. Java's sandbox model is fundamentally flawed and I don't believe it can ever be secured. 3) Executing untrusted external user input within the JVM context, e.g., by evaluating external data using your internal scripting language that has access to the JVM or relies on JVM sandboxing. Of those: 1) Not much you can do, but issues are relatively rare. 2) Can be avoided by not running untrusted code in a JVM-enforced sandbox (applets are dead, sorry). 3) You'll be fine if you steer clear of libraries that even go near eval() of untrusted user input. The culprits here are serial offenders due to architectural/design issues, and are easy to avoid (e.g. Apache Struts.)
fpoling 10y ago
Another source of Java bugs is improper input sanitation when untrusted input eventually feed into various interpreters like embedded JavaScript or SQL. That, of cause, can happen with any language, but at least with Rust it is much harder to accidentally call into some framework that exposes an interpreter capable of arbitrary code execution.