
Our suite of Ethereum security tools - wglb
https://blog.trailofbits.com/2018/03/23/use-our-suite-of-ethereum-security-tools/
======
kerng
I have coded Solidity a bit, and it's pretty obvious the language is not up
for the task. I mean its 2018 and we have a brand new "business language" that
can have overflows and stuff. It's like making all mistakes over again. Many
problematic vulnerabilities and lost funds (e.g. parity freeze) is due to this
language being not the right choice. If "code is law" we need a better
language and not just tooling on top of a broken one.

I don't know, how about Cobol? I'm serious, that was designed as business
language at least.

~~~
rusbus
Is it possible to implement a compiles to solidity or compiles to evm language
with better properties? I assume yes.

~~~
mike-myers
Yea, Solidity is not the only language of code that compiles to EVM bytecode.
There are other languages that also do so: Serpent, LLL, and Viper. "Better"
is subjective, but it looks like Viper is intended to be more audit-able. But
it's also still a work in progress.

Serpent and LLL are apparently lower-level than Solidity.

[https://steemit.com/ethereum/@balzss/the-many-languages-
of-e...](https://steemit.com/ethereum/@balzss/the-many-languages-of-ethereum-
clearing-up-misconceptions-about-solidity-serpent-vyper-and-the-evm)

~~~
davedx
Bamboo looks quite interesting. I think it’s mainly focused on modelling the
state changes smart contracts undergo more explicitly.
[https://github.com/pirapira/bamboo](https://github.com/pirapira/bamboo)

------
realusername
I feel most of these vulnerabilities should not exist in the first place. When
you create a language that's specifically made to handle money that also is
immutable (so without possibility to rollback), it should be generally a bit
more secure than the average language.

The VM should be protected against integer overflows and functions should be
protected by default, I don't really get those design choices.

~~~
joshwatson
Oh it’s even worse than overflows. The order of operations of Solidity isn’t
even the same as most languages, which will undoubtedly lead to issues at some
point.
[https://twitter.com/esultanik/status/976186942625861632](https://twitter.com/esultanik/status/976186942625861632)

~~~
Buge
I fail to see the problem in that code.

    
    
        (1 | 0 < 1)
    

evaluates to False in python as well.

~~~
b6
There's a, what, 50 year tradition in C of boolean ORs evaluating left to
right. I don't know truthiness rules in Python, but the REPL just told me 1 is
not False. So we have something that is not False ORed with True. What is your
thought process?

~~~
Buge
>ORs evaluating left to right

There is only a single bitwise OR here, and no logical ORs. Whether they are
evaluated left to right or right to left makes no difference in the execution
of this expression.

Swap it left and right:

    
    
        (1 > 0 | 1)
    

And you'll see that C still gives you 1, and Python still gives you False.

>we have something that is not False ORed with True

No. We have (in the original Python equation) 1 ORed with 0. That results in
1. Then that resultant 1 is compared ('<') with 1. That comparison results in
False .

The difference between Python and C is that in Python '|' has higher
precedence than '<', but in C '<' has higher precedence than '|'. Dennis
Ritchie admits that this is a mistake in the C language[1]. Python (and
Solidity) have corrected that mistake.

The reason that '|' should have higher precedence than '<' is the same reason
that '+' should have higher precedence than '<'. Namely, people want to do
arithmetic calculations ('|' and '+') then compare the result of those
calculations ('<' and '=='). There is essentially no situation where it is
useful to have '<' have higher precedence than '|'.

[1] [https://stackoverflow.com/questions/4685072/operator-
precede...](https://stackoverflow.com/questions/4685072/operator-precedence-
bitwise-lower-than)

~~~
b6
Thanks for the explanation. I'm not familiar with Solidity and was assuming
the intent was logical or.

------
crispyporkbites
There is a LOT of things to cover here, this tool chain is just the tip of the
iceberg. The EVM is open source on steroids - not only is the code open source
but every cpu cycle, memory access and IO activity is executed in the open,
and replayed across thousands of nodes by anyone, anywhere as a necessity.

This is probably one of the most exciting paradigm shifts in recent times,
being able to call services / functions that are cryptographically verified is
an incredibly powerful tool, and may one day become a standard part of the web
stack. There is still a long way to go, but what a time to get involved!

------
monocasa
Are there no frameworks for formally validating smart contracts or using
thereom provers? The small code size, non Turing completeness, and extremely
high penalty for failure seem to all align.

Hell, even in an offensive sense it makes sense. [https://anee.me/solving-a-
simple-crackme-using-z3-68c55af7f7...](https://anee.me/solving-a-simple-
crackme-using-z3-68c55af7f7b1)

~~~
jbverschoor
[https://github.com/OpenZeppelin/zeppelin-
solidity](https://github.com/OpenZeppelin/zeppelin-solidity)

~~~
monocasa
As much as they use 'secure' in their README, I don't see any real evidence of
that in their code.

When I'm looking for formally methods, a package.json is a bad sign.

------
tyoma
Hopefully these and other smart contract analysis tools can become a part of a
CI/CD system for Ethereum. It seems like that would have prevented some of the
massive losses due to simple programming errors.

------
mannykannot
While working at the level of code can undoubtedly reduce the number of
errors, it is not enough to solve the significant risk of making logical
errors in contract design.

