Hacker News Reader

Comment by chrononaut | Hacker News Reader

Wow! This was the most surprising to me in the thread:

> It's interesting that this commit was made ~9 hours ago and the exploit happened a few hours after that. Possible that an attacker was keeping an eye on the repository and looking out for suspicious commits.

https://twitter.com/kelvinfichter/status/1489050921938132996

> Could be that the Wormhole team spotted the bug, patched it, but the attacker got to it before the patch could be rolled out. Super important to keep these sort of patches lowkey and to try to stuff them into larger commits.

https://twitter.com/kelvinfichter/status/1489051698329014273

Is this something inherent in the cryptocurrency space? Where monitoring for security patches and exploiting them before they are rolled out results in an instant multi-million dollar payday? Is this a common risk? If so, that seems crazy. Vendors already struggle rolling patches in closed source environments.

View on HN

Yes, this is a risk. Exploiters will be running legit nodes with software analyzing the mempool for profitable transactions to abuse, they will be running nodes using the GitHub branches looking for changes in advance of merges so they can run exploits, they will be looking at framework changes and automatically running tools like fuzzers to find errors in downstream chains and projects that use the framework. It's a really really hard space for this reason. I work as a test engineer in DeFi and have been in the blockchain space for years but releases still give me stress like no other domain I've been in.

The nice thing is that engineering isn't usually financially bound so you can use all the toys and hire all the consultants to build really extreme testing environments that most domains won't use. It's also fun to flex tools like TLA+, property based testing tools, fuzzers, etc because it's financially sensible to be as sure as possible that you won't release a bug.

Ethereum is a Dark Forest:

https://www.paradigm.xyz/2020/08/ethereum-is-a-dark-forest

Great share! Thank you

Why waste ones time hoping for 5-6 figures from big tech bug bounties? Smart contracts seem like the ultimate bug bounty program.

Bug bounties are legit money that you can spend as you want without trouble.

In the 'code is law' world of crypto, so are/should be these hacks. How are they any different than lawyers pouring over the fine print of a law or contract to find a loophole to exploit?

it is not that hard obfuscating the money in small amounts

I thought these contracts lived on an immutable blockchain, how can they even be patched?

This bug was on the Solana blockchain. Solana has built in support for updating code.

Even on Ethereum, with it's mostly immutable contracts/programs, there is a super common pattern of a tiny shim contract that forwards all calls on to another contract that does all the work. By changing a storage variable which changes the contract the shim points to, you can effectively upgrade the code.

And therein lies my biggest frustration with crypto evangelism. Almost every theoretical benefit that gets trotted out is such a detriment in practice that the ecosystem tosses it aside. While still proclaiming it as a virtue.

I would wager most contracts deployed these days are immutable. Upgradable contracts are frowned upon in the space, moreso every day.

But given that humans are prone to making mistakes, when code is fresh and unproven, proxies are a practical way to go. Once you've ironed out all issues, you blow the fuse so that the contract can't be changed anymore.

> Once you've ironed out all issues

Yeah this is something that famously happens with software development, you just iron out all the issue and then never have to change anything ever again.

> can't be changed anymore

.. which means that when an undiscovered vulnerability is found all the investors are guaranteed to lose their money.

> the ecosystem tosses it aside

This is false. Many of the most heavily used Ethereum contracts, such as Uniswap, are non-upgradeable.

The one to which you can send back the stuff it sent you, and it essentially burns the money?

And that can’t be fixed because it’s immutable?

Correct, but what they can do is hard fork and encourage users to switch to the new version. Users will vote with their feet and choose the version that benefits them most. In a sense it's still upgradable, but only through direct democracy instead of delegated democracy / oligarchy. (and for the record I don't necessarily think that's a good thing for a financial system, but we'll see how it plays out in the next few years)

A common pattern is to deploy a proxy contract, which simply forwards all function calls to an implementation contract, then an upgraded deployment generates a new address, the proxy contract is changed to point to the new address, and all end users only interact with the proxy contract. This is a little bit frowned upon in the community because it's a point of centralisation and control.

Reply on news.ycombinator.com