Acknowledged
3 months ago

CIQ store app (iOS) falsely shows settings from *wrong app*, when two apps are installed with similar settings definitions

Connect IQ Store app version 2.30.1 (iOS)

I have a data field app that has 4 "clones" in the store. They're all basically identical except for their app UUID, app name, and certain default settings.

AppBuilder 5: https://apps.garmin.com/apps/fd690281-9c22-4fee-a81e-3b7f39aa67c5

AppBuilder 5 (B): https://apps.garmin.com/apps/706e91ae-7b84-4ac3-b0a7-dc2bcceb6fc2

AppBuilder 5 (C): https://apps.garmin.com/apps/f5259a68-1509-4ee9-9a05-46dc1d939f3f

AppBuilder 5 (D): https://apps.garmin.com/apps/394b4149-6d5a-4c2c-836d-dca71ea10b98

I had AppBuilder 5 installed on my 955, but none of the other clones were installed, and I had made extensive changes to the settings of AppBuilder 5. Subsequently, I installed AppBuilder 5 (B). When I opened AppBuilder 5 (B)'s settings in the CIQ app, it showed me settings values for AppBuilder 5, instead of 5 (B)'s defaults!

But when I added AppBuilder 5 (B) to an activity, it was clearly using its default settings values (one of the settings controls the data field label.)

Reproduction Procedure:

- If any of the AppBuilder 5 data fields are installed on your device, uninstall them

- Install AppBuilder 5 and open its settings in the CIQ store app (iOS)

- Note that the default value for "Profile 1 - Label" is "AppBuilder".  (The default values for the other apps are "AppBuilderB", "AppBuilderC", and "AppBuilderD")

- Change "Profile 1 - Label" to "Custom Label" and save settings

- Add AppBuilder 5 to an activity and note that the displayed label is "Custom Label"

- Install AppBuilder 5 (B). (Do not modify its settings or launch the app on the watch)

- Install an unrelated app, such as HM's DIY #1

- Open HM's DIY #1's settings. Exit without saving

- Open AppBuilder 5 (B)'s settings: note that the value for "Profile 1 - Label" is correctly displayed as "AppBuilderB". Exit settings without saving

- Open AppBuilder 5's settings. Exit without saving

- Open AppBuilder 5 (B)'s settings: note that the value for "Profile 1 - Label" incorrectly appears to be "Custom Label". Exit settings without saving

- Add AppBuilder 5 (B) to an activity and note that the displayed label is "AppBuilderB"

- Open AppBuilder 5's settings. Exit without saving

- Open AppBuilder 5 (B)'s settings. Note that the value for "Profile 1 - Label" is now correctly displayed as "AppBuilderB"

The same problem can be demonstrated with any of the 4 clones.

EDIT: as mentioned in a comment below, I think this is a potential security issue.

EDIT2: Simplified recreation procedure:

- install an app (B) with settings but do not modify settings or launch the app on the device. (App B's settings are uninitialized.)

- install a related clone app (A) with similar settings to B. Modify settings so that they're recognizable

- Install an unrelated app (C) with dissimilar settings to B

- Open C's settings, then open B's settings. B's settings will show B's default values as expected. (Do not save B's settings at this point)

- Open A's settings, then open B's settings: you will see A's settings instead of B's default values

FlowState
Parents
  • 3 months ago

    > (I never have been a fan of cloning, but that aside...)

    Yes we talked about that, but I did it bc users asked for it. I think it's worse when some devs have dozens of a data field for different devices / functionality, although the device-specific clones will only really be a problem on store website, and I bet most normal users exclusively use the store app.

    > Interesting bug where you seem to be able to affect settings from other apps.

    This bug seems to affect what's displayed in the CIQ store app, but not the actual settings on the device, unless the user edits the "fake" settings in the CIQ app and saves them.

    This seems to indicate that:

    - Initially properties (related to settings) are null / non-existent on the device (as opposed to taking on the settings default values at the time of installation). I think this was probably explored years ago, but the question has come up a few times since then

    - In this state, the device uses the real default settings whereas the CIQ store app may use "fake" settings values from a different app

    - If the user launches the app before changing settings via the CIQ store app, then the real defaults will take effecf

    - If the users changes settings via the CIQ store app before launching the app, then the modified "fake" settings will take effect

    I think the privacy/security implications of this bug are fairly bad. If it's really just a matter of having the same property key as a different app, then one app could potentially "steal" data (in the form of settings) from another app, whether intentional or not. After all, security was cited as a reason that even apps from the same dev are not allowed to share data.

    e.g. Imagine a scenario where a bad actor makes a malicious app that has innocuous settings related to the app itself, but it also has properties/settings with key names like "username", "password", "unlock_code", etc which may correlate to sensitive settings related to other apps. The bad actor can add enough legit settings so that the bad settings are at the bottom of the page. Since the Save button is at the top of the page, the user wouldn't need to scroll to the bottom of the page to save settings, so they wouldn't necessarily notice that settings from another app had been captured by this one. The bad actor could also designate all of the malicious fields as "password" fields which would make it harder for the user to realize that data is being "stolen".

    Ofc the mitigating factors are:

    - This only works before the user launches the app for the first time after installation (but if they just installed the app, they may want to set it up immediately)

    - The user might notice that there are suspicious fields which don't seem related to the app (but ofc the bad actor could try to use innocuous labels, or to have functionality which overlaps with the stuff they're trying to steal)

    - The bad actor has to guess the names of app keys they want to steal (unless they're targeted a non music app that supports older devices, in which case they can just copy the app PRG off the older device and analyze it.)

Comment
  • 3 months ago

    > (I never have been a fan of cloning, but that aside...)

    Yes we talked about that, but I did it bc users asked for it. I think it's worse when some devs have dozens of a data field for different devices / functionality, although the device-specific clones will only really be a problem on store website, and I bet most normal users exclusively use the store app.

    > Interesting bug where you seem to be able to affect settings from other apps.

    This bug seems to affect what's displayed in the CIQ store app, but not the actual settings on the device, unless the user edits the "fake" settings in the CIQ app and saves them.

    This seems to indicate that:

    - Initially properties (related to settings) are null / non-existent on the device (as opposed to taking on the settings default values at the time of installation). I think this was probably explored years ago, but the question has come up a few times since then

    - In this state, the device uses the real default settings whereas the CIQ store app may use "fake" settings values from a different app

    - If the user launches the app before changing settings via the CIQ store app, then the real defaults will take effecf

    - If the users changes settings via the CIQ store app before launching the app, then the modified "fake" settings will take effect

    I think the privacy/security implications of this bug are fairly bad. If it's really just a matter of having the same property key as a different app, then one app could potentially "steal" data (in the form of settings) from another app, whether intentional or not. After all, security was cited as a reason that even apps from the same dev are not allowed to share data.

    e.g. Imagine a scenario where a bad actor makes a malicious app that has innocuous settings related to the app itself, but it also has properties/settings with key names like "username", "password", "unlock_code", etc which may correlate to sensitive settings related to other apps. The bad actor can add enough legit settings so that the bad settings are at the bottom of the page. Since the Save button is at the top of the page, the user wouldn't need to scroll to the bottom of the page to save settings, so they wouldn't necessarily notice that settings from another app had been captured by this one. The bad actor could also designate all of the malicious fields as "password" fields which would make it harder for the user to realize that data is being "stolen".

    Ofc the mitigating factors are:

    - This only works before the user launches the app for the first time after installation (but if they just installed the app, they may want to set it up immediately)

    - The user might notice that there are suspicious fields which don't seem related to the app (but ofc the bad actor could try to use innocuous labels, or to have functionality which overlaps with the stuff they're trying to steal)

    - The bad actor has to guess the names of app keys they want to steal (unless they're targeted a non music app that supports older devices, in which case they can just copy the app PRG off the older device and analyze it.)

Children
No Data