In the timeline, you can see they seemed unable to replicate it on a Pixel 5. Pixel 3 was already end-of-life at that point. Pixel 3a was still supported but only had a few months left before end-of-life. If it only impacted 3rd gen, there's the reason for the bounty amount.
Conversation
If it was reported a few months later, they wouldn't have considered it a valid issue unless it impacted 4th or 5th generation Pixels too. It's just how it works: the bounties are for their supported products, and 6th gen Pixels are the first ones with 5 years instead of 3 years.
1
This issue actually impacts all the Pixels, from Pixel 3 up to Pixel 5. We only exploited Pixel 3 and 3a (which was not end of life at the time) because these were the devices we had in our hands. But it is true that we did not tried to reproduce this issue on any Titan M2.
2
You’re unable to view this Tweet because this account owner limits who can view their Tweets. Learn more
Titan M2 is a totally different thing where they did away with the Cortex secure element. They were probably working on that for at least 2-3 years before Pixel 6 launch and had Pixel 7 in development already, etc. so they see it as older than the public sees it based on launch.
1
They don't state it on the page but I doubt they will pay out the stated bounties for issues not impacting the most recent Pixels since they'll see it as something they addressed already. They can't go back in time and upgrade hardware they already sold, but they mostly moved on.
2
You’re unable to view this Tweet because this account owner limits who can view their Tweets. Learn more
It has a lot of impact but whether it will be relevant going forward definitely sways the bounties. If you report a mem corruption bug in a C++ component that they've internally rewritten in Rust, they are probably going to see it as something they already addressed internally.
2
And I mean even if they haven't shipped the improvements eliminating it, they'll see it as essentially resolved internally already. The vast majority of their engineers are focused on the latest and greatest code and don't really do much work on the stable releases, etc. at all.
2
We have a lot of communication with people there and the fact that we're using stable releases while they're spending nearly all their time on much newer stuff is a communication issue. To them Android 13 is already old news and they're way past that already working on new stuff.
1
A few months ago, they gave us a rebuild of the keystore HAL with a bug fix for a security feature. They gave us both Android 12.1 and 13 libraries. Android 13 was just released 2 days ago. They didn't actually ship the fix for 12.1. We have to check if it's in 13. Takes so long.
You’re unable to view this Tweet because this account owner limits who can view their Tweets. Learn more
Nah, it's not that. It's not a security bug but rather a security feature exposed as an API to apps is breaks 'safely'. The anti-rollback counter in the news must be for a verified boot bypass in the SoC boot chain. They often increment Titan M anti-rollback counter with no news.
1
Show replies