5 ms·
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 tha
by chrononaut 5y ago
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 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 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.
- mdoms 5y agoI thought these contracts lived on an immutable blockchain, how can they even be patched?
- danielvf 5y agoThis 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.
- dralley 5y agoAnd 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.
- pshc 5y agoI 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.
- pjc50 5y ago> can't be changed anymore .. which means that when an undiscovered vulnerability is found all the investors are guaranteed to lose their money.
- user-the-name 5y ago> 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.
- woah 5y ago> the ecosystem tosses it aside This is false. Many of the most heavily used Ethereum contracts, such as Uniswap, are non-upgradeable.
- masklinn 5y agoThe 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?
- nikisweeting 5y agoCorrect, 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)
- malux85 5y agoA 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.
- exdsq 5y agoYes, 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.
- blihp 5y agoWhy waste ones time hoping for 5-6 figures from big tech bug bounties? Smart contracts seem like the ultimate bug bounty program.
- msh 5y agoBug bounties are legit money that you can spend as you want without trouble.
- hamiltonians 5y agoit is not that hard obfuscating the money in small amounts
- blihp 5y agoIn 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?