Interview with Ralph Pichler who discovered the Ethereum fork vulnerability

Ethereum’s Constantinople Upgrade has been delayed unexpectedly. The decision was made after a critical vulnerability was discovered by Zurich based smart contract auditing company ChainSecurity. They reported that the Constantinople Upgrade would allow reentrancy attacks as an unwanted side effect of cheaper gas costs. You can read details on what was wrong with the code of the Constantinople Upgrade in ChainSecurity’s in-depth blog post.

Ralph Pichler, Ethereum expert, founding member of RIAT Institute for Future Cryptoeconomics in Vienna and advisor for Bitpanda and Pantos played a significant role in the discovery of the vulnerability. He kicked off the initial discussions which highlighted the new attack vector and which eventually led to the discovery of the vulnerability.

We sat down with Ralph to talk about his thoughts and findings on the Ethereum Constantinople security hole.

Bitpanda: Can you summarise the current situation? What is the security hole in the Ethereum Constantinople upgrade code about?

Ralph Pichler: It was discovered that one of the changes for Constantinople allowed contracts to modify storage even if they were called with no gas. Previously, changing storage did cost at least 5000 gas which is more than the 2300 gas available to contracts by default. With Constantinople it is possible to change storage for just 200 gas in some circumstances, which fits well within the limit. As a consequence, contracts which relied on 0-gas calls (.transfer and .send in Solidity) to change state might have faced security issues.

What could have gone wrong, in case it wouldn’t have been detected before the actual upgrade?

In the worst case some contracts may have been exploitable and caused loss of fund. No vulnerable production contracts were found prior to the decision to postpone, but I believe somebody found a vulnerable one since then.

How did you discover the vulnerability?

I first thought about it when I saw that it would only cost 200 gas, but I thought that it probably wouldn’t work since it seemed too obvious for nobody else to notice. It was only much later during a discussion with ChainSecurity that I realised that it really might have gone unnoticed.

What have you learned from this?

I think my biggest takeaway is that one should report possible issues even if it seems too obvious to not already be considered.

What do you think are the next steps for Ethereum now?

There will be a new date for the Constantinople hardfork soon, this time probably without the EIP in question. We might still see it some other from in the future, people are already discussing modifications that don’t introduce the same problems.

                                                                .     .    .

We also asked Michael Borkowski, operational lead of the TAST research project within Pantos, to give us feedback on the impact of the storage modification vulnerability for Pantos.

Bitpanda: How does this vulnerability impact Pantos?

Michael Borkowski: According to our current knowledge, the vulnerability causes contracts which use on transfer or send calls to potentially be susceptible to attacks, where the callee is wrongly allowed to manipulate state. As of now, we do not use transfer and send calls within the Pantos prototype we are developing, so we are not directly impacted by this issue. However, it is crucial to keep in mind that such changes might happen in the future. This time, we were lucky enough for this vulnerability to be uncovered, but this does not mean that a similar situation might arise at a later point. This shows once again how crucial it is to use extreme caution when developing blockchain technologies. Trusting a contract you call must be a well-reasoned decision, and defensive measures (such as disallowing state manipulation in certain scenarios) are advisable.