In late 2022, Samsung patched a security issue in the GalaxyWatch4Plugin — the software bridge that connects your Samsung smartphone to a Galaxy Watch device. This vulnerability, tracked as CVE-2022-39889, may have let malicious apps access sensitive info from wearables, just by being on your phone. In this post, we’ll break down what happened, how attackers could have exploited it, and see a code example that shows the risk.

What is CVE-2022-39889?

At its core, CVE-2022-39889 is an improper access control bug. Think of access control as the rules about who can read or change your private info. If those rules are too loose, apps can see things they shouldn’t.

Specifically, in GalaxyWatch4Plugin (the “plugin” that syncs your watch and phone), versions earlier than 2.2.11.22101351 and 2.2.12.22101351, there weren’t enough checks when apps asked to see your wearable device’s info. This means a random app—without special permissions—could ask for things like the device model, status, and potentially fitness data.

How Could an Attacker Exploit It?

Let’s imagine you install a perfectly normal-looking app from the Play Store. Behind the scenes, the app contains malicious code. Because of this vulnerability, the app could quietly ask the GalaxyWatch4Plugin for information about your watch—maybe your device name, battery status, paired state, or more.

The plugin should only share this info with authorized Samsung apps. But due to the bug, any app with no permissions could do it.

Example Proof-of-Concept Code

Here’s a simplified example of how an attacker’s app might fetch info from your Galaxy Watch using this bug. In Android, you often communicate between apps using intents. The plugin exposed public components (like services or activities) with no permission checks:

// Malicious app could try this code to get watch info
Intent intent = new Intent();
intent.setComponent(
    new ComponentName("com.samsung.android.galaxywatch4plugin", 
                      "com.samsung.android.galaxywatch4plugin.DeviceInfoService")
);
// Use your own PendingIntent or bindService to connect
// (details depend on which service/activity is exposed)

// Try starting the service and hoping for a response (old versions would allow)
context.startService(intent);

// Or, try to bind and get the info directly
ServiceConnection connection = new ServiceConnection() {
    @Override
    public void onServiceConnected(ComponentName name, IBinder service) {
        // IBinder interface may allow info queries
        // E.g., Parcel in/out, depending on Samsung’s API structure
    }
    @Override
    public void onServiceDisconnected(ComponentName name) { }
};
context.bindService(intent, connection, Context.BIND_AUTO_CREATE);

*Important*: This is a demonstration; the exact method depends on how Samsung coded the exposed component, but the point is that no permissions were checked before responding!

...Basically, more than you’d expect a simple third-party app could learn.

While this isn’t as severe as stealing your passwords, it still invades your privacy and could be a springboard for phishing your watch or tricking you with targeted spam or malware.

How Did Samsung Fix It?

In the fixed versions (2.2.11.22101351/2.2.12.22101351 and up), Samsung added proper permission checks. Now, only trusted (Samsung-signed) apps can ask for information from GalaxyWatch4Plugin.

If you keep your phone and Galaxy Wearable apps up to date, you’re protected. If you haven’t updated — do it now! (Go to Settings > Apps > GalaxyWatch4Plugin > App details in store.)

References & Further Reading

- Samsung Security Bulletin for CVE-2022-39889 (direct link)
- Mitre CVE Database: CVE-2022-39889
- NVD Details: CVE-2022-39889

The Takeaway

Access control is a basic but vital part of app security. If apps can talk to each other without any restrictions, your phones and wearables are at risk. Samsung handled this bug, but it’s a reminder: keep device plugins updated, and be careful what you install.

If you care about privacy, audit your app permissions. If you're a developer, always check if your app's public services or activities are properly protected—otherwise, your users could be the next ones exposed.

Timeline

Published on: 11/09/2022 22:15:00 UTC
Last modified on: 11/11/2022 02:20:00 UTC