Earn $200K by fuzzing for a weekend: Part 1
secret.club
secret.club
I am not sure how old the author is but I find these donations incredibly generous and sometimes fail to comrehend such generosity. Sure you got an education at this place but was it worth 200K ? I am not trying to look at the action of the author in any disdain but am genuinely amazed at how such a young person will have such tremendous generosity.
So while the University at large has an endowment, the specific Cybersecurity Club does not.
> DoS Attacks: $100,000 USD in locked SOL tokens (locked for 12 months)
Apparently they made an exception in this case by donating in USD, but I certainly wouldn't trust an altcoin to be worth anywhere near the original $100k in 12 months.
I think that means you have to wait a year.
* Considering the money flying around Solana and its heavy dependency on BPF, $100k payout per vuln is reasonable.
* Considering the money flying around Solana and its heavy dependency on BPF, 2 major vulns with a fuzzer over a weekend is 100% unacceptable. If it was a usual startup, I would not be concerning, but, this is a blockchain that handles tons of money. It's such a complete failure of technical leadership.
* Note that bounty will not always solve the problem. If the vuln could be exploited for profit, Solana would've been already doomed.
Do you consider complaining "elitism"?
Sorry if i've misunderstood your point.
OP is obviously incredibly talented, fine, but maybe someone at Solana could have spent a month working on it full time?
Exactly. OP certainly is talented and did a great job up there. However, Solana is simply too important to fail like this. Literally billions of dollars are on stake, and running a fuzzer for 2 days should NOT be this much impactful. It would not be this absurd if OP had to spend much more time and effort than this.
In other words, Solana should have adopted advanced security measures far before this happened. Using BPF requires a compiler toolchain and VM, which are sophisticated by nature. There's no security-by-correctness here, so one should fallback to the next line of defense - practical correctness by stress test - where fuzzer becomes a necessity. There have to be various fuzzers running regularly somewhere in Solana.
Also, one should note that how Solana uses BPF is well outside the original intention of BPF, which is mainly used deep inside system. BPF in system has much smaller attack surface, much easier recovery scenario, and relatively smaller impact upon failure. When it comes to Solana, BPF is wide open to the wild, a faulty BPF program can cause a lot of damage, which are often (or mostly) irreversible. That mean Solana has to be the one who perform extensive researches on BPF. No one else needs to harden BPF to the level that Solana needs it to be.
I understand why most people wouldn't want to be earlier adopters of smart contracts. A lot of people are going to lose a lot of money to a lot of contract bugs for a lot of years.
But eventually that will stop, and the contracts will be stable, and the lessons will be learned.
At some point along the bounty x time curve, there's a threshold where you'll have a greater confidence trusting contracts than centrally managed institutions.
There was a time when banking over the internet was laughably insecure, but it saved so much time that people did it anyway. It took about 15 years before 2FA became standard practice and we're still weening people off of SMS.
Securing contracts may take 10 years to happen, but posts like this show me that it's going to happen.
The very opposite: it made GPUs and many other components more expensive.
At this point, the only explanation I can think of is that we're using different definitions of "popularize" (I'm using "To make popular; to make suitable or acceptable to the common people; to make generally known."), or you don't know what GPGPU is (I'm using "General-purpose computing on graphics processing units").
EDIT: Added that RR limits supply rather than raising demand, so not the same thing.
let addr = (sym.st_value + refd_pa) as u64;
Shouldn't something as critical as the EBF compiler be trapping integer overflow?
> every validator would run the target ELF file and the rBPF would get panic with “add with overflow”
I did not see overflow-checks = true in the cargo.toml though.