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

Added fuzzy testing #26

Merged
merged 6 commits into from
Jun 9, 2018
Merged

Added fuzzy testing #26

merged 6 commits into from
Jun 9, 2018

Conversation

newpavlov
Copy link
Contributor

@newpavlov newpavlov commented Jun 8, 2018

It is quite important for decoder to be robust in face of malicious input and fuzzy tests is a good helper for improving our chances.

Short fuzzer runs exposed two serious problems which can be exploited for performing DoS attack:

  • In metadata.rs there is no checks on requested chunk_size which can lead to requesting a huge memory chunk. I've fixed it and limited chunk_size by 1 MB. (probably this value should be configurable in future)
  • There is an input which leads to a growing memory usage, probably by creating huge maniac tree. See fuzz/artifacts/fuzz_flif/crash-8d04f4ab0c66838d13561517a34fc18cdf062439, if you'll uncomment line in tests/fuzz.rs it will run fuzzing artifacts.

@@ -3,6 +3,9 @@ use error::*;
use inflate::inflate_bytes;
use numbers::FlifReadExt;

// maximum size of the comressed metadata chunk to prevent DoS attack
const MAX_METADATA_CHUNK: usize = 1<<20;
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did you check if the official FLIF library has a similar limit?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, at first glance I couldn't find such checks, but I am not exactly proficient with C++.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In general I think it will be a good idea to limit value which read_varint can produce, e.g. with 56 bits (8*7), or at least perform overflow checks.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

read_varint is already performing a checked add, so it should be immune to overflow. Is this not the case?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, yes, you are right.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll revert this change, and instead will create configurable limits in the next PR.

let mut deflated_chunk = vec![0; chunk_size];
reader.read_exact(&mut deflated_chunk)?;
let inflated_chunk = inflate_bytes(&deflated_chunk).map_err(Error::InvalidMetadata)?;
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: revert this formatting change.

It clutters the PR

use flif::Flif;
use std::io::{Cursor, Read};

/// Tests an issue found in [#15](https://github.com/dgriffen/flif.rs/issues/15)
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So the artifact in this test both tests the crash in #15 and triggers growing memory usage?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This artifact only triggers growing memory usage in non_interlaced_pixels, IIUC fuzzer kills it long before OOM. I will remove it from this PR and will create a separate bug.

@ZoeyR
Copy link
Owner

ZoeyR commented Jun 8, 2018

I'm not too familiar with the cargo fuzzing library. But I assume this is not meant to be added to the workspace?

@newpavlov
Copy link
Contributor Author

fuzz/Cargo.toml was created automatically and it creates its own workspace with the following comment: "Prevent this from interfering with workspaces", so yes.

@newpavlov newpavlov mentioned this pull request Jun 8, 2018
@ZoeyR
Copy link
Owner

ZoeyR commented Jun 8, 2018

I'm trying to run this locally with cargo +nightly fuzz run fuzz_target_1 but it fails with:

error: could not decode the manifest file at "C:\\Users\\dagriffe\\Documents\\flif.rs\\Cargo.toml" caused by: redefinition of table `workspace` for key `workspace` at line 24

Any idea whats going on?

@newpavlov
Copy link
Contributor Author

newpavlov commented Jun 8, 2018

Command is cargo fuzz run fuzz_flif, but looks like your problem is not related to it. (I am using Linux, so currently can't test this on Windows)

Hm, strange... Google can't find similar errors. UPD: Closest one is rust-lang/cargo#4760.

@ZoeyR
Copy link
Owner

ZoeyR commented Jun 8, 2018

I think my issue was running it from the fuzz directory, which seems to be wrong. I use windows machines myself which seems like it will cause issues since cargo-fuzz only supports linux/macOS.

@ZoeyR
Copy link
Owner

ZoeyR commented Jun 9, 2018

Now that the limits are in this branch should we run the fuzzer again? I don't have access to a linux machine currently so I can't do it.

@newpavlov
Copy link
Contributor Author

newpavlov commented Jun 9, 2018

Short fuzzing revealed use of unimplemented!() macro in permute_planes.rs. (probably it's worth to temporarily disable this transform if implementations is not complete) I think this PR can be merged as is. I will try to fuzz this crate from time to time and will report any found issues.

UPD: This is the input which triggers it, if you are interested:

b"FLIF11\x00\x00\x00@FLIreeip\xb6\x00\x00\x04\x08\x00\x00\x00\x00"

@ZoeyR ZoeyR merged commit 2838f09 into ZoeyR:master Jun 9, 2018
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

Successfully merging this pull request may close these issues.

2 participants