High-order bytes in Solidity can clean up storage: Why does it matter?

by ImmuneBytes

Variables are often the most ignored part of any code, be it a software program or a blockchain smart contract. We are talking about them, why? Because they can harm your smart contract as badly as any other attack.

Thursday is here and so are we! The next part of All About Smart Contract Bugs & Security – A cakewalk series. In this blog, we talk about how higher-order bytes can be overwritten in storage, changing the whole meaning of a smart contract. Make sure to check out the other blogs in the series here.

First of… what are high-order bytes?

The bits in a byte of computer memory can be considered as digits of a number in base 2. Translating that the least significant bit represents 1 and consecutively 2´1, 2´2´1, and so on. If two bytes of memory are considered, a single 16-bit number, one byte will hold the least significant 8 bits, and the other will hold the most significant 8 bits. 

The figure depicts the bits arranged into 2 bytes. The byte holding the least significant 8 bits is called the least significant byte, or low-order byte. The byte containing the most significant 8 bits is the most significant byte or high-order byte.

Let’s see why it is so important in a smart contract.

Higher-order byte clean storage, how?

This bug falls under the class of memory allocation and deallocation bugs. The data contained in that piece of memory is mishandled by hackers, resulting in companies losing millions. 

Higher-order bytes are not cleared properly when they’re reassigned, allowing the data within the bytes to be rewritten at the time of execution. When two fixed bytes are compared, the higher-order bits were considered in the comparison. Hence, the values that were meant to be the same were not considered equal. 

All storage types are stored in blocks of 32 bytes, for some types though, the higher-order bits are not cleaned when assigning or editing the data. It then becomes possible to ploy this bug to overwrite data that is stored in variables. 

A real-world example of this bug is yet to be discovered. However, one must be aware of the preventive measures to be taken.

Preventive Measure

This vulnerability, if present in the smart contract, allows the attacker to write to storage variables during runtime. It affects every common data type in the language. It is thus suggested by the Ethereum developers that people completely rewrite contracts.

This was our short and crisp analysis of higher-order bytes and how they affect the performance of a smart contract. Connect with our team to get your smart contract free of any such vulnerabilities and loopholes that can be mishandled by the attackers.

Tune in next Thursday for Part XIV of this series where we discuss Transferring forward all gas. 

Spread the love

You may also like