Integer Vulnerabilities that Mythril can Detect but Fail to Detect about mythril

[norhh]

A quick tip, you can execute specific transaction sequences with mythril using:

./myth -v4 a t.sol --solv 0.5.0 -t 3 -m IntegerArithmetics --transaction-sequences [[0x095ea7b3],[0x79c65068],[0x79cc6790]] --disable-dependency-pruning

Just don't forget to disable dependency pruning. You can put a list empty for unconstrained execution for that transaction, or you can add stuff to the list for more functions. Use function signatures from solc --hashes

Coming to the underflow question
The code has the following check for burnFrom:

require (balance[from] >= value);

Which means value can only be less than or equal to balance[from]

You can also observe the following:

mintToken() ->
         balance[target] += amount; // overflow
         totalSupply += amount; // overflow

The totalSupply only increments along with balance. So, no amount of balance can underflow it directly. totalSupply cannot underflow without overflowing first (which is not possible in 3 transactions)

In the case when totalSupply is set to 1. We only need 1 transaction to overflow, as uint256_max + 1 will overflow to 0. It's easy to underflow 0. This is not possible in 3 transactions as in above case.
You can check this with the following command:

./myth -v4 a t.sol --solv 0.5.0 -t 4 -m IntegerArithmetics --transaction-sequences [[0x095ea7b3],[0x79c65068],[0x79c65068],[0x79cc6790]] --disable-dependency-pruning

Increase solver timeout if need be. With 4 transactions, Mythril finds the vulnerability.

[qiana0223]

Indeed, the underflow vulnerability is detected. Here is a screenshot showing the detailed information of this vulnerability.

But I am still not clear about the reason:
case 1: executing the sequence: [[approve],[mintToken],[burnFrom]] can not detect the underflow.
totalSupply =0+amount2-value3
case 2: executing the sequence: [[approve],[mintToken],[mintToken],[burnFrom]] detects the underflow.
totalSupply =0+amount2+amount3-value4
Note that amount2, amount3, value3, and value4 are symbols of type unit.

In case 2, if I understand correctly, amount2+amount3 can cause overflow and thus can have a value 0. Then, 0-value4 is easy to determine that there is an underflow.
On the other hand, in case 1, amount2-value3 is not easy to determine? is the "easy" means that the constraint solver can easily reason?

[norhh]

On the other hand, in case 1, amount2-value3 is not easy to determine? is the "easy" means that the constraint solver can easily reason?
that's not the case. As you can see from the code below:

mintToken() ->
         balance[target] += amount; // overflow
         totalSupply += amount; // overflow

A single call to mintToken will be such that balance[target] = totalSupply = amount2. As totalSupply and balance[target] are set to 0 initially.

And balance[target] decides value_3:

       require (balance[from] >= value); # "from" would be "target" in previous tx

Which implies it's equivalent to balance[from] = TotalSupply >= value_3 for your tx sequence, or amount2 >= value3.

In case target in previous tx is not same as from
TotalSupply >= balance[from] >= value.
Which will still lead to amount2 >= value3

[qiana0223]

Thanks so much for the detailed explanation. I get your point.