
List of the top smart contract vulnerabilities - wepple
Https://dasp.co
======
jjallen
I'll never forget this pull request. Just having these two `internal` keywords
there would have saved $150 million dollars.

[https://github.com/paritytech/parity/pull/6102/files#diff-8e...](https://github.com/paritytech/parity/pull/6102/files#diff-8ea4aa7c2ba715c683bc764337f51585)

A lot of people think "smart contracts" are inherently insecure. I personally
believe that most of the "hacks" were very preventable, if those who had
written the code slowed down to think about what they were doing.

~~~
CJefferson
This reminds me of 'Poya-Yoke', which is (as I understand it) about making
accidents less likely by design. Functions should be carefully chosen to be
externally visible, so why not make internal the default. When designing
contracts, the language should be making every possible effort to be safe by
design.

~~~
pmoriarty
Related to this is the maxim to "make it easy to do the right thing, and
difficult to do the wrong thing".

When applied to programming, a first step towards that could be as simple as
using a safer language, where it's more difficult to shoot oneself in the
foot, and where all sorts of errors are prevented by default.

------
hritzdorf
The new version of securify, which will soon be available at
[https://securify.ch](https://securify.ch), catches 7 our of the 9 mentioned
issues automatically and is free.

I am one of the tool's authors. We went on to found ChainSecurity
([https://chainsecurity.com](https://chainsecurity.com)) in order to deepen
our research and understanding of smart contract security. Feel free to ask
any questions about securify or ChainSecurity.

~~~
seanwilson
Do you have any views on Solidity as a contract language and how suitable it
is for being formally verified? Does it make any properties you want to check
difficult or impossible to verify?

My experience with formal verification is that the further a language is away
from being a pure functional language with easy to check termination, the more
difficult you make life for yourself. You really want a smart contract
language that was specifically created to be easy to formally verify rather
than trying to tack on formal verification later.

~~~
ptsankov1
Note that tools like Securify work directly on the EVM, and are therefore
agnostic to the high-level language the contract is written in. The EVM itself
is not as amenable to formal analysis (no types, explicit function calls,
etc.).

------
asynchrony
Please correct me if I'm wrong, but isn't it the nature of a turing machine
(decentralized or not) to produce an endless series of "unforeseen" exploits?

~~~
tree_of_item
Yes, but even if your language is total you have an analogue of the halting
problem, where instead of analysis being undecidable it just takes an
unrealistic amount of effort.

~~~
asynchrony
My understanding is more hand-wavy than formal, but would the combination of a
total language and some limitation on the total number of instructions produce
a provably predictable language?

~~~
lmkg
Likely not. It takes only a very small number of instructions to implement an
interpreter for a Turning-complete language, and then you can create arbitrary
behavior by passing different input. The number of necessary instructions is
shockingly small, if using something like Binary Lambda Calculus or Subtract-
And-Branch-If-Negative.

------
seanwilson
What ever happened with the frozen funds caused by the Parity multi-sig wallet
bug? Is there a plan to unfreeze them somehow?

~~~
jjallen
Original recovery proposal:
[https://github.com/Musiconomi/EIPs/blob/78abec4751c877e7a12a...](https://github.com/Musiconomi/EIPs/blob/78abec4751c877e7a12a879787b2576cf5349b2b/EIPS/eip-867.md)

~~~
seanwilson
What progress is being made though? This was a huge amount of money that was
frozen. I would have thought something would have been done by now.

~~~
DennisP
At the moment there are no plans. There were some attempts to design an
"upgrade" that would make the funds recoverable while benefiting the platform,
but they had dangerous side effects. A lot of people opposed a targeted
recovery fork, for reasons including:

\- It's not such a large amount that it's a systemic risk.

\- The hack was arguably enabled by negligence; the contract was changed after
its last security audit, hacked, changed again and still didn't get a new
security audit, and only after that the funds were frozen. Strong incentives
to be more careful are probably good. Forking every time somebody's negligent
could get messy.

\- The DAO hack involve an attack that was new to most people in the
community, and even the tutorial code on ethereum.org was vulnerable to
similar hacks. These hacks were more in the nature of simple oversights,
enabled by overly complicated code. Good auditors would probably have found
them.

\- The largest loss of funds was to the entity that made the contract (or a
related entity anyway). That entity also said they had plenty of other money
for their project.

\- Most of the remaining losses were to ICOs, who should have gotten competent
advice to avoid this contract (given the first hack and lack of audit), and
who've demonstrated fundraising ability so could conceivably get bailed out by
their own investors.

\- Despite heavy criticism from certain quarters about Ethereum's supposed
lack of immutability (after the DAO hack), immutability actually is a strong
community value. Some people supported the DAO fix on the grounds that it was
early days, but feel that the network is more mature now.

------
jeffreyrogers
I heard someone say that smart contracts don't eliminate the need for a
trusted party, they just make that trusted party a program, since most people
don't fully understand what these contracts are saying. At least when you get
a lawyer to write-up a contract the lawyer is usually familiar with the law,
and how similar contracts are interpreted by the court system.

------
aiCeivi9
The timeline for the first one is just sad.

------
homakov
1\. front running has nothing to do with TOCTOU/race conditions. the real race
condition example would be reentry attack actually.

2\. #9 has nothing to do with "off-chain issues". Off chain has very clear
context and refers to layer 2 solutions for scaling. No need to call a website
bug "off chain issue".

