4 ms·

This is a very strange CVE; the risk of exploit is effectively zero and the remediation effort and attention is equal to a routine version bump. I suppose this

This is a very strange CVE; the risk of exploit is effectively zero and the remediation effort and attention is equal to a routine version bump. I suppose this serves as a nice PSA and fire drill for the security team.

steveklabnik 8y ago
Yep, that's how I view it. Real enough to take seriously, but at the same time, not so severe as to put an intense amount of pressure on the whole thing. The only two previous vulnerabilities we had were in crates.io, and this has already exposed some interesting aspects of how we handle these kinds of things. If we have to have a security bug, this is exactly the kind I'd prefer to have.
reificator 8y ago
This I think is the key takeaway: > It’s worth noting that while Rust does prevent a lot of issues in your code at compile time, they’re issues that result from memory unsafety. This bug is a logic error. Rust code is not inherently secure, or bug-free. Sometimes, people get enthusiastic and make overly-broad claims about Rust, and this incident is a good demonstration of how Rust’s guarantees can’t prevent all bugs.
mikeash 8y ago
It doesn’t seem to me that the risk is effectively zero. You can’t exploit it remotely, but as a local exploit it looks pretty nice.
- steveklabnik 8y ago
  It only works if: * You're using this totally undocumented feature. This involves somehow fabricating a plugin that will actually load, which is non-trivial. Pretty sure you have to copy the appropriate types out of the source of Rust itself, and build things that way. * You're also relying specifically on the fallback location * You're doing this on a computer with other users When you pass either of the flags in question, it prints out a message saying "hey, this feature is deprecated, please comment on this github issue if you're using it" and has gotten zero comments in a full year. Never say never, but the chances of this affecting anyone are extremely remote.
  - tedunangst 8y ago
    Eh, an attacker would simply do all of those things, like copying types from the rust source. I don't disagree this is minor, but an actual attacker will certainly not be thwarted because a vulnerable feature is not documented.
    - steveklabnik 8y ago
      The attacker would, of course, but unless you’re also doing it to, it won’t work. The plugin existing isn’t enough, you have to pass a flag with the name to try to activate it. If it just loaded them without the user needing to also use a flag, the chances would go way up, for sure.
      - tedunangst 8y ago
        Ah, the post is kinda unclear on the command line requirement. It says they're loaded by default.
        steveklabnik 8y ago
        Ah so, yeah it’s poorly worded. If you don’t pass —plugin-path, the default location is the /tmp prefixed one. But you need —plugins for it to attempt to load them at all. I’ll re-work the wording when I’m at a computer, thanks :)

steveklabnik 8y ago

Yep, that's how I view it. Real enough to take seriously, but at the same time, not so severe as to put an intense amount of pressure on the whole thing. The only two previous vulnerabilities we had were in crates.io, and this has already exposed some interesting aspects of how we handle these kinds of things. If we have to have a security bug, this is exactly the kind I'd prefer to have.

reificator 8y ago

This I think is the key takeaway: > It’s worth noting that while Rust does prevent a lot of issues in your code at compile time, they’re issues that result from memory unsafety. This bug is a logic error. Rust code is not inherently secure, or bug-free. Sometimes, people get enthusiastic and make overly-broad claims about Rust, and this incident is a good demonstration of how Rust’s guarantees can’t prevent all bugs.

mikeash 8y ago

It doesn’t seem to me that the risk is effectively zero. You can’t exploit it remotely, but as a local exploit it looks pretty nice.

steveklabnik 8y ago
It only works if: * You're using this totally undocumented feature. This involves somehow fabricating a plugin that will actually load, which is non-trivial. Pretty sure you have to copy the appropriate types out of the source of Rust itself, and build things that way. * You're also relying specifically on the fallback location * You're doing this on a computer with other users When you pass either of the flags in question, it prints out a message saying "hey, this feature is deprecated, please comment on this github issue if you're using it" and has gotten zero comments in a full year. Never say never, but the chances of this affecting anyone are extremely remote.
- tedunangst 8y ago
  Eh, an attacker would simply do all of those things, like copying types from the rust source. I don't disagree this is minor, but an actual attacker will certainly not be thwarted because a vulnerable feature is not documented.
  - steveklabnik 8y ago
    The attacker would, of course, but unless you’re also doing it to, it won’t work. The plugin existing isn’t enough, you have to pass a flag with the name to try to activate it. If it just loaded them without the user needing to also use a flag, the chances would go way up, for sure.
    - tedunangst 8y ago
      Ah, the post is kinda unclear on the command line requirement. It says they're loaded by default.
      - steveklabnik 8y ago
        Ah so, yeah it’s poorly worded. If you don’t pass —plugin-path, the default location is the /tmp prefixed one. But you need —plugins for it to attempt to load them at all. I’ll re-work the wording when I’m at a computer, thanks :)