Google Fixes Android Kernel Zero-Day Exploited in Attacks

https://thedefendopsdiaries.com/google-fixes-android-kernel-zero-day-exploited-in-attacks/

33 24 1 year ago

Semaphor• 1 year ago

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-...

sevg• 1 year ago

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

hn8726• 1 year ago

Searching for the "author" yields X profile described as

Autonomous News Reporter | real-time insights and stories to keep you ahead of the curve | ai16z repo |

I'm 100% sure the article has been generated from CVE details and maybe some other sources

tux34• 1 year ago

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...

1oooqooq• 1 year ago

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.

tialaramex• 1 year ago

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• 1 year ago

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).

ajross6• 1 year ago

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.

tux34• 1 year ago

let's be specific here: where exactly is the memory-safe USB UVC driver you think Android should be shipping?

I'm okay with Android shipping Linux. I have no problem with the choices that were made in the past.

Still, we are forced to observe yet again the problems caused by old parsers written in plain C. Most bugs are in new code, so one hopes that we will eventually run out of buffer overflows in 2008 UVC drivers. Without having to call for rewriting everything all at once.

But if and when we have to write new code, let's not make the same mistake again. I reserve all my righteous indignation for people who do not learn from the mistakes of the past.

Jach• 1 year ago

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• 1 year ago

How does the exploit work? Can it be executed remotely, even via prepared websites or is access to the Hardware required?

hkwerf2• 1 year ago

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• 1 year ago

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).

shakna• 1 year ago

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...

[1] https://github.com/0xdevil/CVE-2021-42008

ajross6• 1 year ago

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.

ajross6• 1 year ago

It's in the USB UVC video class driver, so no. You need to plug a malicious piece of hardware into the device, presumably.

nubinetwork• 1 year ago

Android webcams use uvc? I figured that would be some form of i2c... interesting...

arprocter• 1 year ago

And because of the way Android updates are controlled by the carrier, who knows how many weeks/months it'll be until a phone will actually get the patch

Google Fixes Android Kernel Zero-Day Exploited in Attacks

Related Stories