Full Report
Simple Serialize (SSZ) is used by Ethereum clients in the consensus protocol and in P to P communication. The SSZ soundness depends on the involutive and injective property. The involutive property is that serializing a value then deserializing it will resolve to the original value. The injective property is that if A=B then serialized A should also equal serialized B. Some of these properties didn't hold, which resulted in a vulnerability. SSZ relies on offsets and lengths for encoded objects. For the serialized block information we want to send (SignedBeaconBlockDeneb) the object, there are multiple layers of nesting in order to properly transfer all information. Within a block, is a body. To go from the block of offset 0x64 and then the offset of the body in the block type of 0x54 puts us at 0xB8. The body contains its own set of values that have their own offsets in the block information. With this whole system of offsets to find objects, the serialization system works well. It should be a requirement that there are no gaps in the data. However, by changing the offsets around for objects (which have set lengths), ghost regions can be inserted into the data. By itself, this isn't a huge deal. However, not all clients function this way. Many of them will reject the block information outright even. Since Prysm acts one way (shown above) and Lighthouse acts another that rejects it, this will lead to a consensus failure in the protocol. Doing this does not modify the hash tree root at all either. When setting this up locally, it resulted in the network just stopping entirely. An interesting takeaway from the author: "Paradoxically enough, the same design choice of favoring multiple implementations has brought a new vulnerability class, that of “consensus bugs”, on which we hopefully shed some new light." Overall, a great article on a subtle difference in the Ethereum serialization code.
Analysis Summary