[hn92726819]

I don't understand why they say you need physical access to the device. The Play Store has access to remotely install apps; surely it can enable them. I'm going to try this today.

You can log in to the Play Store on a computer and click "Install" and it'll ask you what device you want it on.

I'm not saying Graphene has this app, I'm just talking about their claim that physical access is required to enable it on non-Graphene pixels.

[ffsm8]

Apps don't have root permission and most Apis aren't available until the user accepted a prompt for the permission. And this specific API is likely only possible through adb, though I'm not further informed then this cited thread.

Could they change that in a software update? Sure! But they could also just push an update that crypto locks your device unless you pay them a monthly fee. The technology exists to do so, your trusting the OTA update provider not to do so. Just like with every other device you're running updates on, wherever that's your laptop, TV, fridge, smart mirror, speakers, doorbell, lightning or... whatever else has firm- or software in your household that you choose to update, manually or automatically.

[hn92726819]

> most Apis aren't available until the user accepted a prompt for the permission

True in general, but not true for preinstalled installed. System apps are already granted permissions on a fresh install (for example, Google Play Services has basically every permission, but you were never prompted).

Also what I'm describing isn't an update. At runtime, no update or reboot required, you can tell Play to install an app on your phone. Google then tells your phone to install it. I bet the mechanism is the same to enable a disabled app. I do know play store can enable disabled apps, I just don't know if it can be done remotely.

Edit: here's proof you can Enable a disabled app: https://storage.googleapis.com/support-forums-api/attachment...

Here's proof you can remotely install apps: https://support.google.com/googleplay/answer/14274288?hl=en

If you put these together, you have this app that can be remotely enabled, contrary to what Graphene is saying.

[ffsm8]

Neither of these proofs actually prove anything.

The first one has nothing about any disabled apps

The second one explicitly states that you're only able to install on your own device. And even if you doubt that... This still won't help you unless the user also opens the application and accepts the pop-up for scary permissions.

[diiidn]

Okay let's say the app can be enabled remotely by someone other than the user of the phone.

What next? Have you looked at the app? What can actually be done with it? Please explain the exact steps an attacker would take next, with evidence.

[throwaway290]

This thing being there is evidence something somewhere went super wrong and now the entire system cannot be trusted by default.

Ask: was it put there intentionally? If yes, why? If it is there by mistake, and no one at google noticed it there, then how many other (actually properly hidden and actually exploitable) backdoors did they miss in their phone?

[strcat]

The Verizon retail demo mode doesn't become active if the package is enabled and regardless they haven't actually demonstrated enabling any of the Verizon apps on Pixels through the Play Store. Enabling the retail demo app doesn't add any remote attack surface.

Verizon's Android apps are additional attack surface for Verizon Android users on any Android device with proper support for Verizon. The retail demo app has yet to be shown to add any relevant attack surface. Despite that, there's a massive amount of news coverage portraying it as if this was accidentally included (it wasn't) or included for no explicable reason (it used to be used by Verizon for demos in their stores). The other apps in the suite are used as part of providing useful Verizon features because they refuse to do things in a standard way.

GrapheneOS has never included these so it's missing features on Verizon including Wi-Fi calling which work with any normal carrier such as T-Mobile. We're previously analyzed the apps and have repeatedly written about them and our privacy/security concerns. The retail demo app isn't part of what's concerning from our perspective.

iVerify, etc. talk about iOS not including carrier apps but it has included a lot of similar functionality for carriers. They're portraying it as Google not having access to the code and not knowing what the apps do which is at least to us is a strange thing to assume. There are many things wrong with the overall claims. The motivation to promote their product by portraying it as finding this is clear, but they clearly shouldn't get credit for that and we've demonstrated that in our thread. We can provide further examples beyond the thread and commit we linked. This section talks about the carrier apps and is not new or modified recently:

https://grapheneos.org/features#broad-carrier-support

We have a lot of past threads on Twitter about it. A lot is on our pre-2018 Twitter account which got stolen from the GrapheneOS project.

[strcat]

Enabling the package doesn't mean the app is active. You also haven't actually demonstrated enabling any of the non-Verizon apps on a non-Verizon SIM with this. You're presenting it as contradicting what we've said but you haven't and are mistaken about what's needed to enable the Verizon retail demo mode. Simply having a Verizon SIM enables the package but the retail mode app is disabled unless the device is put in demo mode with an under the hood setting change.

[strcat]

A response from GrapheneOS:

Enabling the package doesn't turn it into a remote security vulnerability. It's still not active.

The overall Verizon carrier support apps get enabled when you have an active Verizon SIM and disabled when it's not active. Retail demo mode requires additional setup. The other Verizon apps implement production functionality and add attack surface that's exposed along with giving Verizon a questionable level of control. We've repeatedly talked about it and explained why we've always omitted them, which causes a loss of Verizon on Verizon's network. That includes talking about it with the CEO of Trail of Bits and others involved in this. The focus on the retail demo app in particular is strange. The claim that it was discovered by iVerify is strange. iVerify is an EDR app which runs in the app sandbox and can hardly do anything more than scan the static manifest and code for each APK. It doesn't even have anywhere close to the level of access of analyzing the firmware and software through the published code instead of from an app sandbox. Sure, it can see these, but it can't see huge parts of the OS and firmware from there despite it being publicly available. It's a very contrived way to promote iVerify and take credit for finding something they weren't the first to discover something that the Android security research community has been talking about and analyzing for many years. People who aren't security researchers have talked about these apps in quite a lot of detail years ago. Here's the Showcase app id, for doing a quick web search:

    com.customermobile.preload.vzw

Using ADB doesn't just require physical access but rather physical access combined with the user's password, even if the user's device is already unlocked due to enabling developer options requiring it. Otherwise, you would need exploits. Regardless of the approach, what purpose does using this app serve? ADB gives far more access. Filesystem write vulnerability gives far more access.

Stock Pixel OS doesn't implement the same level of verified boot as GrapheneOS and it's not relevant to the way they do things. It's theoretically relevant to verified boot on GrapheneOS but the app has NEVER been included. If this app was included in GrapheneOS, it would present a very contrived example of a privilege escalation option for the verified boot threat model. In practice, it wouldn't actually matter because there are better known ways to do it. We don't claim verified boot on GrapheneOS avoids trust in persistent state to the point this would be relevant at all. We are gradually removing trust in persistent state but that's a long road.

Here's one of several places we publicly documented the fact that we don't include these apps from the stock Pixel OS (they aren't part of AOSP) with a basic explanation of why we omit them:

https://grapheneos.org/features#broad-carrier-support

We've always omitted the Showcase retail demo app but we never considered that to be a particularly relevant part of omitting these apps since it requires special setup, unlike the others which actually run and expose attack surface when using a SIM for that carrier. The Verizon apps get activated not only on Verizon itself but also the Verizon MVNOs.

We don't have an issue with talking about the security threat of the Verizon apps activated when using a Verizon SIM. It's an issue for Verizon Android users, not Pixels specifically, and not Pixel users on non-Verizon carriers. The story is framed in a highly inaccurate way where iVerify gets credit for finding a Pixel vulnerability which they present as being the inclusion of an app which isn't really part of the real issue. They didn't discover these apps, the privileged permissions they're granted and what they do including the connections they make and lack of HTTPS for the demo app. Other people just didn't try to push Verizon's retail demo app as a security vulnerability specifically on Pixels to promote their product.

Talking about this as if Google accidentally included the app or that there was no reason to include it is very strange. They're well aware of why they included the apps as part of the Verizon partnership and what they do. Google appears to have written significant parts of some of them. They know what they are.

There are vulnerabilities discovered in Android on Pixels on a monthly basis including serious ones. This doesn't even seem to qualify as Low severity. Why is it deserving of all this media coverage pushing it as an incredibly serious issue? Google already publicly removed the app as part of Android 15. Can see that from the Android 15 Beta. That's likely being released in September. The amount of time they'd have taken to fix it if they'd classified it as a valid Low or Moderate severity issue may not have been any quicker. Not really clear what the fuss is about.

It's pretty sad that news sites largely operate as a press release system for well connected companies to promote their products with incredibly dubious claims. Incredibly warped way of getting information about security people, and it's harmful too. Non-Pixel Android devices don't even ship Low/Moderate severity patches until the next major yearly release since they don't ship the monthly/quarterly releases of Android like Pixels. How it is improving things to push people to less secure Android devices? How is it improving things to blame Pixels for Verizon's Android requirements for all Android devices? The goal is promoting a dubious product claiming it can meaningfully defend devices from within the iOS and Android app sandbox. An antivirus app with a basic DNS filtering/monitoring system and APK scanning is getting portrayed as a lot more that it isn't to get lots and lots of money. They successfully pushed a largely inaccurate set of claims across most major news sites covering tech to promote a product and a surveillance company. Why does tech news work this way, and how are they going to fix it?