Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> using something that was unknown to be unsafe

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


How can you communicate with a contract if its address changes every time? Don't you need a stable address?


I'm interested in learning more about this- do you have any recommended resources for getting started?


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 is much better to build stupid simple systems ... over complex systems which are almost certain to contain exploitable corner cases.

This popped into my mind when reading your comment.

https://www.youtube.com/watch?v=eU2Or5rCN_Y


That's great, it seems it's trivial for you to make a better one and help a lot of people.


It can be trivial to see an unfixable problem.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: