[contravert]

Although a flashloan was used in this exploit, that's just a tool to leverage a fundamental flaw in the protocol. Flash loans clearly do more harm than good, so it's completely irresponsible for major DeFi platforms to still have this feature at this point.

The actual flaw is in Cream's oracle design for certain exotic long-tail assets. Basically, smart contracts need to get the price of an asset, and Cream was using the most naive way of simply calling the equivalent of asset.getPrice().

The reason this approach is critically unsafe is highlighted by this incident. A flashloan can alter price, borrow assets based on the new price, then return the price to normal before the transaction is finished.

This is not merely a coding bug but a basic design flaw that should have been caught by anyone with even a basic understanding of oracle design. It really reflects poorly on the competence of the entire DeFi space, considering CREAM is a pretty major protocol.

[nostrademons]

I think that a lot of the motivation for flash loans is that they democratize capital-intensive arbitrage attacks, making the attacks happen sooner, making all of the insecure contracts fail fast and improving the overall security of the DeFi ecosystem. In other words, it's supposed to make platforms fail and people lose money, because each hack exposes a bad contract and takes it out of the environment.

If flash loans didn't exist, then an entity with sufficient capital can still alter prices and exploit differentials in borrowing costs to profit. This is a common complaint about the mainstream financial system - examples include market corners, short squeezes, George Soros breaking the Bank of England, or the Fed artificially lowering borrowing costs for the U.S. Treasury. But they're limited to people who already have a billion dollars. Flash loans let everybody have a billion dollars, so that if there's an arbitrage opportunity you don't need capital to take advantage of it.

[foepys]

> In other words, it's supposed to make platforms fail and people lose money, because each hack exposes a bad contract and takes it out of the environment.

I can already hear my grandma say "I'm glad I lost all my savings, now the platform gets safer."

Apart from that, it's naive to think that this makes the ecosystem safer. We still have SQL injections and XSS in the wild even though everybody should know how to avoid them after literal decades of exploits.

[nostrademons]

The issue with SQL injection and XSS is that there is usually no cost to the website with the vulnerability. They can keep on doing business as usual, after a suitable mea culpa, without significant consequences.

When there's a crypto vulnerability, the contract usually gets drained. It goes bankrupt. There is no funds and no viable business there. Therefore, there's not just a significant incentive to guard against security holes, but there's also a selection mechanism.

People underestimate the power of bankruptcy, failure, death, revolution, nonexistence, and other selection mechanisms. Selection bias is the most powerful force in nature, because natural systems without a selection mechanism tend to get selected away. Arguably a lot of the problems with our current economy come about because we fail to let things fail.

[rodiger]

Flash loans are incredibly powerful and allow those without capital to take advantage of arb opportunities. I don't believe it is a given that they do more harm than good at a philosophical level. Not to mention, this exploit still exists without flashloans (however, anyone with $500,000,000 in crypto has likely KYC'd somewhere, so the risk profile is different).

The solution is better coding practices, and plenty of platforms have protections against this.

[capableweb]

> This is not merely a coding bug but a basic design flaw that should have been caught by anyone with even a basic understanding of oracle design. It really reflects poorly on the competence of the entire DeFi space, considering CREAM is a pretty major protocol.

How is CREAM a "pretty major protocol"? It was forked from Compound so no innovation on their own, and their token is not even in the top 100, and their platform is around #30 compared to others in DeFi. There is so much shit things in both DeFi and Cryptocurrency that it's unfair to judge other projects based on how bad they are.

It's like saying a well-written Rust project gets bad rep because some PHP developer once had a SQL injection, and somehow all programmers are the same...

[danielvf]

Since Hacker News is the place for pendency, let me point out that the oracle here worked 100% correctly, and correctly reported the actual value of yUSD.

yUSD's value did actually double during the attacker, because the attacker gave yUSD holders millions of dollars as part of the attack.

[stingraycharles]

I’m a total cryptocurrency noob. Could you elaborate a bit further on what an oracle is in this context? I’m familiar with the term oracle in crypto for things such as a padding oracle, but I feel that what you’re referring to is a different kind of oracle.

[Findeton]

An Oracle is a way to tell the blockchain about external data like the price of something in the general markets. As I understand, a flash loan is a loan that is both created and paid in the same blockchain transaction (thus if it can't be paid it won't be included in the transaction), and that the exploit here was to both modify the price given by the oracle twice (up and down) and have a flash loan in the middle, all in the same transaction.

I hope I'm not adding to the confusion because I am not an expert.

[stingraycharles]

that clears a lot up, thank you.

does the oracle in this specific case use external data? and combine that with internal / blockchain inputs? how does one sanitize all those inputs?

are oracles transactional, ie if you manage to alter the state of an oracle within a contract’s transaction, other transactions don’t get any “dirty reads” from the oracle, etc?

[nemothekid]

An oracle is just a provider of some kind of off-chain data. For example if I wanted to incorporate the stock price of AAPL in my smart contract I would need to "trust" some off-chain (and possibly centralized) provider of data to deliver that information to my smart contract.

The obvious problem is that if that data is manipulated somehow, the smart contract can potentially execute with malicious information.

[postcynical]

What made it click for me was that smart contracts are similar to stored procedures in db speak.

So in this case someone wrote a smart contract/stored procedure that:

- loan $a_lot_of_money from $defi_a

- do something with $a_lot_of_money to confuse an oracle (e.g. a price feed)

- exploit $defi_b who relies on above oracle data

- return $a_lot_of_money to $defi_a

This all happens in a single "db transaction" so as long as $defi_a receives its money back the tx is going to pass.

If $defi_b relies on an oracle that takes it's data from on-chain, and thus is manipulatable with $a_lot_of_money, it is suspectible to those attacks.

To counteract this, $defi_b could only rely on oracles that are secure against manipulation from $a_lot_of_money, but they don't always exist.

This mechanism can be used for good (riskless arbitrage across decentralized exchange) or for bad exploits.

[snug]

Others have answered, but there is a tool that helps with trusting oracle data, called Chainlink ($LINK)

Chainlink uses a proof a stake (POS) concept where it calls out to a number of LINK nodes that have staked assets for liability in order to win rewards. With all of the Oracles data it goes through an algorithm, for simplicity, let's say the average of all the prices it received, gives the nodes a reputation score, on top of that it uses the reputation of the nodes to choose who ultimately fulfills the request, the number of tokens staked will also take into account. If reputation starts going negative, they could lose the tokens they have staked.

[latchkey]

Chainlink solves a lot of this. Another irresponsible move by Cream.