1015350 - CWM Bootloader menu exposes user data

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: General, defect)

Description

[JR Conlin [:jrconlin,:jconlin]]

Fun trick at parties:
* Get any device running Clockwork Mod and turn it off.
* Hold power and VolUp until the phone vibrates, release power, continue to hold VolUp
* Note the happy bootloader menu (This is a good thing because folks who brick their phone for whatever reason can at least wipe to factory defaults)

Note also, the "backup and restore" feature. This will allow the device to write /system and /user data to the SDcard (in spite of there being a lock code on the phone or not). This dumps a tar ball in to /clockworkmod/backup/(date).(time)/data.ext4.tar.a that contains a copy of everying on the phone, including user preferences and information. I'm willing to believe that pretty much everything that is written to internal storage gets dumped out.

I'm not really sure what the best mitigation technique is here. Certainly disabling the backup would help, as would preventing mounting of the /user partition.

Comment 1

[Daniel Veditz [:dveditz]]

We don't ship this, right? How is this our bug?

Comment 2

[JR Conlin [:jrconlin,:jconlin]]

Every b2g device I've used so far has this issue. (I've used both the geeksphone Keon and the ZTE Open) It's fair to say that it's not our problem and mark it as "won't fix", but I wouldn't presume that the device is secure-able in any sense either. 

I think that there's some merit for our security to reach out to the various android bootloader devs and raise the issue as well. We're building a product off of these things, we should be good citizens and note holes that should be patched.

Comment 3

[:gerard-majax]

(In reply to JR Conlin [:jrconlin,:jconlin] from comment #2)
> Every b2g device I've used so far has this issue. (I've used both the
> geeksphone Keon and the ZTE Open) It's fair to say that it's not our problem
> and mark it as "won't fix", but I wouldn't presume that the device is
> secure-able in any sense either. 
> 
> I think that there's some merit for our security to reach out to the various
> android bootloader devs and raise the issue as well. We're building a
> product off of these things, we should be good citizens and note holes that
> should be patched.

Keon's is recovery is under Geeksphone responsability, and given we never considered bugs reported on the Keon, I don't see why we would care about CWM recovery behavior on those device.

For the OPEN, to my knowledge and for the memory I have of hacking one no later than last week, I don't think it was loaded with a CMW allowing this.

But anyway, since we always never cared about recovery for those devices, leaving it to the OEM, I don't see where our responsibility lies.

Comment 4

[:gerard-majax]

On uptodate Keon's sources:

alex@portable-alex:~/codaz/Mozilla/b2g/devices/Keon/B2G$ grep -Ri 'backup' bootable/recovery/ librecovery/
bootable/recovery/install.c:int get_amss_backup(const char* amss_path_name1, const char* amss_path_name2)
bootable/recovery/install.c:        /* Backup radio image before proceeding with the update */
bootable/recovery/install.c:        ret = get_amss_backup(RADIO_IMAGE_LOCATION, RADIO_IMAGE_LOCAL);
bootable/recovery/install.c:            LOGI("Failed to get amss backup\n");
grep: bootable/recovery/.git/svn: Aucun fichier ou dossier de ce type
bootable/recovery/minelf/Retouch.c:            // to do the normal processing and overwrite the backup file:
bootable/recovery/deltaupdate_config.h://Backup of the original status
bootable/recovery/deltaupdate_config.h:#define DELTA_UPDATE_STATUS_BACKUP_FILE    "/cache/fota/ipth_config_dfs.bak"
bootable/recovery/deltaupdate_config.h://Predefined AMSS backup image name
grep: librecovery/.git/svn: Aucun fichier ou dossier de ce type
alex@portable-alex:~/codaz/Mozilla/b2g/devices/Keon/B2G$

Comment 5

[:gerard-majax]

Yet, the recovery is CWM-based when I boot the device. So once again, our sources are not in sync with the reality ...

Comment 6

[:gerard-majax]

I think you got mislead:
 - geeksphone uses cmw, but they branded the device as "developper preview"
 - the ZTE OPEN stock recovery does not have this feature, https://hacks.mozilla.org/wp-content/uploads/2013/12/ZTERecoverMode.jpg
 - the Flame T2M recovery does not have this feature either.

Comment 7

[Dave Hylands [:dhylands]]

Umm. Even if we disabled any of this you could just write a CWM which didn't have it disabled.

The only way I'm aware of actually securing a phone against these types of phones is to use a secure boot, where you're booting a signed bootloader & kernel which have the appropriate features disabled.

As long as the bootloader is unlocked, there is no protection, except for using something like an encrypted user partition.

Comment 8

[Dave Hylands [:dhylands]]

> The only way I'm aware of actually securing a phone against these types of phones

I meant to say: attacks not phones (last word above)

Comment 9

[:gerard-majax]

(In reply to Dave Hylands [:dhylands] from comment #7)
> Umm. Even if we disabled any of this you could just write a CWM which didn't
> have it disabled.
> 
> The only way I'm aware of actually securing a phone against these types of
> phones is to use a secure boot, where you're booting a signed bootloader &
> kernel which have the appropriate features disabled.
> 
> As long as the bootloader is unlocked, there is no protection, except for
> using something like an encrypted user partition.

That being said, at least on Flame there is support for secure boot. I don't know how the production devices are handled regarding this topic.

We can even build our own signed kernel: I did it, it works. And we have the bootloader that we can rebuild, also.

Comment 10

[BMO Automation]

Firefox OS is not being worked on