*edit: another good thread https://twitter.com/samczsun/status/1489044939732406275
> 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.
What do you mean?
At the moment the transfer fee for Bitcoin/Eth is about $1.80/$4, so if you are buying a $5 coffee it’s not really cost effective to do that on chain.
The main issue that drives up cost is that Bitcoin has a scalability problem for transactions, particularly as the market cap/difficulty has gone up.
This is why the lightning network was introduced - although that comes with its own drawbacks compared to “pure” crypto.
What’s the ideal scenario here? Transactions on chain eventually become free and then we truly have a useful distributed currency?
But frankly that’s besides the point. There are very few physical transactions in the “cash” world. Crypto can become very successful and never touch those transactions if it can work to standardize & disintermediate the electronic movement of money it could be a massive change.
I don’t know if that will happen and it’s not a goal of the crypto diehards I’ve met, but that’s a path to success that allows for fees along the way.
Fair point. But there are still many more informal cash transactions that don't have that issue, but maybe that's not what cryptocurrency will solve. That's fair.
> But frankly that’s besides the point. There are very few physical transactions in the “cash” world. Crypto can become very successful and never touch those transactions if it can work to standardize & disintermediate the electronic movement of money it could be a massive change.
Definitely agree traditional electronic money transfer today has many issues. But I don't yet understand why cryptocurrency is the necessary solution. Sure it's a solution, but surely it's possible to fix the issues without cryptocurrency.
I think I understand the core principle and appeal of crytpocurrency as a decentralized currency, underground currency among those wishing to avoid traditional financial institutions. But everywhere I look I see cryptocurrency turning into traditional banking and I don't really understand the overall benefit. It seems the few benefits it does have over traditional banking (speed, ease of transfer, univeral currency) are outweighed by the drawbacks (power hungry, surprisingly insecure, easy to simply lose everything you have with no recourse).
That depends on which blockchain you're fully settling on. There's more than one, Ethereum != "the blockchain".
Have I missed some Turing Award discoveries while I was away?
Yes. ZK Rollups - https://polynya.medium.com/conjecture-how-far-can-rollups-da...
If you don't understand this post he has many more explaining the technologies behind it.
That's not necessarily a problem. Slow is ok if it's highly secure, reliable, and inexpensive relative to the amounts being moved or compared to other alternatives.
Where do you hear that? One of the big criticisms of the biggest cryptocurrencies as currencies is that transactions are glacially slow for most practical uses (small transactions). Improving on that seems to be the main selling point of Solana.
given enough time the entire crypto space will have reinvented every regulation they tried to get rid of and understood why they existed in the first place
Some googling found this article on the origin of the phrase "Chesterton's fence".
And the hilarious thing is that they see the absence of this regulation as a feature and don't even recognize just to what extent they are reinventing the wheel.
My favorite example is kleros.io, a "decentralized arbitration service". There's an app "Kleros Court". Can't wait for the "Kleros Supreme Court" version, for appeal processes and such.
Just like modern-day web development!
Right, but they have to get through the robber baron and feudalism phases first.
"Hey, grandma, run this command and press enter and I'll send you the Fountain of Youth™ creme tomorrow."
At least you kind-of-sort-of have a chance at reverting a transaction.
Heck, my bank completely blocks my transactions over a certain limit (I need to ask for temporary limit increases through a separate process) and frequently delays transactions larger than another limit and they call me to verify that I want to do them.
Sure, blockchains could do the same, through intermediaries, but then... they've reinvented banks.
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)
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
His super-devs may not be so clued up after all
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.
The parent commenter is referencing several fields:
> Sybil attack: 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
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
Circuit breakers based on price/volume/volatility is standard finance tech.
With that said smart-contract programming is (at least for now) an in-demand skill set.
The company I work for is interested in developing that skill set because such people are in short supply. A background in conventional distributed systems is very helpful, but anyone with a solid grounding in CS fundamentals can pick it up. It’s a different execution cost model and it’s an adversarial environment, so one needs to keep their wits about them, but it’s learnable like anything.
If you want to know more: ben@rocinanteresearch.net
* The solidity docs are very good - dry and daunting but not too bad to get through.
* Ethernaut has some great CTFs you can play with.
Also some other books: Mastering Bitcoin Mastering Eth The Sovereign individual
Then i would read the first 10 chapters of the rust book, then dive into substrate.
Is that really that hard though? It does require a price oracle but otherwise it's a pretty easy limit to set.
> If you're wrong, the bridge will freeze right when a lot of people want to use it.
I mean, this stuff should be staying in beta a LOT longer than it is, and in a nice long beta you could be increasing limits gradually.
Because, as always, if you were competent, you would not be working on cryptocurrencies.
That's a bananas philosophy
> 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.
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.
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.
.. which means that when an undiscovered vulnerability is found all the investors are guaranteed to lose their money.
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.
This is false. Many of the most heavily used Ethereum contracts, such as Uniswap, are non-upgradeable.
And that can’t be fixed because it’s immutable?
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.
The new language & platform will likely need to learn the classes of bugs that can crop up through a similarly painful process, although this one was using something that was unknown to be unsafe :shrug:
The call they were using was deprecated and marked unsafe a while ago: https://github.com/solana-labs/solana/blob/7ba57e7a7c87fca96...
They need a new name for these things that better communicates the risk level. Right now calling these "smart contracts" is like calling dynamite a "lovely candle". There's nothing smart about something that lets you screw up this badly.
It boggles my mind that anyone would want to participate in anything like that, let alone believe it's the future of anything. It's like volunteering to live in a hole in the middle of a WWI no-mans-land, when there are nice homes available in town where you don't have to worry about being killed all the time. It's one thing to be forced to live in a dark forest, it's quite another to choose to live in one (as anything other than the apex predator).
I'd even argue that imperative programming is the wrong paradigm for such smart contracts.
That is simply not possible. No-one can think of all edge cases.
As a security researcher, I absolutely assure you, the pattern of "checking signatures by checking that the last instruction executed was, in fact, a correct signature check over the right data with the right results" sets off ALL my alarm bells. This is so backwards I don't even know what to say. Just reading through the linked code I'm getting "this might be exploitable" feelings, and not just the aforementioned bug, other parts of it too.
I can't believe others trust these people with their money. They have no idea what they're doing. They're building a ridiculously overcomplicated system layered upon layers of systems where any single mistake can cost them all the funds with no recourse, and aren't even doing it in ways that make sense. It's insane.
This also ties in with general security hygiene and understanding; you need to know what is trusted, what is untrusted, and how to make them interact. Ideally you don't validate untrusted data; instead you build your system so that is not necessary. Every validation that needs to be performed is one more place where something can go wrong. If you need to validate a signature, you go and validate it; you don't ask the user to do it and then validate that they really did it properly and the validation happened. That's what happened here, as far as I can tell. The extra, avoidable validation went wrong.
This popped into my mind when reading your comment.
One example of this is rent. You can store data in accounts. But if the balance of the account is lower than some amount (that depends on the size of the data), the entire account might disappear. Depending on the amount it might disappear immediately and you would find out, but if it is just below the threshold, the account could survive for years. So in any kind of transfer that involves an account that holds data, you need to be careful to check that its balance does not drop under the threshold. If you forget to check in just one place, your state may disappear.
Another example: program calls take a list of accounts. You need to manually serialize and deserialize your data into accounts. It's like writing a program in C where every function can only take an array of void* as arguments, and it is up to the caller to cast (serialize) all arguments to void* and pass them in the right order, and up to the callee to unpack the array again, cast back the pointers, and check that they are valid before dereferencing ... That's fine for a low-level target if a compiler could generate the tricky code for you. But on Solana it's your responsibility to do it manually, in Rust. Much of Rust's safety is useless here. (There exist eDSLs that alleviate much of this, but if you don't understand the underlying model, it is still easy to make a fatal mistake.)
https://threadreaderapp.com/thread/1489044939732406275.html
It's unfortunate that the images don't load in that view, but it's still better than the twitter UI