Closed tirkarthi closed 6 years ago
Thanks for the tip @tirkarthi , we haven't done a build of our project internally that uses this, and I must've missed this in my morning scan of advisories.
We'll work on getting this patched ASAP, and yanking the old version.
As an update it looks like the Ring crate still uses 0.6.1 which is actually our whole use of untrusted. Until ring bumps we will not be able to bump our version.
As for the issue itself it looks like this only occurs in:
A mistake in error handling in untrusted before 0.6.2 could lead to an integer
underflow and panic if a user of the crate didn't properly check for errors
returned by untrusted.
Our only use of untrusted is: untrusted::Input::from
which does not return an error type. So I feel safe in saying that this doesn't affect us. We should still bump as soon as possible just incase, but I'm assuming it'll be a bit, which is acceptable considering our usage of untrusted.
@tirkarthi do I have a grasp of this situation right? Anything else you can see here that I'm missing?
Sorry, I don't have much information about the vulnerability affecting this project. In fact I did this as part of pinging people based on projects who use untrusted as dependency. A recent discussion about the security aspect at r/rust might be helpful : https://www.reddit.com/r/rust/comments/8tv847/rustsec_advisory_an_integer_underflow_in/e1b3x0o
Also author of ring is also the author of untrusted so there might be a new release soon with the updated dependency.
Thanks
Description
This project seems to use
untrusted = 0.5.1
as I can see from the cargo.toml file on master branch. Recently a security issue was fixed as part of 0.6.2 release. Please refer to https://github.com/RustSec/advisory-db/commit/3c0458d26bd19e30dc19ae5ca9a4540cc9c0394b . You can also consider adding cargo audit as part of the build step to get notified in the future.Kindly ignore if this is irrelevant or fixed on another branch.
Thanks.