The answer to this question is out there, but the reports are not published yet.
I caution readers to not make rash judgements on their skill like this though. These bugs are really hard to find, and it was a minor miracle that I noticed these ones at all. I actually had a whole list of critical bugs in this codebase ready to report before the V2 upgrade was merged to master (which would put it in scope for a bounty). However the auditors managed to find every single bug on my list. I only noticed the ones that eventually made it here later, by a stroke of luck, and after I had already spent a ton of time looking at this codebase without noticing them.
did you try other things like try to get employed by the team, or consider submitting an altruistic pull request? or was the bug bounty the adequate incentive from the getgo
Projects are free to change their terms and the page you link has been updated since I submitted my reports. The maximum was lowered to $1M and payment currency changed from USDC to SEI.
What sort of crime are you envisioning that exploiting this would fall under? It's not always fraud to satisfy a poorly written contract, although that is commonly the case.
It was advertised in advance, but the real gamble is on if they'll pay. If you go to my other blogpost linked in OP, you can see a case where I was owed 500k and paid 60k.
You're right though that it's a lot of risk. It's not something that most of the leaderboard works full time on, though some of us do. The immunefi homepage has a list of all the bounties on offer.
It's up there but not singularly so. Twice there have been $10M! You can see the leaderboard where the majority of crypto bounties are represented here (https://immunefi.com/leaderboard/) but you have to search around for the actual reports.
1. This is really hard to enumerate. I basically am always doing recon and don't do it 1 target at a time either. I'd been looking at Sei's V2 upgrade code on and off for months, and made my report when they merged the v2 branch to master (this action put the code in-scope for a bounty). I'd found a handful of other critical bugs on the way but they were fixed eventually either in the course of normal development or audits. I definitely spent upwards of 40 very focused hrs in total investigating this codebase along with its dependencies Cosmos/Tendermint. Probably much more time less focused. Cosmos&TM are quite big. But those dependencies are used in many other projects too, so it can't be purely accounted towards time on Sei.
2. I am a very experienced security researcher/pentester/whatever we want to call it, specifically in the blockchain niche. I'm OK at the other stuff (reversing, cryptography, web, mobile, etc). Networking probably alright? I'm comfortable saying I have a good mind for security and a wide knowledge of the basics in many fields, then a very deep knowledge of a select few areas.
2. Well, I'm currently not employed full time and I do spend a lot of time bounty hunting. But I mix it in with other things as well, like competitive security reviews on https://sherlock.xyz or https://cantina.xyz and private contracted security reviews.
Typically networking. I spent some time working at a reputable firm in this space as well.
One way to do this is to show some chops on the competition sites and then move to one of the organized freelance firms like Spearbit or yAudit. In doing all of these things you'll inevitably meet more people, build a specialty, get some reputation, etc.
Did you have to specify that it was a critical bug or haggle with them? On the immunefi site, their max bounty is set at $1M but you clearly got 2x that.
NAND flash is... weird. The old generation of SLC and MLC flash actually had more than the binary size, with the extra being used for error correction and wear leveling information. Newer MLC has larger "spare area", but is sufficiently unreliable that SSDs tend to round down the binary size to a decimal number and use the difference for replacing bad blocks as they wear out and fail.
TLC flash has a capacity that's actually a multiple of 3 times a power of 2, with an additional spare area. I believe a "128GB" TLC SSD might have somewhere around 150GB of writable bits.
Your computer does not have a problem with non-existing LBAs. The SSD controller might not like missing raw flash addresses, but that's abstracted away from the user perspective anyway, even if for no other reason than the FTL.
But spinning hard drive and SSDs are not working at the byte level, but at a power of two block. 512B to 4kiB usually.
You purchase a number of those blocks, and the total amount of byte is a power of two.
The filesystem then stores everything in it's own blocks, composed of one or more disk/SSD blocks.
Files on disk therefore consume a number of blocks, making their storage usage a power of two (the real size can by anything of course).
And you might as well align blocks to memory pages when buffering/reading/writing the filesystem. Since you must align memory access for performances with CPU cache, RAM is loaded/stored itself in blocks of 256 or 512 bits those days (yes reading one byte from RAM will rapatriate that much) etc.
That's a lot of power or two (you could argue power of 12 [4kiB]) designed everywhere.
> Technologists describe their systems as having “uptime” and measure it in “nines”, such as “We have five nines of uptime”, which means that a system has 99.999% uptime or, equivalently, about five minutes of downtime per year. Five nines is admirable in many circumstances and would be considered _disastrously_ below expectations for e.g. Google Search.
This seems wrong? 5 9s is probably a reasonable benchmark or even unattained goal for Google Search, right?
I caution readers to not make rash judgements on their skill like this though. These bugs are really hard to find, and it was a minor miracle that I noticed these ones at all. I actually had a whole list of critical bugs in this codebase ready to report before the V2 upgrade was merged to master (which would put it in scope for a bounty). However the auditors managed to find every single bug on my list. I only noticed the ones that eventually made it here later, by a stroke of luck, and after I had already spent a ton of time looking at this codebase without noticing them.