Google Fixes Android Kernel Zero-Day Exploited in Attacks | Hacker News Reader

Google Fixes Android Kernel Zero-Day Exploited in Attacks

thedefendopsdiaries.com

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

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

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

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

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.

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.

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

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.

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.

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

Right, but what I'm saying is that people aren't writing that new code because no one wants to.

Basically: If half the energy spent on righteous tut-tutting about Rust (or whatever) was given to writing memory-safe implementation of "boring" stuff like webcam drivers and not the sexy junk that ends up on HN, there'd be a lot less need for the irksome tut-tutting. Basically I think this says more about the psychology of the tut-tut set than it does development practice.

It isn't that there is a shortage of developers willing to write code. No, the kernel has entirely too many developers submitting to relatively few maintainers. So I don't take the psychology point at all. We already have more developers than we can handle.

The problem is elsewhere. We have another thread at the moment about opposition to Rust drivers in the kernel. Writing the boring code is, I think, the easy part. Getting it past the old guard is another fight entirely. And not always fought on technical grounds.

For every unit of energy that is spent writing code, twice that amount will be drained in endless bickering about whether modernity shall be permitted.

And till the barriers disappear, the flow of exhausting discourse will continue crashing against the immovable wall of how it used to be.

I'll have to be blunter: people who tut-tut about memory safety instead of spending their time working on rewriting "boring" software (USB video drivers in this case) in safe environments are a much, much bigger problem than the folks still trying to make C code work. Not only are you not fixing bugs, you're driving people away from the environments where those bugs still need to be fixed.

I'm sorry, I understood you the first time around. But I'm not sure you're applying your criticism homogeneously. Both sides in this argument are doing something which is not fixing bugs when they go online and write another reply, and of course they might think the other side is a much bigger problem.

There is plenty of code being written regardless. Not all of it makes it upstream, and that's for a different set of reasons. Discussion is not an indication of whether people also write code, in fact. Nevermind the fact that it takes two people to waste time arguing instead of fixing bugs.

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

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

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.

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

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.

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

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.

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

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

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

Reply on news.ycombinator.com