Google Fixes Android Kernel Zero-Day Exploited in Attacks
16 comments
·February 7, 2025Semaphor
sevg
Worth noting the submitter is just blogspamming links from this domain.
View this logged in and see an ocean of flagged submissions: https://news.ycombinator.com/submitted?id=tuzzmaniandevil
tux3
Logic error in a video frame parser written in C, running in ring 0. No bounds checking. Another Friday.
Diff: https://android.googlesource.com/kernel/common/+/96ad4e759ff...
tialaramex
This sort of code (for, you know, Wrangling Untrusted File Formats Safely) should be written in WUFFS.
The nice thing about WUFFS for this specific problem is that although it's an entirely safe language† and is exactly the right way to do this, it also transpiles to C, so you can do the "Write file format code" stuff in WUFFS, transpile to C and then just land both in the kernel source.
[You might wonder: Why both? Surely the C is enough? No, the GNU GPL says you should provide preferred form for modification and clearly the preferred form for this code is WUFFS source not C, the provided C is just so that people don't need the WUFFS transpiler to build Linux if that's what they're doing]
† Entirely safe here meaning these mistakes won't even compile in WUFFS.
wereHamster
Isn't it tragic that both Android and WUFFS are built by the same company? Sounds almost like the left hand doesn't know what the right hand is doing (or willingly ignores).
ajross
Despite the terminology in the article, this isn't an "Android" bug and wasn't "written" by Google. In fact the relevant code predates Android entirely.
ajross
Not to interrupt your righteous indignity, but this bug is ancient. The relevant bug appears to be unchanged since this file was merged in June 2008. Writing it in Rust or whatever wasn't really an option.
This attitude sort of irks me. It's not enough in a modern world of outrageous complexity to pronounce what should have been done. Someone needs to be actually doing it. I mean, let's be specific here: where exactly is the memory-safe USB UVC driver you think Android should be shipping? And if it doesn't exist, why doesn't it exist yet? That seems, IMHO, to be a more serious roadblock than the bug itself.
1oooqooq
at least better response when they had a remote exploit on the pixel modem os wich allowed full phone takeover and just delayed one update for almost two months and tried to pretend there was nothing to see there.
Jach
https://nvd.nist.gov/vuln/detail/CVE-2024-53104
Maybe dang can change the URL to one of the sources at the bottom, this is too obviously and annoyingly AI-written...
sandreas
How does the exploit work? Can it be executed remotely, even via prepared websites or is access to the Hardware required?
shakna
It's an out-of-bounds write, caused by injecting UVC_VS_UNDEFINED frames into the video file, as they weren't size-handled correctly.
Which means, unfortunately, that playing a video file with that particular driver is all that would be needed.
The constructed video file would need a second exploit to jump out of the virtual memory of the driver and into the kernel, but that has happened before [1]. It's a high risk. Or it could just be used to crash every device that sees the video in a DoS attack.
However, the devices that use those drivers tend not to be end-user devices (webcams, smart TVs, TV tuners, recorders, etc.) They would be used as an entrypoint, before moving laterally into a network. So, standard IoT type breach.
[0] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux...
ajross
This is not correct. The UVC code isn't involved in the playback path. It's the USB class driver for video capture devices. You have to plug a malicious webcam into the phone.
hkwerf
That's what I'm wondering too. This is in uvcvideo, processing data from USB-connected cameras.
So, maybe you can exploit it by connecting a camera to the USB port? That would be bad enough. But this code only seems to be called if a video stream is active. So things like unlocking a locked phone seems improbable to be possible.
KwanEsq
Well that depends, the camera app is generally accessible on locked phones, so the question is, can the camera app make use of USB-connected cameras, and if so is there any restriction on accessing such cameras in locked mode (like there is a restriction on accessing past photos).
hkwerf
I'm not sure, most vendor camera apps were pretty much tied to the particular camera on the phone, on the phones I've had. For UVC, I usually needed to use another camera app.
You could try to initiate a video call with the locked device, though.
ajross
It's in the USB UVC video class driver, so no. You need to plug a malicious piece of hardware into the device, presumably.
Was this written by AI? Every paragraph repeats a lot, while saying very little. Looking at their article images, I’m going to say probably. [1] seems like a better source, first thing I found, but it has actual content, maybe someone else will find a proper link.
Anyway, this was probably why GrapheneOS released the early [0] security patch
> This is an early February security update release based on the February 2025 security patch backports since the monthly Android Open Source Project and stock Pixel OS release scheduled for this month hasn't been published yet.
[0]: https://grapheneos.org/releases#2025020300
[1]: https://thehackernews.com/2025/02/google-patches-47-android-...