Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Panic when decoding an invalid UTCTime #27

Closed
nmathewson opened this issue Nov 14, 2021 · 0 comments
Closed

Panic when decoding an invalid UTCTime #27

nmathewson opened this issue Nov 14, 2021 · 0 comments

Comments

@nmathewson
Copy link
Contributor

nmathewson commented Nov 14, 2021

Hello, I hope this is the right place to report this; I didn't find any documentation for a preferred method for reporting security issues.

The following code panics when trying to parse an invalid UTCTime object:

fn main() {
    let input =  [55, 13, 13, 133, 13, 13, 50, 13, 13, 133, 13, 13, 50, 13, 133];
    let output = simple_asn1::from_der(&input);
    println!("{:?}", output);
}

The panic occurs because of these line in lib.rs:

                let v = String::from_iter(body.iter().map(|x| *x as char));
                let y = &v[0..2];

If the string is constructed in such a way that the first two bytes do not end on a character boundary, the slice operation will panic.

Found by fuzzing a downstream library.

I'll submit a patch ASAP.

nmathewson added a commit to nmathewson/simple_asn1 that referenced this issue Nov 14, 2021
When slicing a string, you get a panic if you do so at any point
other than at a character boundary.  This happened in the
implementation of UTCTime parsing.

This bug was introduced in bc156c3,
and appears to affect only version 0.6.0.

I've tried using the clippy::string_slice lint to confirm that there
are not any other string slices in this code.

Fixes bug acw#27.  Found via fuzzing.
@acw acw closed this as completed Nov 15, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants