
Security Advisory for rustdoc - steveklabnik
https://blog.rust-lang.org/2018/07/06/security-advisory-for-rustdoc.html
======
kenhwang
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.

~~~
mikeash
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
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
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
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
Ah, the post is kinda unclear on the command line requirement. It says they're
loaded by default.

~~~
steveklabnik
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 :)

------
magissima
What an odd place to load plugins from.

~~~
baseballdork
Yeah, looks like a long forgotten temp path for a long deprecated feature. I'd
be lying if I said I'd never done the same.

~~~
cmrx64
I added support for loading plugins to the pass manager because I could. It
was never really useful. I had a vision for rustdoc_ng, which was that it
would do all the dirty work of collecting information from the (complex) Rust
AST into a (simpler) "doc tree" describing just details relevant for
documentation, and backends would add their own plugin passes as needed to
massage that AST before final output of the JSON doctree, while the original
analyzed Rust AST was still around. I think I'm probably the only person that
ever used this, in an experimental troff backend.

I was in a rush to get it out the door before I went off to start college, and
I guess I never removed my testing path from the code. Oops!

It was fun getting the email this morning and reminiscing ;)

------
admax88q
> rustdoc’s obscure plugin functionality, consisting of its loading plugins by
> default from a path that is globally writable on most platforms

It's supremely disappointing that a brand new language/platform like rust
suffers from the same classic security mistakes that we keep finding in old
software. You normally expect to see these types of things in stuff like Bash
that has been around for so long nobody has taken time to review lots of its
code with a more modern thread level.

