fuzz: `script`: Assertion `!extract_destination_ret' failed.

[dergoegge]

$ echo "TnNcAALv////Ua2t" | base64 --decode > script.crash
$ FUZZ=script src/test/fuzz/fuzz script.crash
fuzz: test/fuzz/script.cpp:87: void script_fuzz_target(FuzzBufferType): Assertion `!extract_destination_ret' failed.

[dergoegge]

This looks P2A related (#30352).

cc @instagibbs @glozow

[ismaelsadeeq]

Yes I think it is, I've bisected and it starts crashing on 455fca8

IIUC I dont think we should assert that ExtractDestination will return false after parsing a CScript of TxoutType::ANCHOR type.

It returns true.

bitcoin/src/addresstype.cpp

Lines 90 to 92 in 24ced52

	case TxoutType::ANCHOR: {
	addressRet = PayToAnchor();
	return true;

So I think we should not assert for that?

diff

diff --git a/src/test/fuzz/script.cpp b/src/test/fuzz/script.cpp
index a23543d70ec..07a49e039fb 100644
--- a/src/test/fuzz/script.cpp
+++ b/src/test/fuzz/script.cpp
@@ -76,13 +76,11 @@ FUZZ_TARGET(script, .init = initialize_script)
         assert(which_type == TxoutType::PUBKEY ||
                which_type == TxoutType::NONSTANDARD ||
                which_type == TxoutType::NULL_DATA ||
-               which_type == TxoutType::MULTISIG ||
-               which_type == TxoutType::ANCHOR);
+               which_type == TxoutType::MULTISIG);
     }
     if (which_type == TxoutType::NONSTANDARD ||
         which_type == TxoutType::NULL_DATA ||
-        which_type == TxoutType::MULTISIG ||
-        which_type == TxoutType::ANCHOR) {
+        which_type == TxoutType::MULTISIG) {
         assert(!extract_destination_ret);
     }
  

[maflcko]

About how easy it is for the fuzz engine to find this bug: This is trivial to find in libFuzzer with a small enough max_len and value profile ( for example, -use_value_profile=1 -max_len=24). However, absent that, it seems harder to find on a quick test.

There are no hashes involved here, so in theory symbolic execution should also be able to find this quickly?

Would be fun to use this example for some fuzz benchmarks/evaluation. cc @dergoegge @agroce @murchandamus

[agroce]

This actually leads to a q I was wondering about for OSS-Fuzz: are there configs for appropriate targets with smaller max-lens?

[dergoegge]

fwiw, I found this using afl++ and libfuzzer in parallel in ~16h CPU hours. The original input is much larger, but I minimized it for this issue:

TnNzc3NzknNzc3Nzc3Nzc3NzUXNzc3Nzc3NzcnNzc3Nzc3Nzc3Nzc3Nzc3Nzc3MAAAAAgPlzc3Nzc3NEY1wAAAAAgAEBAYABAfogAAAAc3Nzc3Nzc3Nzc3Nzc3NzbHNzc3Nzc3Jzc3//c3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3N3c3Nzc3NzRAFc/wEBAYABAQGAAQH6AS8vLy8vLy8vLy8vEi9/AC8vLy8vLy8vLy8vc3NWc3Nzc3NzlHNfc3Nzc3Pe3iHe3t7e3t7e3t7ec3NBQQCeW1yfn5+fn5+fn59cXFxcXFxcXV1cQZ+fc3Nzc3hzc3Nzc0QBXP8BAQGAAQEBgAEB+gEvLy8vLy8vLy9CLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vb0FBQUFbdVteW1u3W1tb6Fw1AAAAf/9cXABcXFwAAF1cu1xmW1xcXDk5AxC+AVzBXB0xMTExMTExMTExMTH//wAB/zsh/7D/sFZcc3Nzc3Nzc3Nzc3Nzc3NydHNzc3Nzc1xcXFxvXAAAAAAAAHNzc3Nzc3Nzc3Nzc3Nzc3N3c3Nzc3NzRAFzc3Nzc3Nzc0QBXP8BAQGAAQEBgAEB+gEvLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vb0FBQUFbdVteW1vOW1tb6EJCQnNEAVwAAAAAgAEBAYABAfpzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Jzc3//c3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3N3c3Nzc3NzRAFc/wEBAYABAVwuXP8D6Fw1XH1cXFxBQUBhPlxAAHhBAOzu////Ua2tLy8vLy8vLy8vLy9vQUFBQVt1W15bXKdbW1voXDVcAQGAAQH6AS8vLy8vLy8vLy8vEi9/AC8vLy8vLy8vLy8vc3NWc3Nzc3NzlHRfc3Nzc3Pe3t7e3t7e3t7e3t7ec3NBQQCeW1yfn5+fn5+fn59cXFxcXFxcXV1cQZ+fc3Nzc3hzc3Nzc0QBXP8BAQGAAQEBgAEB+gEvLy8vLy8vLy9CLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vb0FBQUFbdVteW1u3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t1tbW+hcNVx9XCcE/xxcIx4AAAAAIwA6AHkBLy8vL1zBXAFcwVwdMTExMTExMTExMTEx//8AAf87If+w/7BWXHNzc3Nzc3Nzc3Nzc3NzcnNzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3NEAVz/AQEBgAEBAVxCQuLj4uLi4uLi4kJCQUFteQAx9QH1eXr1ARAAAVwuXP8D6Fw1XH1cXFxBQUBhPlxAAHhBAOzu////Ua2tLy8vLy8vLy8vLy9vQUFBQVt1W15bXKdbW1voXDVcfVxcXEFBQGE+XEAAaEEAAtH///8BgAEB+gEBEAABXC5c/wPoXDVcfVxcXEFBZGE+XEAAeEEAAu////9Rra0=

This actually leads to a q I was wondering about for OSS-Fuzz: are there configs for appropriate targets with smaller max-lens?

Not on oss-fuzz directly. I think we have a few harnesses that exit early if the input size is smaller or larger than expected, e.g.:

bitcoin/src/test/fuzz/script_flags.cpp

Line 20 in c2d15d9

if (buffer.size() > 100'000) return;

[agroce]

I think we have a few harnesses that exit early if the input size is smaller or larger than expected, e.g.:

Not sure the equivalent in AFL++, but in libFuzzer (and Eclipser) for some targets really limiting the size of input gives the mutator a much better chance at finding lots of things. This is a good example of very different time-to-find depending on max_len. It might be a good idea to either add a (rare) config for targets with some appropriate "very short but long enough to be interesting" lengths or at least run such outside OSS-Fuzz occasionally. I don't remember what libFuzzer does with corpus entries over max_len... Or maybe try len_control runs?

[agroce]

Actually, looks like the random_max_len (which could be small enough) strategy is enabled 15% of the time in the OSS-Fuzz config anyway.

[agroce]

https://github.com/google/clusterfuzz/blob/578b401b655e95211b6ba9b805986832622b213f/src/clusterfuzz/_internal/fuzzing/strategy.py#L35

[agroce]

.... though that's a random uniform value between 1 and 10000, so at 15% (which is of runs?) I'm not sure how often you'll ever see any target hit with a particularly small max_len. it'll happen, but perhaps quite infrequently if there are targets that benefit substantially from small string runs

[agroce]

Each target will spend < 0.15% of the time with a length of 100 or below, so not much low-max_len fuzzing happening I guess.