There are important files that Microsoft projects should all have that are not present in this repository. A pull request has been opened to add the missing file(s). When the pr is merged this issue will be closed automatically.

Microsoft teams can learn more about this effort and share feedback within the open source guidance available internally.

Merge this pull request

Please accept this contribution adding the standard Microsoft SECURITY.MD :lock: file to help the community understand the security policy and how to safely report security issues. GitHub uses the presence of this file to light-up security reminders and a link to the file. This pull request commits the latest official SECURITY.MD file from https://github.com/microsoft/repo-templates/blob/main/shared/SECURITY.md.

Microsoft teams can learn more about this effort and share feedback within the open source guidance available internally.

Bumps spin from 0.5.0 to 0.5.2.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Overview

Deserialization would be desired so we can take real "over-the-wire" data sent to a target server, application, or library, and deserialize it back into a Rust structure as defined in the fuzzer. This would help with reproducibility and using real corpuses to get started with fuzzing.

Blockers

lain does not use a 1:1 mapping between Rust objects and target objects. The expectation is that the user defines a struct with a layout that's similar to how the object looks while serialized. This includes the user defining things like the padding as part of the data structure. Bitfields are an exception where the Rust struct would appear larger than the target structure since these are defined as a whole-sized type (e.g. if you have two bitfields with 4 bits each, it'd be defined as two u8 fields).

Given the nature of fuzzing these data structures as well, it's not reliable to decode from a C type to Rust types for things like dynamic-sized arrays, strings, or things that rely on run-length encoding. For example, given the following struct:

struct Foo {
    len: u8,
    items: DynamicArray<Bar>,
}

How would we know the true length of items given that len will most of the time not exactly match the true length of items? Or null-terminated strings with null bytes embedded before the actual end of the string?

Possible solutions

The only realistic solution is to always assume well-formed data. Fuzzer-generated data will produce errors and cannot be deserialized. All fields will be considered trusted and well-formed. Users should not rely on decoding C structs for corpuses and instead should convert to a Rust-native serializing solution such as bincode.

Why enum variations fuzzing is not supported?

#[derive(NewFuzzed)]
   |          ^^^^^^^^^ variant or associated item cannot be called on `ACCESS` due to unsatisfied trait bounds

Here's the remaining warnings:

warning: the feature `specialization` is incomplete and may not be safe to use and/or cause compiler crashes
   --> lain/src/lib.rs:101:12
    |
101 | #![feature(specialization)]
    |            ^^^^^^^^^^^^^^
    |
    = note: `#[warn(incomplete_features)]` on by default
    = note: see issue #31844 <https://github.com/rust-lang/rust/issues/31844> for more information
    = help: consider using `min_specialization` instead, which is more stable and complete

warning: field is never read: `all_chances_succeed`
  --> lain/src/mutator.rs:35:5
   |
35 |     all_chances_succeed: bool,
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: `#[warn(dead_code)]` on by default

warning: `lain` (lib test) generated 2 warnings

(min_specialization doesn't seem to work here)

We're using lain in an example for LibAFL, a fuzzing library that supports multiple faster (non-cryptographic) random implementations, but we are unable to update our rand crate dependency, as it breaks with Lain's version, see https://github.com/AFLplusplus/LibAFL/pull/327. As the rand API, as far as I can tell, did not have any drastic changes, maybe you can update it at some point. Thanks

Just a quick fix for the version inside the example, otherwise you get:

error: failed to select a version for the requirement `lain = "^0.2"`
  candidate versions found which didn't match: 0.5.0
  location searched: XXX/lain/lain
required by package `example_fuzzer v0.1.0 (XXX/lain/examples/example_fuzzer)

It seems like there would be adapter libraries, or this would be one piece of a larger fuzzing system? Where does this fit in with cargo fuzz or other existing rust fuzzing tools?