For those not following the space, solana has a smart contract language (a DSL in rust) that is new. Ethereum's primary smart contract language is solidity which has iterated many times & has linters and auditors that have learned their lessons through plenty of bugs in the past. (e.g. the DAO hack that split ETH into Ethereum and Ethereum classic) was a bug of the type "re-entry", it still crops up.
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:
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.
Yeah I hadn't looked into Solana's contract language much and this sounded like a nightmare. Another good one is that Cardano follows a UTXO model for everything, including contracts. So the address of a contract changes every time someone interacts with it
I don't have any specific pointers handy, but it might be a good idea to look through historical security vulnerabilities in widely-used protocols like TLS (and x.509 certificates). The cryptography/security community has slowly understood over the past couple of decades that complexity is the enemy of security, and it is much better to build stupid simple systems that you can validate (and ideally prove are secure) over complex systems which are almost certain to contain exploitable corner cases.
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.
It's not just that Solana is fairly new; the entire way the chain works is “torment the programmer on behalf of chain speed”, and if one of those decisions causes trouble down the line, instead of taking a step back and going with the simple and elegant approach, they choose an ad-hoc patch that causes more trouble down the line.
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.)
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.
If they didn’t formally verify the smart contract in a way that covers all edge cases including known “exploits” they kinda deserve to have their ethereum transferred to its new holder. Code is law.
> If they didn’t formally verify the smart contract in a way that covers all edge cases including known “exploits” they kinda deserve to have their ethereum transferred to its new holder. Code is law.
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).
According to contract theory, it may not be possible, in practice, to write "complete contracts", that is contracts that specify what is to be done in every possible contingency. See https://en.wikipedia.org/wiki/Complete_contract
Apparently not, as the hard fork into Ethereum and Eth. Classic proves. Once every big stakeholder decides the game isn't in their favor anymore, they change the rules.
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: