Vulnerable Arm GPU Drivers Under Active Exploitation, Patches May Not Be Available (arstechnica.com) 30
An anonymous reader quotes a report from Ars Technica: Arm warned on Monday of active ongoing attacks targeting a vulnerability in device drivers for its Mali line of GPUs, which run on a host of devices, including Google Pixels and other Android handsets, Chromebooks, and hardware running Linux. "A local non-privileged user can make improper GPU memory processing operations to gain access to already freed memory," Arm officials wrote in an advisory. "This issue is fixed in Bifrost, Valhall and Arm 5th Gen GPU Architecture Kernel Driver r43p0. There is evidence that this vulnerability may be under limited, targeted exploitation. Users are recommended to upgrade if they are impacted by this issue."
The advisory continued: "A local non-privileged user can make improper GPU processing operations to access a limited amount outside of buffer bounds or to exploit a software race condition. If the system's memory is carefully prepared by the user, then this in turn could give them access to already freed memory." [...] Getting access to system memory that's no longer in use is a common mechanism for loading malicious code into a location an attacker can then execute. This code often allows them to exploit other vulnerabilities or to install malicious payloads for spying on the phone user. Attackers often gain local access to a mobile device by tricking users into downloading malicious applications from unofficial repositories. The advisory mentions drivers for the affected GPUs being vulnerable but makes no mention of microcode that runs inside the chips themselves.
The most prevalent platform affected by the vulnerability is Google's line of Pixels, which are one of the only Android models to receive security updates on a timely basis. Google patched Pixels in its September update against the vulnerability, which is tracked as CVE-2023-4211. Google has also patched Chromebooks that use the vulnerable GPUs. Any device that shows a patch level of 2023-09-01 or later is immune to attacks that exploit the vulnerability. The device driver on patched devices will show as version r44p1 or r45p0. CVE-2023-4211 is present in a range of Arm GPUs released over the past decade. The Arm chips affected are:
- Midgard GPU Kernel Driver: All versions from r12p0 - r32p0
- Bifrost GPU Kernel Driver: All versions from r0p0 - r42p0
- Valhall GPU Kernel Driver: All versions from r19p0 - r42p0
- Arm 5th Gen GPU Architecture Kernel Driver: All versions from r41p0 - r42p0
The advisory continued: "A local non-privileged user can make improper GPU processing operations to access a limited amount outside of buffer bounds or to exploit a software race condition. If the system's memory is carefully prepared by the user, then this in turn could give them access to already freed memory." [...] Getting access to system memory that's no longer in use is a common mechanism for loading malicious code into a location an attacker can then execute. This code often allows them to exploit other vulnerabilities or to install malicious payloads for spying on the phone user. Attackers often gain local access to a mobile device by tricking users into downloading malicious applications from unofficial repositories. The advisory mentions drivers for the affected GPUs being vulnerable but makes no mention of microcode that runs inside the chips themselves.
The most prevalent platform affected by the vulnerability is Google's line of Pixels, which are one of the only Android models to receive security updates on a timely basis. Google patched Pixels in its September update against the vulnerability, which is tracked as CVE-2023-4211. Google has also patched Chromebooks that use the vulnerable GPUs. Any device that shows a patch level of 2023-09-01 or later is immune to attacks that exploit the vulnerability. The device driver on patched devices will show as version r44p1 or r45p0. CVE-2023-4211 is present in a range of Arm GPUs released over the past decade. The Arm chips affected are:
- Midgard GPU Kernel Driver: All versions from r12p0 - r32p0
- Bifrost GPU Kernel Driver: All versions from r0p0 - r42p0
- Valhall GPU Kernel Driver: All versions from r19p0 - r42p0
- Arm 5th Gen GPU Architecture Kernel Driver: All versions from r41p0 - r42p0
Qualcomm Socs not affected? (Score:4, Informative)
Qualcomm uses their own iGPU IP rather than Mali. So if you've got an Android device with an Adreno GPU in it then you're probably not affected.
Headline unclear (but what else is new?) (Score:3)
Is the claim that a "patch may not be available" because the exploit isn't patchable? Or are they just flogging the long-dead horse about how many Android phone makers don't offer security updates for existing phones?
TFS seems to imply the latter.
Re: (Score:3, Interesting)
The information I could gather seems to suggest the latter as well. Additionally, the communities for the Linux hardware in question has already long since moved on to reverse-engineered drivers and there's no evidence they were even tested for this vulnerability.
Re: (Score:2)
Users are recommended to upgrade (Score:3)
And how do I know if I am?
Re: (Score:2)
Check the specs of your phone (for example look it up on a site like gsmarena) and see that GPU it uses. If is a Mali chipset, then most likely you are affected.
Re:Users are recommended to upgrade (Score:4, Informative)
Looking at the article - rather than the summary - shows:
Re: (Score:3)
Devices believed to use the affected chips include the Google Pixel 7, Samsung S20 and S21, Motorola Edge 40, OnePlus Nord 2, Asus ROG Phone 6, Redmi Note 11, 12, Honor 70 Pro, RealMe GT, Xiaomi 12 Pro, Oppo Find X5 Pro, and Reno 8 Pro and some phones from Mediatek.
Don't forget the dozens of "brands" of no-name cheap phones and tablets using Mali.
Re: (Score:3)
I have a Samsung and - as far as I can see - I am potentially affected.
I looked up the specs for my device and it has a "Mali-G72 MP3" GPU, looking at "About phone" under Settings, "Software information" is the next to last entry there and my "Android security patch level" is 1 August 2023. My last Android update was 11 days ago.
On the other hand, local access appears to be necessary - this presumably means a rogue app - and I'm pretty restrictive on which apps I install. Hopefully Samsung are going to po
Re: (Score:2)
Re: (Score:3)
A neat idea. But you and I know that no beancounter will cut loose the money necessary to implement that. We're after all talking about a fundamental change in the core infrastructure of the internet (and, well, pretty much any network there is). This isn't like the shift from Token-Ring to Ethernet where companies did it whenever they had to redo the wiring of their companies anyway. We're talking about something that has to be done pretty much universally.
This will not happen unless companies have a very,
Is there a list of devices? (Score:3)
Even TFA talks about devices "believed to use" the affected chips. I thought we should probably know what chips are used in the devices we build?
Re:Is there a list of devices? (Score:5, Informative)
It 's complicated - Samsung market phones worldwide and I believe would select either Snapdragon (Adreno) or their own Exynos (Mali) depending on which 4G bands were supported - branded the same Galaxy model regardless.
We'll stop running untrusted code eventually (Score:2)
With all the side channel attacks and vulnerabilities in systems that won't ever be patched in time, untrusted code will be a thing of the past or at the very least restricted to highly abstracted virtual environments with very clearly defined and strictly limited interactions and minimal processing power. Many of the things we run programs of unknown origin for nowadays could just be static web pages.
Re: (Score:2)
Yeah. Makes Apple's walled garden look like a great idea. Even though I got android to develop on it I had so many malicious ads show up, the security plus being a part of family iPhone messages chat made me switch to iPhone and I don't regret it.
Especially the below quote.. somehow I think Apple will do a better job of validating app stores too when they become legislated, one can hope.
"This code often allows them to exploit other vulnerabilities or to install malicious payloads for spying on the phone use
Re: (Score:2)
One of many times: https://lifehacker.com/great-now-the-apple-app-store-has-malware-too-1849386738
And security issues like this have been found with iPhones before, except Apple literally couldnt fix the holes, where this is fixable with software. Checkm8 being one example. It effects (now older) A series, as well as Apple T2 chips and cant be fixed (became a bigger issue when
Re: (Score:1)
https://lifehacker.com/great-now-the-apple-app-store-has-malware-too-1849386738
Wait... your example "malware" exploits the victim with "an abusive download of data that is not related to the application purpose"...
And security issues like this have been found with iPhones before, except Apple literally couldnt fix the holes
[citation needed]
Re: We'll stop running untrusted code eventually (Score:2)
Literally the next sentence.
Re: (Score:1)
Checkm8(released in 2019) allows you to exploit iPhone 7's security(released in 2016) and basically get anything off the phone if you have physical access to the phone. Checkm8 is partly applicable to iPhone8-X, but you can't bypass the Secure-Enclave, so without the passcode/fingerprint and physical access you can't do anything.
Re: (Score:2)
Its like you are cherry picking to only get the answers you want, and avoid reallity. Oh, wait, thats exactly what you are doing.
Re: (Score:2)
Please distinguish "untrusted code" from the kind you should trust.
Memory safety or code signing or attestation or whatever else do not guarantee security or privacy or anything else. Writing good code is hard; it's a constant trade-off between a dozen goals. Error checking and fault detection detract from efficiency. Crime prevention is in tension with user privacy. Functional correctness in corner cases adds development time. And so on. There's no silver bullet that guarantees usable code with zero
Re: (Score:2)
Untrusted in the sense that someone else decides you should run it. Obviously if you download just any app that promises you free movies or something like that, you're still going to get owned, but the way it is today, that we run megabytes of code just to read a paragraph of text, is unsustainable. Running code should be the exception, not the rule. It's a risky thing to do. A web page should work without Javascript.
Re: (Score:2)
Stop running untrusted code?
That depends on the scope - what untrusted code means
javascript?
HTML5 -> webGL ?
ohh yeah trusted code from a walled garden,
where the garden's keeper had her keys copied.
walled garden - a nice looking prison, with flowers.
IPO (Score:1)
They knew this was a thing before their IPO last week. This might end in an investment fraud investigation.
Re: (Score:2, Interesting)
It appears that the rapid rise of RISC-V prompted a rushed IPO.
There are many underplayed risks for investors, IMO.
Closed-spec Mali has been a thorn in my side for over a decade. It was claimed that Mali engaged in massive patent infringement to remain viable (entirely possible) so it had to remain secret. Glad that we're moving past ARM now.
Re: (Score:3)
But RISC-V has all the same problems that you mention. The GPUs that vendors choose to put in their RISC-V SoCs are just as proprietary, closed-spec, and secret as any ARM SoC, and all the same problems of boot loaders, binary blobs, and mesa and kernel forks that ARM does. If Mali is a thorn in your side, you'll have the same thorn with RISC-V, and I don't expect this to change soon.
Affected / Collector Thread - starts here (Score:2)
The reason why I start this thread is not to discuss but to collect with the help of the slashdot crowd.
Nokia G21 / affected (Score:2)
"ARM Mali-G57 MP1 / MC1" Valhall due to being integrated into "UniSoc T616"
good thing:
Nokia does supply updates for this phone, so we expect to see some, however everybody who has such a vulnerability should pay attention and update as soon as available.