Reentrancy Puns

Hi everyone, I'm going through the SWC registry now https://swcregistry.io/docs/SWC-107#modifier-reentrancysol

In this reentrancy example, the difference between the insecure contract and the fixed contract is simply changing the order of the modifiers on the function airDrop(). I'm scratching my head because I can't figure out what difference this makes in this particular example.

I know that with reentrancy, we need to make sure changes to state variables are made before external function calls, and possibly include a locking mechanism. But I can't see how switching the order of modifiers on airDrop() in this example changes that at all.

Can anyone shed some light ?

Lending and borrowing platform Cream Finance has fallen to a flash loan exploit involving Flexa Network's native token, AMP.

Original announcement:

https://twitter.com/CreamdotFinance/status/1432249771750686721?s=20

Technical Analysis:

https://medium.com/cream-finance/c-r-e-a-m-finance-post-mortem-amp-exploit-6ceb20a630c5

Analysis:

https://decrypt.co/79746/defi-project-cream-finance-involved-25m-flash-loan-exploit

When looking at blogs and tutorials - a lot of them still use Transfer (or, Send). On the topic of: Smart Contracts not depending on gas costs and the Call function -- is this the most up-to-date information?

blog about transfer

Are there any other good links in this topic that are newer?

I read this blog post (which seems to be a parrot of Wiki: Reentrancy (computing)) about reentrancy and it appears to be a problem because of a recursive call (in their case, indirectly via my_func()).

I guess what I'm really asking is under what conditions should you worry about code reentrancy. The examples and wiki mentions two:

1. Recursive calls
2. An interrupt service routine which, separate from main() execution, executes a function that had already been called from main().

If you're writing a multithreaded program and Thread1 calls foo() and Thread2 also calls foo(), would you need to take care to make foo() reentrant?

Is that it?

The "window procedure" (also known as wndproc) for winapi has the annoying requirement that it be reentrant - various winapi calls can call back into the window procedure.

In druid-shell I'm trying to be careful and correct. I materialize the window state from a *const pointer to an &self reference and then rely on interior mutability. Someone on #winapi irc said that it would be valid to do this as mut, that the recursive call could be considered the same original borrow. I'm very skeptical of this and would like an expert opinion.

Looking at other code, I see winit makes an &mut reference, but doesn't do a lot of direct mutation, most of the inner state of that struct is interior mutability. My hunch is that this is technically UB but likely to work in practice (my favorite kind of UB, just like mem::uninitialized). This is one of the reasons I'd like an expert opinion, if this is wrong it should be fixed, but if it turns out to be okay, then it's going to make a bunch of this code easier to write.

I checked a couple of other Rust implementations of wndproc, but didn't find anything I could use as an authoritative reference. If people know of any, I'd love to see them.

I've been doing some Ethereum development and research, and came across this page: https://consensys.github.io/smart-contract-best-practices/known_attacks/

This confuses me because I'm under the impression that the EVM is single-threaded and executes transactions one at a time in order of their gas prices. Reentrancy shouldn't be possible if my conception of the execution environment is correct, so I must be missing something. How in the world would one go about re-entering a function before its initial invocation has completed?

Thanks!

It seems there is another serious reentrancy bug on some Ethereum defi smart contract being exploited. My question is, will the same issue occur on Tezos? Is it Solidity specific or every smart contract language needs to pay attention to?

Original & Formatted Post Here: Ethereum's Delay & Reentrancy Attack Explained

#Constantinople & Reentrancy Attack Explained

Unfortunately, the long-awaited Ethereum Constantinople Network Upgrade has been delayed. An auditing team discovered that the upgrade to Constantinople would introduce a security vulnerability. Before we go over the security vulnerability, let’s quickly answer a couple of questions I’ve been getting.

##What do You Need To do

This depends on whether you’re simply an investor/trader or if you’re a miner or node operator.

> Do you need to do anything with your Ether?

No – if you’re simply an investor, just sit tight. You do not have to do anything with your Trezor, Ledger, MyEthereumWallet (MEW). So, watch out for scammers who may try to confuse you.

> Do I need to upgrade my node?

Yes – if you’re a miner or node operator you will have to upgrade to a new version of Geth or Parity before approx. 4am Jan 17th GMT.

##What was the Security Vulnerability in Constantinople?

###Quick Answer: The security vulnerability arises from the update that introduces Cheaper Cost Of Storage [EIP1283] that we discussed in our Constantinople Simple Explanation post.

The cheaper gas costs allowed for an exploit in the Smart Contracts. This particular exploit is called a “Reentrancy Attack”.

##What is a Reentrancy Attack?

I’ll give you guys a simplified explanation.

A Smart Contract may communicate with an external Smart Contract by “calling it”. If the external Smart Contract is malicious, it may be able to take advantage of this and take over control flow of the first Smart Contract’s code.

 

This allows the attacker to make unexpected changes to the first Smart Contract’s code. For example, it may repeatedly withdraw Ether from the Smart Contract by “re-entering” at a particular spot in the code. (Essentially, it makes multiple invocations of the withdrawBalance() function)

 

###Note: It’s important to note that this security vulnerability does not exist in the current Ethereum chain. All Smart Contracts on the current chain are Reentrancy-Safe!

The introduction of cheaper

It seems like the definition of reentrance is inconcistent among many people:

https://imgur.com/a/F2HTvi0

from the last paragraph first sentence, "must be reentrant - it must be capable of running in more than one context at the same time" source: Linux device drivers O'reilly which, to me, means that the kernel code you write must be able to be run by eg multiple threads at the same time. While when looking at this answer on SO and explanation on Wikipedia:

https://stackoverflow.com/questions/34758863/what-is-reentrant-function-in-c/34759003#34759003

"Function is called reentrant if it can be interrupted in the middle of its execution and then safely called again ("re-entered") before its previous invocations complete execution" those are 2 totally different things! In the former you should only make sure that you have a locking mechanism on eg the driver's fd, while in the latter you only have to disable interrupts and task preemption. And the C99 standard obviously doesn't define "reentrancy"

What does reentrancy really mean? Where can I find a proper reliable definition?

Two high profile hacks of DeFi protocols resulted in $300,000 and $25 Million being stolen from Uniswap and dForce respectively. This post looks at the imBTC token and why one of its features enabled both attacks. TL;DR: it was the same kind of reentrancy bug that led to the demise of The Dao nearly four years ago.

https://www.buildblockchain.tech/newsletter/issues/no-92-reentrancy-returns

The post also explores best practices for protecting against these kinds of hacks, and asks some hard but important questions. One is: how do we expect teams to pay for audits and other security best practices when we also expect protocols to be "fully decentralized" and thus impossible to monetize?

Not fud, not a drill. Here's the main details: https://np.reddit.com/r/ethereum/comments/agaiif/constantinople_enables_new_reentrancy_attack/

In the eth core dev chats, it looks like consensus is leaning towards that it will be postponed. Good job to ChainSecurity for catching this, and good job to Eth Devs for making what is probably the right decision, despite all the fud that is going to come with it.

Edit: It's been confirmed.

> Nick Johnson @Arachnid 12:08 The consensus on the call is to postpone.