Protect against OOB offset in variable list SSZ decoding

[paulhauner]

Issue Addressed

NA

Proposed Changes

As raised by @pventuzelo during fuzzing (thank you Patrick!!), SSZ decoding was failing to ensure that all offsets were in-bounds. This resulted in trying to allocation a billion-element Vec which caused a panic due to a failed memory allocation.

Ironically, I documented this bug (SSZ Offset Exploits #4) last year but failed to enforce it here. 🤦‍♂️

This PR:

• Adds a fix for this bug.
• Makes DecodeError more granular to be more certain that tests trigger certain code paths.
• Add simple checks to stop VariableLists/FixedVectors from decoding lists that conflict with their variable/fixed sizes.
• Only do a Vec::with_capacity for objects that specify a maximum length.
• Fixes a bench that wasn't compiling (I needed it to check the performance impacts of not allocating)
• Adds the pretty-ssz CLI command which allowed to me to parse the SSZ file from @pventuzelo. It should parse some SSZ then pretty-print it as YAML, but is useful for finding errors in SSZ decoding.
  • The command I used was lcli -s minimal pretty-ssz SignedBeaconBlock crash1_min.ssz

[paulhauner]

This is a great catch by the fuzzer!

I had written a test that I thought covered this case:

lighthouse/eth2/utils/ssz/src/decode/impls.rs

Lines 573 to 576 in 5a6e904

	assert_eq!(
	<Vec<Vec<u16>>>::from_ssz_bytes(&[8, 0, 0, 0, 9, 0, 0, 0]),
	Err(DecodeError::OutOfBoundsByte { i: 9 })
	);

However, I was getting an Err here not because 9 is out-of-bounds, but instead because 9
is not a clean multiple of BYTES_PER_LENGTH_OFFSET:

lighthouse/eth2/utils/ssz/src/decode/impls.rs

Lines 421 to 427 in 5a6e904

	// The fixed-length section must be a clean multiple of `BYTES_PER_LENGTH_OFFSET`.
	if next_variable_byte != num_items * BYTES_PER_LENGTH_OFFSET {
	return Err(DecodeError::InvalidByteLength {
	len: next_variable_byte,
	expected: num_items * BYTES_PER_LENGTH_OFFSET,
	});
	}

What we really needed to test this functionality was:

assert_eq!(
    <Vec<Vec<u16>>>::from_ssz_bytes(&[8, 0, 0, 0, 16, 0, 0, 0]),
    Err(DecodeError::OutOfBoundsByte { i: 16 })
);

I think there's a lesson to be learned about being specific with error types. If I had more specific DecodeError variants here then I would have noticed that we were getting the wrong error!

[michaelsproul]

Looks good. The updates appear to faithfully implement all the checks from the hack.md doc, while preserving existing behaviour.