Maxi ContieriI am not a security expert. But I do love Clean Code and Code Smells
TL;DR: don't trust your hashes.
The Hack
Yesterday, 2022 Oct 7th one of the larger blockchains had to be halted.
This news was shocking since most blockchains are decentralized by definition.
Halting a large blockchain is not usual news.
It wasn't the first one, Either.
The Reason
I pay attention to blockchain and security news.
This is far from my comfort zone when writing technical articles.
I've written more than 180 code smells and refactorings.
There's always a tension between doing things in the right, clean way versus performance optimization.
Blockchains should be fast.
Many vulnerabilities are related to cryptic and optimized code.
This code would be unacceptable in many mission-critical large systems and codebases.
Performance and security are the main drivers on Web3, therefore blockchain and contracts code usually have exploits.
Clean code is not so easily exploitable.
The Problem
I've read a lot of forensic analysis on the problem.
One of the best explanations is here:
This tweet has a lot of resources for research.
I will address its main ideas:
What does matter is that due to the way that hash functions are intended to work, we can basically say with certainty that any (path, nleaf) pair will produce a unique hash. If we want to forge a proof, those will need to stay the same
In summary, there was a bug in the way that the Binance Bridge verified proofs which could have allowed attackers to forge arbitrary messages. Fortunately, the attacker here only forged two messages, but the damage could have been far worse
TL;DR: A hash function was exploited.
The Hash
I've been using hashing functions for decades (not on blockchains of course).
There's been a lot of research on the math hashing functions.
We teach our students at the university about hash collisions and how hard we create math functions to avoid them.
We also teach them some corollaries:
Two objects with the same hash might not be the same.
If we override an object's equality, we need to also override the hash.
The last one is very important for hashed collections.
A clean code lesson should be:
Use (fast) hash for fast discard, and use (slow) equality to ensure you are right.
Now, I need to come back to my comfort zone and write this lesson in the standard code smell template I've been using for years.
If you like the format, you can read 166 more here:
Image Credits
The beautiful image you see as the cover is a PNG image which hash is itself.
See the full story here:
And the code smell in the series format...
Code Smell 167 - Hashing Comparison
Hashing guarantees two objects are different. Not that they are the same
TL;DR: If you check for the hash, you should also check for equality
Problems
Solutions
- Check for hash (fast) and then check for Equality (slow)
Sample Code
Wrong
public class Person {
public String name;
// Public attributes are another smell
@Override
public boolean equals(Person anotherPerson) {
return name.equals(anotherPerson.name);
}
@Override
public int hashCode() {
return (int)(Math.random()*256);
}
// This is just an example of non correlation
// When using HashMaps we can make a mistake
// and guess the object is not present in the collection
}
Right
public class Person {
public String name;
// Public attributes are another smell
@Override
public boolean equals(Person anotherPerson) {
return name.equals(anotherPerson.name);
}
@Override
public int hashCode() {
return name.hashCode();
}
// This is just an example of non correlation
}
Detection
[X] Semi-Automatic
Many linters have rules for hash and equality redefinition.
With mutation testing, we can seed different objects with the same hash and check our tests.
Tags
Identity
Security
Conclusion
Every performance improvement has its drawbacks.
Caches and replications are notable examples.
We can (must) use them carefully.
Relations
More Info
Disclaimer
Code Smells are just my opinion.
This will surprise some of your readers, but my primary interest is not with computer security. I am primarily interested in writing software that works as intended.
Wietse Venema
