\n<\/p>\n
This blog post provides\u00a0an update on\u00a0our findings following the discovery of the storage corruption bug last week. In\u00a0summary, the bug\u00a0was\u00a0much less severe than we initially thought. The small number of affected contracts we found is either only exploitable by the owner, or the exploit can only cause a disruption in the user interface and not in the actual contract logic. All exploitable contracts\/dapps we reviewed can be fixed without having to upgrade the contract itself. Of course, please still check your contracts to be safe.<\/p>\n
Following the discovery of the storage corruption bug in the Solidity compiler and the realization that it may\u00a0have serious effects on already-deployed contracts\u00a0that\u00a0cannot be updated, we started analyzing how common the bug is and how exploitable contracts can be addressed.<\/p>\n
We focused on contracts with source code published on etherscan because important or popular smart contracts usually have their source code published there in order to gain trust from their users, who can then verify the compilation. Furthermore, if the source code is not available, it is also much harder for an attacker to find a suitable exploit. Finally, contracts that are privately used (and thus do not require publishing their source code) usually check that they are called from a certain address, and thus an attacker has no means to write to their storage.<\/p>\n
In order to automate the process of checking all contracts on etherscan, we created a modified version of the Solidity compiler that can automatically detect the conditions for triggering the bug. This technique\u00a0has already reduced the number of potentially vulnerable contracts\u00a0to 167. We then manually checked\u00a0those contracts for\u00a0potential corruption of storage that would make them vulnerable to attacks.<\/p>\n
It turns out that only ten\u00a0contracts were\u00a0vulnerable, so\u00a0we were able to contact most of the contract owners\/developers. Seven out of ten\u00a0of those contracts\u00a0are only exploitable by the owner in that they are allowed to change certain parameters outside their permitted\u00a0range,\u00a0or allowed to unlock a previously locked contract. One contract is exploitable by unprivileged users but have other major flaws in its design. The other two\u00a0contracts found to be\u00a0exploitable by unprivileged users either provided no advantages if exploited or only\u00a0affected\u00a0the user interface.<\/p>\n