Out of nowhere, a Bluetooth RCE vulnerability for Android was surreptitiously patched January 2019.
As far as I can tell, it was an ethical disclosure to Google that happened sometime before or during early November 2018.
It didn't garner much attention from anyone besides a few blog posts online that only briefly mention how the vulnerability is of critical nature.
What surprised me more than anything is that, considering how severe this vulnerability is, and how it can allegedly be exploited in person when close enough for Bluetooth radio, how nobody has done a write-up on it or investigated the vulnerability online yet.
I looked deeper into this and got the diffs from the source code before and after the fix to the vuln.
Here is the actual function in question:
And the only place where the function gets called is within this branch:
As you can see, there isn't a lot that was changed.
Besides what appears to be some renamed constants, the main difference is a change in the way the size of the number at the
bta_ag_parse_cmer is checked, using now a passed in parameter instead of utilizing a function that converts the string to an int.
This is a common occurrence, but if done incorrectly can result in logic susceptible to an integer overflow attack.
Still investigating this, will update further when I have the chance.
All versions of Android 7 though 9 are affected, meaning a large slice of the Android user base is vulnerable – worst part is, Android phones bought from manufacturers or carriers almost never get updated after the first few years.
If this ever gets picked up by bad actors, it could be a very interesting toolkit that might be used in worm-like attacks that spread like a disease throughout the whole world.
One car entertainment system or kiosk at a mall with Bluetooth on can get infected, and then infect any devices nearby that are vulnerable with a copy, and so on, to the point where a massive botnet propagated by Bluetooth could be under control by a single bad actor.
Reminds me of the BlueBorne vuln, a very similar vulnerability that got a lot more press. Not sure why this didn't land on anyone's radar.