[Music]
my name is ganelli as he already uh said
I'm a head of security services at open
Zeppelin I'm I'm here today to talk you
about double entry point
issues so first things first what is the
double entry point as we all know how
solidity Works um users or protocols
interact with contracts by knowing what
the address is so basically they know
the address and that address is pointed
to a specific smart
contract a double entry point happens
when actually there's not only one
address that points to that storage of
the contract but actually there's many
addresses could be two could be n
um and also protocols can talk to uh
these double entry points so not only
not only uh users but also protocols but
also tokens but basically anything that
can interact with an address can
interact with a contract that can have
more than one entry point this can have
a couple of problems which are um
unclear to end users to which contract
they should be talking to um and clear
to protocols uh which contracts they
should be interacting with when they're
integrating based on the fact that
basically all smart contracts are
interacting with other smart contracts
all the time and that introduces
security caveats that we're going to see
now with some examples so first case
compound 2022 um this was an issue that
we found at the beginning of 22 uh in a
token named uh TUSD this T USD token had
two entry points so basically anyone
would be able to for example if you want
to transfer some of your gusd tokens
from one address uh to the other you
could use any of the two entry points
that you had and how it worked the
Legacy address they did some kind of
migration this Legacy address would uh
when you talk to the transfer function
would uh forward the transfer function
to the new contract and the same with
all the um functions def finded in the
contract and again as I said not only
with users also with protocols and the
case was compound the C token contract
had a Swip token function that had here
a required statement that you can see
that would check that the address uh
that you want to sweep the typical sweep
token that sweep token function that you
want to like remove certain tokens of a
specific contract will'll check that the
address that you're sending was in the
underline so if you have the c t us D
token and you want to sweep all the T
USD tokens you shouldn't be able to do
that but if you want to sweep the DI
tokens you should be able to do that and
send it to the admin of the of the
contract that I think it was the time Lo
button um the problem is that the
underlying could be two addresses so
actually you can call this function
bypass the required statement and
actually move all the funds that were in
the C token or the CT USC contract back
to the admin basically creating chaos
one of the or a couple of things that uh
we saw that happen is that the C token
to token price got completely screwed so
any Mint or any burn uh would account uh
wrongly um and also there was the
possibility to steal funds from the pool
because all the calculations were me
wrong so if an attacker would uh send a
transaction to the sweep token function
to reduce uh to zero the underlying
token balance and then touch a little
bit what was happening in the like
sendat transactions to other functions
would have been able to uh steal around
50 million uh dollars second case 2024
un of before we did an audit for the V4
core code and we found that uh the case
was with another representation of
double entry points that happens not not
when you have two addresses but when you
have a native token and an erc20
representation of that erc20 token and
basically users can interact with both
at will as well as protocols unisoft
we're not going to talk much about
unisoft because it's very uh complex but
there's a settle function the SLE
functions allows uh users basically to
uh modify their account Deltas which is
basically the amount of money that they
hold in there in the pool manager um at
will by by adding tokens or removing
tokens and it has this if statement that
actually checks uh if the currency that
we want to interact with in the pool
manager is the native token and if it's
not the native token it will enter to
the lse so basically uh we can interact
with another entry point and an attacker
could call the sync function selling the
CEO address the issue was actually with
the I didn't mention it but it was with
the CEO uh token address um basically to
put in transient storage the CEO address
to then interact and do other operations
uh then they could call the sell
function that would enter to the if
statement and account the value that
you're sending as a parameter as the new
account Delta so the new uh balance of
the user and then call the other SLE
function I mean is the same setle
function but we enter to the else um
statement and we'll basically account
for 20 tokens instead of 10 uh and in
the end the user would only deposit 10
tokens but get a balance of 20 and then
this same user could without any
problems take that money from the pool
if they do this many times or if they
use higher values that is not 10 uh they
could drain the pool so in V3 um CEO has
like $15 million of TBL I believe and if
they were to migrate things from B3 to
B4 uh it would have costed around $50
million uh of losses so time takeaways
first of all this is an issue that we
found in 2022 2022 also in 2024 it's an
issue that can still happen because it
doesn't depend of our protocol it
depends on other protocols that we inate
with um so we should never trust any
protocol or or token that we interact
with um always double check that when we
integrate with a protocol or a token it
doesn't have a double entry point and
actually if we do we have to also check
and code in a defensive way so that if
they introduce uh a double entry point
we can account for that and we don't
have issues and that's all thank you
very
much thank you H and thank you again for
all all that you are doing for the
security of our
apps okay we have the full room almost
so I expect some questions raise your
hand
please you can just say something nice
to the speaker that's also
accepted are you going to say something
nice or you have a question let's see
let's
see yeah hello so with the raise of AI
that can create code how do you think AI
will will uh blend into the
development how would you blend this
into development with AI yeah how how
you going to use AI to basically secure
check the system it's a good question
you can like write rules around the
things that you want to check around
double entry points and put it in an llm
to learn from different code bases and
maybe check if they have a double entry
point issue you could also use a ITC if
storage is mod ified by more than two
addresses um out there I
guess okay thanks for the question
more yes there in the
back
in um thank you what I want to ask is
there are many like special tokens like
this double entry some with hooks so why
is there not like any framework that
kind of specify like testing tokens like
these ones so like do fasting or this
kind or I don't know just standardize
the testing for all the special tokens
that we know that might have prevented
for instance this issue in development
what do you think about
this I think that's a good idea but
would be more like we have to come up
with preventative measures rather than
how to mitigate these sort of problems
once they're introduced way of doing
that is just like have good standards on
things that we have to do and things we
shouldn't do for example never have two
or more Dres pointing to the same
storage layout of a like of of the same
contract like I would always go through
the preventative um measurements
measures rather than for like trying to
fix things when they already wrong okay
thank you for the question and for the
answer we are out of time big round of
applause again please for hot
um I'm going to be outside in case
anyone want to talk about this topic
thank you very much okay thanks again