{"id":6618,"date":"2018-04-26T21:11:14","date_gmt":"2018-04-26T21:11:14","guid":{"rendered":"https:\/\/davidgerard.co.uk\/blockchain\/?p=6618"},"modified":"2020-03-06T23:00:00","modified_gmt":"2020-03-06T23:00:00","slug":"smart-contracts-stupid-humans-new-major-erc-20-token-bugs-batchoverflow-and-proxyoverflow","status":"publish","type":"post","link":"https:\/\/davidgerard.co.uk\/blockchain\/2018\/04\/26\/smart-contracts-stupid-humans-new-major-erc-20-token-bugs-batchoverflow-and-proxyoverflow\/","title":{"rendered":"Smart contracts, stupid humans: new major Ethereum ERC-20 token bugs BatchOverflow and ProxyOverflow"},"content":{"rendered":"

Smart contracts are fundamentally bad software engineering,<\/a> part 666 of a never-ending series\u00a0\u2014 PeckShield<\/a> have been running an automatic scanner on the public Ethereum blockchain:<\/p>\n

Built on our earlier efforts in analyzing EOS tokens, we have developed an automated system to scan and analyze Ethereum-based (ERC-20) token transfers. Specifically, our system will automatically send out alerts if any suspicious transactions (e.g., involving unreasonably large tokens) occur.<\/p><\/blockquote>\n

They’ve found a couple of beauties, which they’ve branded “BatchOverflow” and “ProxyOverflow.” These affect multiple ERC-20 tokens \u2014 which are the basis for almost all ICOs.<\/a><\/p>\n

The root cause is that smart contract coders just copy each other’s code a lot<\/i>, because who needs formal methods when you can cut’n’paste’n’bodge.<\/p>\n

BatchOverflow<\/h3>\n

On Sunday 22 April, PeckShield detected<\/a> two transfers of\u00a02255<\/sup> \u2014 or, in hexadecimal, 0x8000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000\u00a0\u2014 BeautyChain (BEC) tokens.<\/p>\n

If you add these two numbers, you get 2256<\/sup>, a 257-bit number \u2014 or, since we’re working in Solidity, which has 256-bit integers, you get an overflow, and the counter cycles back around to 0.<\/p>\n

This occurs in a function called batchTransfer()<\/tt> \u2014 a version of which is used in quite a lot of ERC-20 token contracts, because smart contract programmers copy code from each other lots and lots:<\/p>\n

\"\"<\/a><\/p>\n

In line 257, amount is cnt<\/tt> times _value<\/tt> \u2014 and if _value<\/tt> is a huge number, this can easily overflow. This then passes the sanity checks in lines 258 and 259.<\/p>\n

Finally, in lines 262 to 265, the balances of the two receivers will have the very large _value<\/tt> added to them.<\/p>\n

batchTransfer()<\/tt> is not part of the ERC-20 standard, but it’s widely used \u2014 so, despite the CVE (CVE-2018-10299<\/a>) specifying only BeautyChain, PeckShield found over a dozen tokens vulnerable to this exploit.<\/p>\n

ProxyOverflow<\/h3>\n

The CVE report for ProxyFlow (CVE-2018-10376<\/a>) specifies only one ERC-20 token, SmartMesh (SMT) \u2014 but it affects multiple tokens.<\/p>\n

PeckShield first detected the ProxyOverflow exploit<\/a> in MESH, when someone transferred 6.5\u00d71076<\/sup> tokens\u00a0\u2014 or 0x8fff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff in hexadecimal \u2014 with a transfer fee of 0x7000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0001.<\/p>\n

If you add these values, you get 2256<\/sup> \u2014 which overflows and the counter cycles back to 0 again!
\n<\/em><\/p>\n

Here’s the code this was exploiting:<\/p>\n

\"\"<\/a><\/p>\n

_fee<\/tt> and _value<\/tt> are both set by the sender. If you put in values that add to more than 256 bits, the result wraps around. In this case, it adds to 0. This bypasses the sanity check in line 206. The huge number of tokens in _value<\/tt> are transferred to the attacker in line 214, and a huge _fee<\/tt> goes to msg.sender in line 217.<\/p>\n

This pattern is found in lots<\/em> of ERC-20 tokens! PeckShield lists MESH, UGToken, SMT, SMART, MTC, FirstCoin, GG Token, CNY Token and CNYTokenPlus.<\/p>\n

The consequences<\/h3>\n

OKex first suspended trading just on BeautyChain, but has now suspended all ERC-20 tokens,<\/a> as has Huobi Pro.<\/a> A pile of other exchanges are still allowing trading \u2014 and there’s still decentralised exchanges such as EtherDelta,<\/a> which can trade any<\/em> ERC-20 token.<\/p>\n

SmartMesh will be destroying the counterfeit tokens<\/a> \u2014 remember that the underlying Ethereum blockchain may be (somewhat<\/a>) decentralised, but ERC-20 tokens themselves can be under absolute central control \u2014 and BeautyChain are looking into what they can do here. There’s no word as yet from the other tokens.<\/p>\n

Fixing these bugs will require redeploying the contracts \u2014 assuming they have been coded to be upgradable. The usual method is per the Ethereum white paper:<\/a><\/p>\n

Although code is theoretically immutable, one can easily get around this and have de-facto mutability by having chunks of the code in separate contracts, and having the address of which contracts to call stored in the modifiable storage.<\/p><\/blockquote>\n

Even then, it can be a massive pain in the backside \u2014 and isn’t a panacea, as Parity discovered.<\/a><\/p>\n

 <\/p>\n

\"\"<\/a><\/p>\n

 <\/p>\n

Smart contracts, stupid humans<\/h3>\n

As I spent all of chapter 10<\/a> of the book<\/a> attempting to bludgeon home \u2014 smart contracts are almost impossible for humans to program safely.<\/p>\n

The value proposition of \u201cimmutability\u201d is that nobody can mess with your contract once it\u2019s been deployed. But this is another way of saying “bugs can’t be fixed, ever.”<\/p>\n

The first really famous smart contract, The DAO<\/a> in 2016, crashed and burned when it turned out to have a security hole that couldn\u2019t be fixed in time and it got hacked.<\/p>\n

(Smart contract security hits a worst case scenario \u2014 everyone can see your financial code and poke it for security holes, but you can’t quickly deploy fixes.)<\/p>\n

The eventual fix for The DAO hack demonstrates the other problem with smart contracts: the \u201cimmutable\u201d system containing the smart contract was suddenly considered changeable the moment the big boys risked losing money.<\/p>\n

Solidity, the standard Ethereum smart contract language, is a JavaScript derivative, so as to bring smart contracts to middling programmers. Ethereum successfully leveraged Worse is Better<\/a> \u2014 an imperfect solution that’s easily reproducible will spread much more virally than the perfect, painstaking solution \u2014 to become the first smart contract platform to be widely used, with almost all its smart contracts written in Solidity.<\/p>\n

But humans are really <\/i>bad at coding without error. Programs that can’t be fixed once they’re deployed need formal methods, functional programming and preferably a non-Turing-complete language.<\/a> You need to program like NASA programming spacecraft.<\/a><\/p>\n

Programs that cannot<\/em> be allowed to have bugs … can’t be bodged by an average JavaScript programmer used to working in an iterative Agile<\/a> manner. And particularly not a programmer who’s copying and pasting code like they’re still doing web site front ends and hitting StackOverflow for cribs.<\/p>\n

And you can even deploy fully-audited code that you\u2019ve mathematically proven is correct\u00a0\u2014 and then a bug in a lower layer means you have a security hole anyway. And this has already happened.<\/a><\/p>\n

Remember that not even Gavin Wood \u2014 the Ph.D computer scientist who wrote the Ethereum protocol specification<\/a> \u2014 could write a smart contract safely enough not to lose hundreds of millions of dollars of his startup’s ICO funds in the Parity wallet disaster last November.<\/a> What makes you sufficiently sure that you can?<\/p>\n

 <\/p>\n

\n

Some of us called out the Solidity overflow issues a long time ago.<\/p>\n

This is me back in July 17, 2017. pic.twitter.com\/3799yJTR4b<\/a><\/p>\n

— Emin G\u00fcn Sirer (@el33th4xor) April 25, 2018<\/a><\/p><\/blockquote>\n