-
Notifications
You must be signed in to change notification settings - Fork 11
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
Term with payloads #280
Draft
LCBH
wants to merge
204
commits into
main
Choose a base branch
from
termWithPayloads
base: main
Could not load branches
Branch not found: {{ refName }}
Could not load tags
Nothing to show
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Draft
Term with payloads #280
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
TODOs: - correctly evaluate any sub-term in MakeMessage - modify evaluate for terms and replace found payloads_0 by payloads
…ture, fully tested (in seeds.rs)
…e sup-terms of non-symbolic, fix many bugs, test to investigate mutation failures TODO: clear understanding of which mutations and replacement can fail
… Countable trait + various fixes
find_relative_node now returns `shift_ancestor_to_search:usize`: this can be non-zero when p is not a sibling but a sibling of an ancestor of to_search. It then corresponds to the position of `to_search` relatively to the evaluation of this ancestor. This can happen for example for append(f, fn_support_group_extension(to_search)) when relative node is f and fn_support_group_extension add some headers in front of to_search. shift_ancestor_to_search will be the length of this header.
However, we end up with inconsistent payload replacements. Example: fn_true -> MakeMessage -> BitFlip -> MakeMessage with payload_0 = 0 instead of 1.
…t-in argument like `HELLO_RETRY_REQUEST_RANDOM` which made replace_payload failed!
…n the HandShakeMewssage) + Fix mutation tests
… adding fn_payload_u16 + Fix heuristic 2
…window = parent.window
… encoding, thus failing payloads replacements. Fix most of them. This requires to add several new function symbols.
…or Payload* types (had to use a hacky new trait) add missing types.
….read.encode. Fix try_read_bytes that made this test fail. Add custom Codec2::read for several types. Remove the identity function fn_opaque_message and use type filtering instead (adapt seeds). Disable some safety checks to explore more messages; can be enabled with `enable-guards`. Fix some offset issue with reading PayloadU8. New Codec::read for HandshakeHash.
…utable! Now the test passes.
…ions, in which case MakeMessage only applies to root messages) + better experiment folder formatting
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See [#279 ]
One approach to integrate bit-level mutations (like HAVOC) to tlspuffin and DY fuzzing in general is as follows:
make_bitstring
that:a. randomly choose a sub-term
t
in a recipe in the current trace (similar to what is done in this clone,b. evaluate it to a bitstring
b
,c. associate a mutable version of
b
, amenable to bit-level mutations, tot
in fieldspayload
andinitial_payload
oft
.The idea is that, from now on, future evaluation of
t
will usepayload
instead of using the evaluation oft
and bit-level mutations can mutate in-place the fieldpayload
.HAVOC
operating on allpayloads
of all sub-terms of all recipes in the trace.t
:a. evaluate it to
b_t
as currently done.b. for each sub-term
t'
oft
having a payloadb
(hencemake_message
has been used ont'
), do the following:t.initial_payload
that must be found inb_t
byt.payload
(even if the two do not have the same size)t.initial_payload
can be found at different locations, find the right location corresponding tot'
. (One option is to evaluate the first child oft
that hast'
as descendant, evaluate this child as a bitstring, and findb_t
in it. If there is only one matching location, then we win, otherwise, we recursively do the same on this child (instead oft
).b_t
to the suitable agent.Pros:
Codec::read_bytes
#278], this approach allows to accept any kind of bit-level mutations. Approaches based on re-interpreting the mutated bit-strings in the Mapper internal structure (hererustls
) rejects a lot of mutations that make this re-interpretation/parsing fail. Problem 1: We are not really interested in fuzzing the Mapper: a mutation that may be gracefully rejected by the Mapper might crash the PUT's "Mapper"/parsing routines. Problem 2: even if we used the PUT as Mapper, the context of evaluation in our fuzzer will not be the same as the one of the agent we fuzz, hence some bugs may be missed because of we reject a mutation on the fuzzer side (parsing fails) but this would still crash the PUT.--> This approach does not suffer from those problems, any bit-level mutation will go through.
rustls payloads
(like this clone) are only able to fuzz certain parts of messages (such as certificates). Problem 3: structures of messages (header, length, etc.) cannot be fuzzed this way.Cons:
b
to replace is non-trivial (but possible)Question: some HAVOC sub-mutations are more expressive if we give them the concatenation of all
payloads
of all sub-terms (e.g., the ones that swap around some parts of the bitstrings). We may want do to that but reconstructing the new mutatedpayloads
after having applied the mutation is non-trivial.