>>It would be bad form of me to not explain the incredible flexibility shown by Solana in terms of how they handled my payout. I intended to donate the funds to the Texas A&M Cybersecurity Club, at which I gained a lot of the skills necessary to perform this research and these exploits, and Solana was very willing to sidestep their listed policy and donate the funds directly in USD rather than making me handle the tokens on my own, which would have dramatically affected how much I could have donated due to tax. So, despite my concerns regarding their policy, I was very pleased with their willingness to accommodate my wishes with the bounty payout.<p>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.
Solid writeup, but that bug bounty policy...<p>> DoS Attacks: $100,000 USD in locked SOL tokens (locked for 12 months)<p>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.
A big absurdity I sense here. I'm talking about Solana here, btw.<p>* Considering the money flying around Solana and its heavy dependency on BPF, $100k payout per vuln is reasonable.<p>* 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.<p>* Note that bounty will not always solve the problem. If the vuln could be exploited for profit, Solana would've been already doomed.
Can someone explain the CVS 2021 46102 bug? Various sources tell me it was an integer overflow in some Rust. The faulty line was:<p><pre><code> let addr = (sym.st_value + refd_pa) as u64;
</code></pre>
I guess, the + is evaluated using 32-bit arithmetic and then it is cast to a u64, and thus overflow is possible? And in release mode, Rust doesn't trap integer overflow.<p>Shouldn't something as critical as the EBF compiler be trapping integer overflow?
This is interesting -- I generally think of memory bugs being harder to exploit because of memory protections (stack canaries, ASLR, etc) and code execution being the goal. A quick read of this article it seems from the nature of crypto it was enough for reward to just crash the network (denial of service).