[Music]
so good afternoon earlier this year I
started the first underhanded solidity
coat contest and the goal was to write
code that looked innocent on the surface
but actually concealed a sinister
purpose the reason that I started this
was to encourage deeper thought about
smart contract coding practices and and
good code and to help highlight
potentially issues with unobvious
features and solidity and and smart
contract programming so in an attempt to
capture the sort of current zeitgeist
the theme was token sales and
participants were challenged to write a
contract that was in some way involved
with token sales and looked innocent but
had some advantage for the person
running the token sale and ideally the
sinister purpose should be by ignored by
an auditor or if it was discovered then
easily excusable or explainable as an
innocent mistake and so I have here the
three winners of the contest this year
we have Joelle who came in third Richard
who came in second and Martin who came
in first and so I'd like to start the
our discussion about smart contract
security by asking each of the panelists
to describe their winning salute winning
entry and what they think is a novel
about it so would you like to start
sure well my entry is a proposal for a
Dutch auction crowd sale so in this
model the sale starts with really high
price per token that decreases
continually as the as the patent as the
time passes so buyers can enter the sale
in whatever time the issue the price is
fair the CEO ends or when either the the
time finishes or they cut the door sorry
or the capped is reached so the thing is
I made use of a feature of solidity that
is that anyone can forcibly send error
to a contract without tricking code
execution so in that scenario
the co-owners could sneak in some header
during the sale to inflate the token
price making the touch the traction and
earlier so if you couple that with for
example a min table token that is a
token that you only mint amount of token
that was bought
you can like really inflate the token
price because you put money on the on
the auction but you don't mint tokens so
you're raising valuation of the token
artificially irregardless of marketing
interest and another retail is you can
kind of use this as an as an influence
it because if people are watching the
sale and they see that it's it's
reaching the cap really fast they might
want you getting earlier than they would
if in normal conditions so it's an kind
of effective way to manipulate market in
your favour using this this little
feature right and Richard would you
describe your submission okay testing
there we go
so very similar I actually didn't know
about the suicide bug which allowed you
to get money into a contract with a code
execution but it basically uses the same
idea which is there was a so the basic
idea of the contract is you have a crowd
sale and the the runner of the the
runner yeah the issuer of the token gets
one either the first week to ether the
second week for the next week so on and
so on the idea being that if they're not
doing what you expect you can kind of
yank your money back from them it comes
down to using this stop balance and so
again as long as the contract isn't
executing as you expect this stop
balance can never be more than the
amount you received
unlike the suicided method which again I
don't know about but I have more clever
solutions now if I was new of that the
basically you compute the address the
contract is going to live at before you
deploy it send ether to it and now you
deploy the contract at
now the contract actually is breaking
the invariant that this stop balance is
strictly less than the amount it thinks
it has great
and finally Madame's so in my entry I
I'm gonna start by describing the bug my
entry is based on a bi encoding and how
solidity handles a bi decoding in run
time maybe everyone doesn't know that
actual the EVM and the code in a
contract doesn't really have a notion of
methods that's an invention on top of
the EVM so on the fly
some bytecode determines what method is
called and what the parameters are and
this is encoded by a ABI and certain
types of parameters such as dynamic
dynamic length arrays have a length and
that length is not enforced by the
decoder so it's possible I noticed to
specify a very very large length and
make the this value overflow and that's
what I kind of designed my entry around
and it was a bit difficult because I had
to make sure that during a loop
I can't loop against the size but still
use the size to somehow give a kick back
to the attacker and in the end it became
a kind of a round table where you can
round table Dao like thing which you can
pay for try to get a seat on this round
table and submit multiple bits and thus
get the dynamic arrays in there and what
I think was pretty good about that entry
is that this exploit is basically not
possible to exploit
using standard tools you need to
generate your own ABI your little bytes
of data in order to exploit this and I
think it would be very difficult for
solidity contract developer or auditor
without deep insight into other VM
functions to actually find the
vulnerability so first of all in a
question for any of the panelists would
like to answer which is what should
smart contract auditors be looking for
in order to try and to take these sort
of underhanded tricks I mean and I think
in the case of our entries if you see
this stop balance anywhere it should be
I mean this means wrong but it's
certainly a red flag that you're
accessing data that may or may not be
what you expect it to be to complement
on these there are a few things that tip
me off one example is random numbers
because it's usually pretty hard to
generate random numbers and it that kind
of indicates that it's a point of
failure external calls are also a kind
of security edge because you know you're
calling strong external contracts so
it's the thing it's the kind of thing
that I start looking after when I start
looking at a contract yeah I would like
to add to that that what you really kind
of should be looking for one of the
things is are these assumptions and
they're mainly implicit assumptions that
are made and it's easy to gloss over
that and not notice it but really try to
investigate where are the implicit
assumptions here and in your cases are
just the implicit assumption is that the
balance is zero at the entry or at the
exit and start to like make these
assumptions explicit and then see can I
violate this assumption in any way shape
or form and just to add my own note do
you some caution is required there
unless if you made the assumption that
the balance is zero and then you've
coded in an assertion the balance is
zero then now an attacker has a
mechanism by which they can actually
just disable your contracts by sending
someone's to it exactly so so I I didn't
mean that you should
you know assert that thing necessarily
but instead question is this the valid
assumption that can be made or can this
be exploited by an attacker so next
question again for any of you is what
sort of improvements would you like to
see to tolling in two languages and and
other infrastructure pieces in order to
make it easier to take these issues and
and help prevent them from happening in
the first place so on the tooling front
I was at the she's me at the breakout
session earlier and saw some
presentation about a Yenta and about
sakura phi and for a long time I've had
this feeling that there are these tools
to with just analysis on bytecode and
either detects vulnerabilities or
provides some kind of analysis on the
bytecode and they're on the kind of
fringes but they're not right now in the
in the tool set of most the app
developers and that's what I think
should be added so that as part of your
development process you can get some aid
by these tools which operates preferably
on byte code which would also help to
protect against
failures and better within the solidity
and in this step from source code to
byte code
all right so you'd say more maturity and
the tools were already building and an
easier integration yes in zero
integration in the into the developer
pipeline of these tools yeah anyone else
I mean I would out yeah that's basically
why I say like it's really important we
have better testing tools as well like
being able to run a huge suite of test
cases against both expected behavior and
unexpected behavior if you feed bad data
in do you still get a result and now
you've corrupted something or like I
just think we need more and I think the
tools are there I think it's just
they're not easy to use it's not easy to
make a test we can just run through them
you you you see all these contracts they
have about three test cases and it's
testing if I send money to this not like
this thing doesn't work yes passed and
so three test cases this should not be
sufficient to validate that this
contract you're sending billions of
dollars to is is working and yeah it's a
and just in addition to that I would
like to see some way to test in large
scale because most projects when it
tests some behavior they used like the
minimum the viable number of players in
the contract to test but if a contract
work like with ten transactions will it
work with ten thousand or a million and
there's no H test that there is but
there is no no one doing that right now
so I would like to see some some work on
that alright and if you each could give
one piece of advice to somebody writing
a smart contract on something to look
out for or something to be careful about
what would it be I would I would give a
device that sometimes the code work has
intended but they make mechanisms behind
it or not so sometimes it's not about
the codes about the way you design your
contracts about how we interact people
interact you don't consider that that
might be a malicious player
interacting with it that someone is like
no bad behavior and it's kind of easy to
oversee that and just like because it
passes the test it works but you have to
account for like bad people right now I
again will just mimic the same thing I
mean formal verification everyone thinks
is this magic bullet but there's still a
gun the game here you have to think
about I mean we've heard about minor
front-running this is a great example of
the type of things that the code is
doing exactly what you expected to do
there's nothing being lied about about
what's happening is just people who have
weird connections to what's going to
happen have too much say and can tweak
what you expected to game theoretically
or mechanism design wise work yes my top
recommendations would be no the EVM in
detail and keep it simple don't build
like very large inheritance models
because it just try to keep it simple
and much easier to audit last one
dropped out all right so I'd like to see
are there questions from the audience
for the panelists if you raise your hand
and shout it out I'll repeat the
questions who've Rankin here
nobody has any questions about smart
contract security okay
hi I've seen like it many companies or
individuals does like code auditing but
there's no much standard if you want to
say like if we're gonna have a code
auditing standard or something what kind
of stuff should be understand our list
so effectively you're asking how would
you recommend people go about auditing
code is there is there best practice for
that is that right yes best practices
for auditors and audits so I'll say
there's been some work in that direction
I think mainly done by consensus they've
put together a best practices guide but
as I mean in general it's the field is
not yet mature it's taken a lot of years
to even get kind of like rough web
application security guidelines going
and still evolving and it's the same
thing here new things get added as hacks
happen so yeah there's I don't know it's
it's going to continue to evolve there
is one but it's not it's not all
complete one other thing I agree we need
something like that we also need some I
would like the idea that auditing should
be a fairly public type thing I've done
many audits and often times I'll say
like oh well your your can be exploited
if this character who owns this address
does this thing and often I hear there's
like oh that's the lead developer he
won't ever do that to us and that's not
counting for him a being malicious him
or her or them being hacked and their
computers private key being stolen so I
had to offer inhere in response to a
completely valid audit well that won't
happen and that's you're losing some of
the value of blockchain
so well we're talking about audits at a
very high level would you describe how
you go about an audit like how do you go
from here's a big chunk of code to -
here's a finished audit report I would
say I mean usually to be fair most most
audits I feel aren't actually large
amounts of code like the Dow looked way
larger than anything I've needed to
audit before that was like a lot of code
for what I was doing but even with one
issue or thing that actually makes this
describing this process a little bit
easier is usually it's very modular
usually there is a wack ton of contracts
that are all inheriting for each other
using each other so it makes it easy to
kind of break it down and and yeah I
usually just start at the top go through
it and probably call you browse
Wikipedia you hit like some good class
you're like I don't wanna means and so
you jump with that file and you go
through that and it is then you start
popping the stack and get up and you
have to go over it a few times before
yeah that's a good point the first thing
you do is really understand what the
code is doing trying to audit code that
you're kind of like well I think it kind
of does this you really need to
understand the assumptions the rest of
the code is making I mean going back I
guess to a previous thing another like
thing I often see is let's say you're
counting the number of elements inside a
mapping I often see you know plus plus
and then set but this isn't or in the
other direction - - and then set to zero
and this is a huge problem because if
you set the same thing twice you now
think the mapping has to bytom's in it
and so it's important to kind of be able
to trace back and see well what code
paths can get here to even do this maybe
they're guarding it somewhere else maybe
they're not maybe they should be
checking like gas efficiency may or may
not come to play so I don't know if I
really answered the question but what
seemed like good search do you have
anything to add matter no that's that
sounds very close to what I'm doing I
mean it's very it's extremely time
consuming to do it this way but really
get to know the code read it read it
read it read it until you know it's
forwards and backwards
and during that and try to have this
aggressive mindset where you know that
there are flaws in it you just need to
find them other questions from the
audience shout and I'll repeat oh no we
have a microphone hi so we heard from
Piper yesterday about package management
for a solidity and in Python as well are
you guys or anyone else looking into how
we know if we can trust those packages
especially as the standard library might
be replicated with different package
sets obviously today in the development
world we just hope the code works and
then we realize it it doesn't which may
not be as big of a deal when it's not
solidity well that's an interesting
question and just will to add there is
also the question that if you can we
trust the standards because a lot of
contract interacts with tokens for
example and no one accounts for a
malicious token that can implement this
standard we can modify in some some way
that exploits the the other counters so
it's I'm not sure if I'm answering a
question but kind of a bad I'm sorry
it's it's hard to really trust everyone
so it's kind of what marketing said you
have to be aggressive you have to think
that anything can break anytime you have
the think that anyone is malicious
anyone is bad and kind of go this way
don't trust anyone
I is anyone thinking about putting in
that package management system the
concept of this package has been audited
and give some kind of a marking of what
company audited it and of course the
reputation for that company is Piper
here III I mean my perspective at least
maybe I'm not supposed to have an
opinion since I'm running the panel but
is that it's definitely true that
systems like NPM are an unsuitable here
you know you need a lot better control
over the code you're running but I think
step one and as I understand that ESPM
implements that is you specify exact
versions of the code it crypt
graphically hashed you know so you know
you're getting the right code I don't
know if any of you know whether sort of
metadata about auditing is is in scope
or not with a metadata for whether a
code has been audited and who it's been
audited Byers is in scope for a package
management system I don't know what
level of metadata then so I guess the
question is ask Piper the answer rather
Thanks
just over there I was wondering if you
guys are interested in any other smart
contract languages and if so what would
they be we interested in any smart
contract languages other than solidity
is that great yep yes definitely I did
look a bit into serpent contracts way
back did an audit of the BTC relay but
it's right now solidity is the one which
most contacts are written in but I think
it'll be actually a refreshing change
when serpents hits the road properly
Viper
oh sorry Viper yeah yeah I had a
fascinating chat with the lead developer
of Vipers a day I think it shows a lot
of promise I'd like to see more smart
contract programming languages there are
things I like about Souls II and things
I don't I have a mental laundry list of
what my perfect programming language
would look like and the reason I don't
write us is because I'm aware that 90%
of the work is the tooling and other
languages can have a bit to catch up
with salasi before it's before they're
sort of at the same level in terms of
tooling maturity but I don't think like
some of these continued domination is in
any way it should and so I'm working on
my own like a little language but more
as a side project than anything the
solidity is by far the most yeah mature
and it's all those other things on top
of it that you really want like you want
the the ID ease integration and like
syntax highlighting like writing a
syntax highlighter is not a fun thing
but it's something that you kind of want
and that's something you just have to
write if you're doing your own like
random stuff I think another cool
approach is to have languages which are
less capable basically like Babbage
which and I don't know the details of
this but I I think that Babbage is a lot
more restricted in what it can do but
can thus provide a great
safety about the you know potential post
states after the execution great
unfortunately that's all we have time
for so thank you very much to my
distinguished panelists thank you up
next we have another panel on formal
verification moderated by Rito drinkler
you
[Music]