Possible AB update security issue, mainly for developers

[mke208]

If you are a developer, maybe some time you flash a userdebug image to your phone (boot A) to test stuff. Then, you flash a significantly more secure user image, too boot B. A possible attacker can make the phone switch the A/B to previously installed userdebug image. You can do that on marlin by playing with the power button at boot time... I don't know if this is a bug or a feature, but the workaround would be after flashing a userdebug image(via recovery) and switching to a user image, flash the user image twice. first will go to A boot, second will go to B boot. Correct me if i'm wrong. PS: this is for technical people who like to play with their phones, regular users will not be affected.

[thestinger]

You can ask fastboot to flash to both slots with --slot all. It defaults to flashing the current slot.

[mke208]

I am not talking about fastboot flash, i am talking about adb sideload

[thestinger]

That's how sideloading is intended to work. It can be used for development but usually development would be done on a dedicated, unlocked device to save a bunch of time by not building the target files zip, signing everything in it to get a signed target files zip and then generating a signed over-the-air update zip from it.

[mke208]

Yes i know, that is why i said it is a "take caution" for developers ...

[thestinger]

You could disable part of what makes userdebug builds insecure by not bundling test keys and building adb in the secure mode.

[thestinger]

Having adb shell accessible su and debuggable apps isn't a very big deal, particularly if you're only worried about the threat from a past installation. Alternatively, add code to invalidate the other slot in late boot after the current slot is verified?

[mke208]

Maybe the idea is to remember what you flash before taking your phone to customs or what ever, and remember it twice. Most people are not developers or technical people and don't care about this. As a side note, i am still convinced that having physical access to a device is game over

[thestinger]

Sure, just swap the device with another Pixel and they type their password into the backdoored one -> use it to unlock the real one.

[thestinger]

The physical security features are primarily there as an theft deterrent and to greatly raise the initial barrier to doing on-device brute forcing or other tampering. OEM unlocking toggle is almost entirely for theft deterrence, it barely offers any useful security properties beyond that.

Signature verification in recovery and adb security are about more than a device falling into an attacker's hands. If you plug a device with a userdebug build into an untrusted computer, it's compromised without a vulnerability being exploited due to non-secure adb builds.

[mke208]

Yes, this is what i have been thinking of ... Instead of trying to break the encryption and stuff just swap the phone with an identical one and identical lockscreen, and go fi(phi)shing. This is why i consider a device that leaves your sight to be theoretically compromised

[thestinger]

userdebug builds expose insecure adb, test keys are partially trusted, attack surface in the OS, etc. too

[mke208]

in my opinion, the data is more important then the phone ... even if it's a 1.7K phone

[thestinger]

Just saying that userdebug builds also add problems like every connected computer being trusted. An attacker can have control over a connected USB device without physical access.

[mke208]

Userdebug is never ment for production and normal usage. In my oppinion they are "do what ever you want" builds ... The idea is that if you are a guy with a developed sense of curiosity like me, you can flash via recovery a userdebug build over a production build, see what's going on, and then flash again a newer user build ... just remember to do it twice :) signed with my keys obviously

[mke208]

userdebug = god mode :)

[thestinger]

You could enable the su sepolicy / binary in user builds without the other more significant risks if you wanted.

[mke208]

there is no point on enabling root access on user builds. that would kinda defeat the purpose ... btw did you guys get my last e-mail ?

[thestinger]

I don't handle the main copperhead.co email addresses, so I don't know.

[mke208]

side note, if you install a reasonably secure OS, and then complain that "facebook doesn't work, instagram doesn't work, whatever social network doesn't work" then you are in the wrong boat :)

[mke208]

dont know if is appropriate to ask here, but if you have time, try to check some connections that izat and lowi try to make to qualcomm, even if location services are disabled. It seems to me that qualcomm does not care about our settings and try to connect to the izat servers anyway. I worked around this problem by deleting the "offending" libs

[thestinger]

BTW, which carrier do you have? Having a lot of trouble working on carrier support without having access to other ones.

[mke208]

Vodafone Romania. But i don't think qualcomm/izat/xtra is carrier related ...

[thestinger]

It's a mostly unrelated question. And BTW the xtra downloads are done by system_server, AFAIK, so we're in direct control of that and could change it.

[mke208]

yes, i tried blocking it with iptables, but it keeps trying and trying ... on my builds root does not have internet access. the log was full of "trying to connect to xtra server" . then i just deleted the offending lib, and i just get a "canoot find lib" error when i turn on the screen. more quiet now

[mke208]

"politically correct" would be when location services are off, xtra/izat/etc should go away

[thestinger]

You can probably just disable the code that triggers it in system_server.

[mke208]

i don't think i can, because they are loaded by other qualcomm /vendor stuff . i dont think they are related to system_server. but again i'm not a good coder :) as another side note, ought to find a coder that can mess with the radio, because that is where the most important stuff is ...

[mke208]

one more question, is the github copperhead identical to the paid one ?

[thestinger]

Yes, other than not including the Updater app since it would need to be pointed at a different server to use it for unofficial builds.

[mke208]

Allright, i do appreciate all the work and i will make a donation, hope you accept bitcoin. Thanks for all your work.