7 ms·
From the first thread: > A commit was made ~9 hours ago replacing usage of load_instruction_at with load_instruction_at_checked, which actually confirms that t
by btown 5y ago
From the first thread:
> A commit was made ~9 hours ago replacing usage of load_instruction_at with load_instruction_at_checked, which actually confirms that the program being executed is the system program. 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. 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.
> It looks like maybe Wormhole tried to do this by including the change in a much larger and unassuming commit called "Update Solana to 1.9.4". Not sure exactly what happened here, but a clear lesson to try to deploy before making any patch details public, if you can afford to do that. Of course this ends up being at odds with Web3 ideals, so not always clear how to best handle these sort of things.
One thing that would be healthy for the larger ecosystem would be for chains to build in regular "maintenance windows" where trades are halted by contract, at which time sensitive security patches can be rolled out to the codebase and then to the network by the maintaining team. Of course, this requires a lot of foresight. But the alternative is something like this.
Also - why would you ever set up a system where the majority of its assets can be drained by a single transaction, whether legitimate or not? Just because it's not centralized doesn't mean every transaction is made equal; one could require timeout periods for transactions above a certain amount, or any size of transactions could trigger a halt once a certain amount has been bled in aggregate, that requires supermajority consensus to "unlock" the chain. That this wasn't built in, in an ecosystem where hacking is rampant, by a team focused on creating a cross-chain transmission utility, is surprising, to say the least.
There are far, far worse things than a halt on trading. There are many domains where unsupervised 100% uptime on systems with access to a substantial portion of an organization's assets is ideal; finance, whether centralized or decentralized, is rarely one of them.
- rr808 5y agoThis is why multi day settlement is a feature not a bug. For big money it really does not need to be instantaneous.
- 101011 5y agoWhich is funny because you always hear how fast crypto transactions are. What everybody seems to leave out is that fully settling on the blockchain is slow and costly.
- SkyMarshal 5y ago> fully settling on the blockchain is slow and costly. That depends on which blockchain you're fully settling on. There's more than one, Ethereum != "the blockchain".
- yvdriess 5y agoFundamentally, the more popular the chain, the more expensive transactions are going to be.
- spopejoy 5y agoNot if the chain can scale -- ie not "fast finality" but being able to throw more resources at the problem as adoption increases (unlike Bitcoin, Ethereum and most single-chain POS systems however). Gas' true function is to stop griefing, the fact that it sends tx costs through the roof is because immature tech.
- oblio 5y agoHow can they ever solve the fundamental problem of slow worldwide, globalized, decentralized consensus? Have I missed some Turing Award discoveries while I was away?
- basicallybones 5y agoSeveral newer blockchains have made significant progress on transaction speed and throughput. Solana probably is the most notable example, but there are others. https://medium.com/solana-labs/how-solanas-proof-of-history-is-a-huge-advancement-for-block-time-178899c89723 https://medium.com/solana-labs/how-solanas-proof-of-history-....
- X6S1x6Okd1st 5y agoThere are applications that would really not perform well under a whole chain gets locked situation, e.g. anything that requires collateral ratios, things protected by timelocks, bridges. You can build in things that limit velocity of transactions, send limits etc in the smart contract it's self, no need for it to be at the chain layer, it's just that many of the largest protocols haven't done that (also you either enable some form of DoS or you are vulnerable to sybil attacks)
- panarky 5y ago> Could be that the Wormhole team spotted the bug, patched it, but the attacker got to it before the patch could be rolled out. It's a dark forest. Many predators who are smarter, faster and better connected than you are silently watching, ready to exploit your mistakes and ignorance for their profit. Dark Forest -> https://www.paradigm.xyz/2020/08/ethereum-is-a-dark-forest https://www.paradigm.xyz/2020/08/ethereum-is-a-dark-forest
- motoxpro 5y agoUgh this is the coooolest thing ever to see the ideas in that book come to life.
- edf13 5y agoHuh? Why didn’t he use flashbots to avoid the mempool??? https://docs.flashbots.net/ https://docs.flashbots.net/ His super-devs may not be so clued up after all
- T0Bi 5y agoHe didn't need to since the actual attack happened on Solanas side. The Ethereum transaction was completely legit.
- deleted 5y ago[deleted]
- TimJRobinson 5y ago
- woah 5y ago> Also - why would you ever set up a system where the majority of its assets can be drained by a single transaction, whether legitimate or not? Just because it's not centralized doesn't mean every transaction is made equal; one could require timeout periods for transactions above a certain amount, or any size of transactions could trigger a halt once a certain amount has been bled in aggregate, that requires supermajority consensus to "unlock" the chain. That this wasn't built in, in an ecosystem where hacking is rampant, by a team focused on creating a cross-chain transmission utility, is surprising, to say the least. Easier said than done. This is obviously vulnerable to sybil attack- the attacker just make a lot of different transactions. You could build in a circuit breaker that would slow down transactions to only allow a certain rate of increase in total dollar volume going through the bridge. Hopefully this would slow the attacker down enough. Now you're basically trying to devise a heuristic of what every single attack might look like in terms of transaction volume increase. If you're wrong, the bridge will freeze right when a lot of people want to use it. Plus, you also need to build a price oracle now. All of this is possible, but maybe it's better to spend that effort on just making sure the code is secure in the first place.
- technics256 5y agoWhere did you learn this skill/field? Would love to learn up on it and get my hands dirty.
- SEJeff 5y agoSybil attacks are common problems in many blockchain related problems. Especially for governance and “sources of truth” such as price oracles. Just google it.
- vhiremath4 5y agoI'm not trying to be mean here, but this is your chance to learn now so I say seize it if you find the passion! It might be daunting because the parent commenter is referencing several vast and technical fields, but it's very doable and my preferred way of learning is to start with what is immediately in front of me so I can gain somewhat of an understanding and then dig in every time I don't understand something again (depth first search). The parent commenter is referencing several fields: > Sybil attack: https://www.sciencedirect.com/topics/computer-science/sybil-attack#:~:text=A%20Sybil%20attack%20is%20defined,and%20function%20as%20distinct%20nodes https://www.sciencedirect.com/topics/computer-science/sybil-.... This is a type of peer-to-peer strategic attack. So you could postulate that this broadly falls under the category of "common p2p network attacks and vulnerabilities". Google that! > Circuit breaker: https://en.wikipedia.org/wiki/Circuit_breaker_design_pattern https://en.wikipedia.org/wiki/Circuit_breaker_design_pattern This is a type of software pattern for making sure a signal (usually bad) doesn't keep recurring and its blast radius is contained. > Now you're basically trying to devise a heuristic of what every single attack might look like in terms of transaction volume increase. If you're wrong, the bridge will freeze right when a lot of people want to use it. Plus, you also need to build a price oracle now. This is blockchain specific, but you can definitely deep dive into how blockchains work to get to a point where you understand the concept of a "bridge", "price oracle", etc. All this said, some people are more breadth-first-search learners, so, if you find yourself in a situation where this is overwhelming but you still want to know, you can always start teaching yourself fundamentals that lead to these areas. I'm roughly breaking down the stack for you here: First stack: * intro to programming (and getting deep into programming in general) * understanding the basics of an CRUD database app (client-server systems) * understanding multiple services (microservices and systems architecture) * distributed systems (consensus algos, time drift + vector clocks, etc.) * specialization in understanding the blockchain data structure * specialization in understanding p2p systems and their faults
- user-the-name 5y ago> why would you ever set up a system where the majority of its assets can be drained by a single transaction Because, as always, if you were competent, you would not be working on cryptocurrencies.
- SEJeff 5y agoWhy not? Porn drove much of the storage technology and video codec technology forward we use today. Electronic trading drives much of the networking technology the world runs on today. As much as it is mostly scamming and haxx, there is some genuinely interesting computer science research happening around Byzantine fault tolerance and distributed systems in the blockchain space. Just because you don’t like it doesn’t mean it isn’t legitimately moving the needle forward in tech we will all use eventually.
- bpicolo 5y ago> Super important to keep these sort of patches lowkey and to try to stuff them into larger commits That's a bananas philosophy
- sigmar 5y agoWhether it is bananas or not, it's the same principle Microsoft uses for patch Tuesday (ie slow down patch analysis by bundling everything into a big monthly release)