Stream: wg-secure-code

Topic: Threshold for "vulnerability"


RalfJ (Jul 16 2019 at 11:49, on Zulip):

What is the threshold for something to be considered a "vulnerability" for https://github.com/RustSec/advisory-db/blob/master/CONTRIBUTING.md ? (And I hope I am asking in the right stream here.)
https://crates.io/crates/memoffset versions before 0.5 have a critical soundness bug, so it would be good to migrate away and update to 0.5. However, except for version 0.3 and 0.4, there are no known problems that were caused by this pattern. What is the best way to proceed?

Alex Gaynor (Jul 16 2019 at 11:54, on Zulip):

Soundness meaning you can extract multiple &mut references or something?

I think any time you've got the possibility for memory unsafety using only safe APIs that's fair game

RalfJ (Jul 16 2019 at 12:30, on Zulip):

it called mem::uninitialized on arbitrary types

RalfJ (Jul 16 2019 at 12:31, on Zulip):

for most recent compiler versions, that will just panic on uninhabited types, and it is not known to cause problems with inhabited types like bool even though it is UB

RalfJ (Jul 16 2019 at 12:31, on Zulip):

for older compiler versions that do not have this panic yet (I dont recall when it got added), LLVM might do whatever

Alex Gaynor (Jul 16 2019 at 12:35, on Zulip):

Can I get it to call mem::uninitialized with a type that implements Drop, thereby almost certainly causing mayhem? Because that surely seems like it'd qualify.

RalfJ (Jul 16 2019 at 12:35, on Zulip):

I think it did mem::forget but let me check

RalfJ (Jul 16 2019 at 12:36, on Zulip):

but note that let b: bool = mem::uninitialized() is insta-UB, drop really is not needed to cause mayhem in theory

Alex Gaynor (Jul 16 2019 at 12:37, on Zulip):

Ah, so not a totally straight forward instance of memory unsafety.

I'm not in charge or anything, but I suppose it qualifies (though I tend to be less excited about these than other vuln types.)

RalfJ (Jul 16 2019 at 12:38, on Zulip):

yeah as I said, except for 0.3 and 0.4 there is no known way to cause an actual miscompilation with recent rustc

Alex Gaynor (Jul 16 2019 at 12:39, on Zulip):

Maybe start with an advisory just for 0.3 and 0.4 then?

RalfJ (Jul 16 2019 at 12:39, on Zulip):

they were only out very briefly and have no resverse deps so I am wondering if its worth it^^

RalfJ (Jul 16 2019 at 12:40, on Zulip):

actually I am wrong they have reverse deps

RalfJ (Jul 16 2019 at 12:40, on Zulip):

okay so I'll start with that

Alex Gaynor (Jul 16 2019 at 12:43, on Zulip):

It's also always possible for them to have users who aren't other crates

RalfJ (Jul 16 2019 at 13:52, on Zulip):

fair

Tony Arcieri (Jul 16 2019 at 13:56, on Zulip):

seems good to me

Shnatsel (Jul 17 2019 at 20:17, on Zulip):

if something can panic while holding on to mem::uninitialized(), that's exploitable. See https://github.com/RustSec/advisory-db/blob/master/crates/libflate/RUSTSEC-2019-0010.toml for example

Tony Arcieri (Jul 17 2019 at 20:18, on Zulip):

https://rustsec.org/advisories/RUSTSEC-2019-0011.html

Shnatsel (Jul 17 2019 at 20:20, on Zulip):

https://github.com/Gilnaa/memoffset/issues/9#issuecomment-505472124 - wait, isn't this memory disclosure?

Tony Arcieri (Jul 17 2019 at 20:23, on Zulip):

sounds like it

Shnatsel (Jul 17 2019 at 21:28, on Zulip):

It should be mentioned into the advisory then

Tony Arcieri (Jul 18 2019 at 16:49, on Zulip):

@Shnatsel yeah, definitely

Tony Arcieri (Jul 18 2019 at 16:49, on Zulip):

do you want to add it or should I?

Shnatsel (Jul 18 2019 at 17:58, on Zulip):

Best if you do it, I'll try to handle the other smallvec vuln in the meanwhile

Tony Arcieri (Jul 18 2019 at 18:01, on Zulip):

so I linked that to Patrick Walton and he was questioning it... I'm not sure I'm confident enough to say anything definitive in the advisory

Tony Arcieri (Jul 18 2019 at 18:01, on Zulip):

I guess we can just bug @RalfJ directly :wink:

Shnatsel (Jul 18 2019 at 18:02, on Zulip):

Neither am I ¯\_(ツ)_/¯

RalfJ (Jul 19 2019 at 07:24, on Zulip):

well it's a bug leading to an incorrect offset being returned

RalfJ (Jul 19 2019 at 07:24, on Zulip):

depending on how the offset gets used it could indeed lead to arbitrary OOB memory accesses

RalfJ (Jul 19 2019 at 07:26, on Zulip):

if something can panic while holding on to mem::uninitialized(), that's exploitable. See https://github.com/RustSec/advisory-db/blob/master/crates/libflate/RUSTSEC-2019-0010.toml for example

I see. And indeed together with the other bug, there could be arbitrary user code being executed (as part of the deref coercion, which I had entirely forgotten about) and if that panics that does lead to dropping a mem::uninitialized.

RalfJ (Jul 19 2019 at 07:26, on Zulip):

this affects all versions before 0.5

RalfJ (Jul 19 2019 at 07:26, on Zulip):

so should the advisory be updated for this?

Tony Arcieri (Jul 19 2019 at 15:55, on Zulip):

I think so but I would prefer someone who understands the exact exploitation path do the writeup :wink:

Shnatsel (Jul 19 2019 at 17:06, on Zulip):

@RalfJ Arbitrary OOB memory access is a Big Deal. This definitely needs to go into the advisory.

RalfJ (Jul 20 2019 at 10:53, on Zulip):

absolutely, I just was not sure if this should be a new advisory or an update. I will then make it an update.

RalfJ (Jul 20 2019 at 10:57, on Zulip):

submitted update: https://github.com/RustSec/advisory-db/pull/129

Shnatsel (Jul 20 2019 at 13:24, on Zulip):

The interesting question is, what do we do about the vulnerable versions with no semver-compatible upgrade path? Is it possible to backport the fixes, or do we need to yank all versions of every single crate that depends on a vulnerable version?

RalfJ (Jul 20 2019 at 13:28, on Zulip):

there is no semver-compatible upgrade path

RalfJ (Jul 20 2019 at 13:29, on Zulip):

fixing the potential panic during the computation requires ruling out deref coercions, and the only known way to do that only works for testing a field of a type. the old versions of the crate allowed things like offset_of!(Type, field[3].subfield). We dont know how to statically or dynamically rule out deref coercions for such a macro.

RalfJ (Jul 20 2019 at 13:30, on Zulip):

however, when a crate only uses offset_of! internally and does not actually use it in a way that would cause a deref coercion, there is no reason to yank that crate

RalfJ (Jul 20 2019 at 13:30, on Zulip):

(unless it used version 0.3 or 0.4 which can cause SIGILL)

Shnatsel (Jul 20 2019 at 13:52, on Zulip):

Well, we can at least enumerate the crates that depend on old versions. Thanks to @Zach Reizner for https://gitlab.com/zachreizner/crates-audit

Alex Gaynor (Jul 20 2019 at 13:55, on Zulip):

Is there an online summary of this? Just sending PRs to resolve the highest impact ones would be a valuable way for people to contribute to ecosystem security.

RalfJ (Jul 20 2019 at 13:56, on Zulip):

do you mean https://crates.io/crates/memoffset/reverse_dependencies ?

RalfJ (Jul 20 2019 at 13:57, on Zulip):

I took care of the three most-downloaded ones in that list

RalfJ (Jul 20 2019 at 13:58, on Zulip):

Well, we can at least enumerate the crates that depend on old versions. Thanks to Zach Reizner for https://gitlab.com/zachreizner/crates-audit

what does that do? the repo doesn't explain anything...

Alex Gaynor (Jul 20 2019 at 14:01, on Zulip):

It analyzes all of crates.io and finds packages which depend on a package which has a rustsec vuln

Shnatsel (Jul 20 2019 at 14:05, on Zulip):

The interesting part is that it does so transitively. So you can look up all the leaf crates affected by a vulnerability.
It currently only detects cases without a semver-compatible upgrade path.

RalfJ (Jul 20 2019 at 14:45, on Zulip):

I see, interesting. I basically sued the download numbers as a proxy for "is this in the transitive chain of something widely used".

Tony Arcieri (Jul 20 2019 at 15:51, on Zulip):

crates-audit is running here: https://crates.rustsec.org/

Tony Arcieri (Jul 20 2019 at 15:51, on Zulip):

@RalfJ your update looks good. should it specifically call out potential memory exposure and/or RCE?

Tony Arcieri (Jul 20 2019 at 16:36, on Zulip):

made a note of that on the PR

Tony Arcieri (Jul 20 2019 at 17:14, on Zulip):

@Shnatsel re: upgrade path for vulnerable versions and semver compat, someone with the same question https://twitter.com/DPC_22/status/1152623528442773505

Shnatsel (Jul 20 2019 at 17:23, on Zulip):

Re: twitter complaint: they need a third option. Backport something somewhere - extract stdlib function into their crate or some such. I wouldn't worry about MSRV 1.32 but if it's 1.36 that's too extreme. And if it's not fixable that way... well, rewrite the code to be slower but actually safe.

Shnatsel (Jul 20 2019 at 17:24, on Zulip):

I don't have twitter so can't comment in there

Shnatsel (Jul 20 2019 at 17:40, on Zulip):

Oh, regarding uninitialized memory and panic, there was this exact problem in libflate too: https://rustsec.org/advisories/RUSTSEC-2019-0010.html and it's fixed by using take_mut crate instead of uninitialized memory.

Shnatsel (Jul 20 2019 at 17:41, on Zulip):

The issue was discovered and fixed by Shnatsel.

This is weird to see in an advisory for some reason.

DPC (Jul 20 2019 at 19:13, on Zulip):

@Shnatsel thanks. The relevant discussion is here

DPC (Jul 20 2019 at 19:13, on Zulip):

(deleted)

DPC (Jul 20 2019 at 19:13, on Zulip):

Wait

DPC (Jul 20 2019 at 19:13, on Zulip):

https://github.com/sodiumoxide/sodiumoxide/pull/350

Shnatsel (Jul 20 2019 at 19:15, on Zulip):

There is nothing in there saying it's exploitable though

DPC (Jul 20 2019 at 19:17, on Zulip):

Yes it may not be. But we are taking the safe option and replacing rather than depending on a deprecated function

Shnatsel (Jul 20 2019 at 19:17, on Zulip):

This function is not yet deprecated and won't be until 1.40, so I don't see an immediate problem.

RalfJ (Jul 20 2019 at 19:18, on Zulip):

it's deprecated with 1.39

RalfJ (Jul 20 2019 at 19:18, on Zulip):

and the only reason we are waiting is to give people time to migrate

Shnatsel (Jul 20 2019 at 19:18, on Zulip):

Huh. With Debian Stable shipping 1.34 and Ubuntu shipping 1.32, I'd expect people will need way more time to migrate.

RalfJ (Jul 20 2019 at 19:18, on Zulip):

but yeah, mem::uninitialized has been broken since forever, it's just with 1.36 now there is finally a fix -- but it requires bumping the minimal Rust version

Tony Arcieri (Jul 20 2019 at 19:19, on Zulip):

@Shnatsel that makes me somewhat sad :cry:

DPC (Jul 20 2019 at 19:19, on Zulip):

Thanks. Yeah which is 2-3 months later which goes well with our release plans

RalfJ (Jul 20 2019 at 19:19, on Zulip):

I don't think there is any precedence for aligning deprecation schedule with distros? deprecating 3 versions in the future is our "cautious" deprecation, most of the time stuff just gets deprecated with some release ;)

DPC (Jul 20 2019 at 19:20, on Zulip):

Yeah deprecations don't align with distro releases

RalfJ (Jul 20 2019 at 19:20, on Zulip):

it's sad that debian and ubuntu have a pre-MaybeUninit rust, but then there are tons of reasons why using a 1-year-old Rust is a bad idea even if thats what your distro ships

Shnatsel (Jul 20 2019 at 19:21, on Zulip):

Ubuntu LTS actually updated to 1.32, despite being from April 2018... so there is hope

RalfJ (Jul 20 2019 at 19:21, on Zulip):

so if they want to stick with that (as opposed to RedHat where I heard they will actually ship ever 2nd Rust release to their stable distro)... well bad for them I guess and someone should talk with them about that.

DPC (Jul 20 2019 at 19:22, on Zulip):

We have got bitten by that before. Had to maintain 1.22.0 for a long time on another crate because of fedora (till we bumped it to 1.32 when we switched to 2018 Ed)

RalfJ (Jul 20 2019 at 19:22, on Zulip):

I mean if you are not affected by https://github.com/rust-lang/rust/issues/62825 there is no reason to do the switch to MaybeUninit now rather than in 2 or 3 releases, I guess

Shnatsel (Jul 20 2019 at 19:22, on Zulip):

miniz_oxide also has a hypothetical safety improvement if bumped to 1.34 as minimum version thanks to u32::from_le_bytes() and try_into(), but it has so many checks around it already so I'm not really worried

Tony Arcieri (Jul 20 2019 at 19:22, on Zulip):

for production applications we're primarily CentOS users. We source Rust from the Fedora repos, but the Fedora Rust people are amazing and usually turn around new RPMs for each Rust release in less than a week

Tony Arcieri (Jul 20 2019 at 19:23, on Zulip):

Debian/Ubuntu people do not seem to be quite as enthusiastic about Rust...

Shnatsel (Jul 20 2019 at 19:23, on Zulip):

RHEL also has aggressive about their update policy, with 3-month syncs

DPC (Jul 20 2019 at 19:24, on Zulip):

Yeah Ralf, but it will most likely be a while before we create a new release so it is fine

Tony Arcieri (Jul 20 2019 at 19:24, on Zulip):

RedHat is also actually using Rust in some of their tools (e.g. rpm-ostree), whereas I see Debian people talking about dropping support for projects which are migrating to Rust because they don't want to deal with building them :cry:

Shnatsel (Jul 20 2019 at 19:24, on Zulip):

I believe Ubuntu actually updates Rust after the distro release, which is basically unprecedented. The only other packages to do that other than rustc are Firefox and Chromium.

Tony Arcieri (Jul 20 2019 at 19:24, on Zulip):

@Shnatsel neat

DPC (Jul 20 2019 at 19:25, on Zulip):

Tony there is some talk going on with having an Ubuntu snap. Details aren't public yet iirc

Tony Arcieri (Jul 20 2019 at 19:25, on Zulip):

nice

Shnatsel (Jul 20 2019 at 19:25, on Zulip):

oh WOW they're on 1.35 already!

Tony Arcieri (Jul 20 2019 at 19:25, on Zulip):

:tada:

Tony Arcieri (Jul 20 2019 at 19:25, on Zulip):

that's good, because a bunch of my crates are 1.35 minimum now

Shnatsel (Jul 20 2019 at 19:26, on Zulip):

1.35 because it's apparently a security update?

Tony Arcieri (Jul 20 2019 at 19:26, on Zulip):

aah

DPC (Jul 20 2019 at 19:26, on Zulip):

What security update?

Shnatsel (Jul 20 2019 at 19:28, on Zulip):

IDK, it comes from the security updates repo but there is nothing about it on Ubuntu Security Notices

Shnatsel (Jul 20 2019 at 19:28, on Zulip):

The latest CVE I've filed was https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-1010299

Shnatsel (Jul 20 2019 at 19:30, on Zulip):

https://www.cvedetails.com/vulnerability-search.php?f=1&vendor=&product=Rust%2C+&cveid=&msid=&bidno=&cweid=&cvssscoremin=&cvssscoremax=&psy=&psm=&pey=&pem=&usy=&usm=&uey=&uem= - nothing here for 1.32 that they shipped previously. Oh well. Good thing it's up to date though!

DPC (Jul 20 2019 at 19:36, on Zulip):

Thanks for the help :)

Shnatsel (Jul 20 2019 at 19:49, on Zulip):

Any idea where I can browse the current package versions for RHEL/CentOS? I know of https://packages.ubuntu.com/ and https://www.debian.org/distrib/packages but nothing equivalent for RHEL

Tony Arcieri (Jul 20 2019 at 21:10, on Zulip):

I might be a bit silly but if I'm trying to find things via the web as opposed to using the yum/dnf CLI tools, here's how I typically do it: http://mirror.centos.org/centos/7/os/x86_64/

Tony Arcieri (Jul 20 2019 at 21:10, on Zulip):

that's not the yum repo I source Rust from, though

Tony Arcieri (Jul 20 2019 at 21:12, on Zulip):

we install Rust from EPEL, which is repackaged from the Fedora Rust builds

Tony Arcieri (Jul 20 2019 at 21:12, on Zulip):

we try to minimize use of EPEL and it's not enabled per default, but I think Rust is a great example of it working

Tony Arcieri (Jul 20 2019 at 21:13, on Zulip):

also the Fedora Rust team seems amazing

Tony Arcieri (Jul 20 2019 at 21:14, on Zulip):

RedHat seems to be quite interested in Rust, especially for things like building out Project Atomic

Last update: Nov 15 2019 at 20:45UTC