What is Tizen?

Tizen is Linux-based open source operating system developed by Samsung. Since the OS was envisioned to serve all kind of devices, it has been shipped with many Samsung products include smartwatch.

Gear series (now Galaxy Watch) is Samsung’s smartwatch products. It offers many useful feature like tracking fitness, receiving and replying to calls, texts, emails, and even paying for stuff with NFC.
To achieve all this, we share our highly sensitive information with the watch. For security reason, access to such privileged resources must be permitted based on proper access right.

In this post, I will focus on the Tizen’s security internal, especially their implementation of access control. And take a look at the privilege violation found by Dongsung Kim.

Video recording of the presentation at Defcon 2018 by Dongsung Kim and Prof. Choi.

For more information on affected systems see CVE-2018-16262~72 The technical details of the attack are available in our slides. Our repository contains the code that we developed to implement for our Tizen research.

Tizen’s Security Internals

In this section, we will get right into the internals of Tizen’s security. Our research highlight Tizen version 3.

Object

Since Tizen is based on Linux, there are typical stuff like files, directories, sockets and utilities. But we focus on application and services. Application use Tizen’s public, or private APIs to access the subsystems; such as frameworks and services. Services are special privileged daemons, each dedicated to a specific resource, ex) Wi-Fi, Bluetooh, GPS, messaging, etc.

Privilege

Service must validate if the calling app acquired proper ones. Similar to Android, app developers type in privilege strings in the manifest file. For example, we have the manifest file listing privileges like, http://tizen.org privilege/internet or alarm.set. The app market sign the tpk application package. On installation, user accepts the permissions on the screen. Then, the installer checks and registers the policies in the database. Finally at the runtime, access is controlled by the policies.

Tizen defines many privileges; Internet, Bluetooth, Network.set and more. However only some of them are “public” to app developers. There are also “partner” and “platform” level privileges, not for public use.

Access Control Mechanisms

To enforce the access policies Tizen implements three, plus one security mechanisms

Discretionary Access Control(DAC)

The first is the DAC: user ID and group ID, easily found in Linux

Simplified Mandatory Access Control in Kernel(SMACK)

The second is SMACK. SMACK is Tizen’s choice of kernel-space MAC mecahnism; like SELinux. The specifics are complex but conceptually: an app receives a unique label at installation. For every kernel object access, the current label or context, is checked against the rules in SMACK database.

Cynara

The third is Cynara. Cynara is Tizen’s user-space privilege management daemon. Services ask Cynara to check if the calling application has the privilege. Cynara identifies the application by its SMACK label, and validate it against the policies in the Cynara database

Security Manager

Security manager is a policy configurator. It reads the policies from the filesystem or the manifests, then fills the database we discussed, so DAC, SMACK, Cynara can recognize them.

D-Bus

How application talk to services. D-Bus is widely implemented IPC system for Linux-like OS, that also offers useful built-in functions like discoverability or introspection.

To put it simply, each service daemon registers itself to the D-Bus daemon, then clients dispatch request messages over a virtual channel. Tizen relies heavily on D-Bus for IPCs. So, lets look at D-Bus concepts using a typical D-Bus method call.

We want to send a request from a client to a service. The service process already has itself registered. The client process opens a connection to the bus, then the connection gets assigned a unique “bus name” (:1.7).

So now, the client sends a request message to the bus. The message reaches the service, whose connection also has a unique bus name, and an optional “well-known” bus name; org.example.service.

The request is to invoke SetFoo method of the object: /org/example/object1. The object implements the interface; org.example.interface, which specifies methods like SetFoo and GetFoo. And finally, the service responds with a message.

Cynara-aware D-Bus

Tizen’s D-Bus is Cynara -aware, meaning it is patched to natively perform privilege checks. Upon receiving a message, the D-Bus daemon in the middle asks Cynara for validation.

This approach allows the D-Bus daemon to control access on messages. On the example shows the Bixby assistant bus configuration file. You can see there is a check element with destination, interface, member method, and privilege attribute.
So whenever D-Bus daemon receives a message, it queries Cynara to see if the sender has the privilege, then decide accept or deny the message.

Deeper with an Actual Code

Let’s dig a little deeper with an actual code example, how an API calls sends a request to a service, and its privilege gets validated.

We’re going to start with Location Manager API with proper “local” privilege. Upper code shows that the privilege string is in the manifest. The client process “logic” function below, creates a manager handle, starts the manager handle, starts the manager, and print out the result of the log.  In the shell of the device, we can see the result is 0, which is a success.

First Privilege Check : Cynara

Now let’s try the same thing without the privilege

The log shows PID and -13 as result which means failure. And we can see the Cynara_check failed message. Location library “lib lbs location” is responsible for the log; by calling location check Cynara function. This is the first privilege check down the chain of a service request. 

By reverse engineering the location library, we can find where check happens. Since the library is linked to the client within the same PID, client can simply live-patch the instructions. Remove the code, write zero to the register 0, then we bypass the first check.

Second Privilege Check : D-Bus

Upper code shows the live-patch, mprotect to enable write, then simply overwrite the memory. When we run this the result is still failure. However, the log changes. A D-Bus Access Denied Message still withing the same PID is printed out, in violation of the privilege: http://tizen.org/privilge/location. We can see D-Bus library LBS_DBUS_CLIENT sends a request to  lbs server. The error shows the request access is denied by D-Bus daemon, which queries Cynara in the middle.  This is second privilege check of the chain.

Third Check : Service Daemon

On the top an app using location API links the location library. Then the Library queries Cynara for the first time. If that passes, a D-Bus request is sent, then the D-Bus daemon in the middle queries Cynara, for the second time. If that passes, the location daemon receives the request, which could potentially query Cynara for the third time. Then finally request reaches the hardware below.

We’ll talk more about this third check in the next section.

Securing Services

If the client is a malware, however there is no “first check” anymore, So, there are two point that can actually secure the service.

• D-Bus daemon : Request in the middle

• Service daemon : After receiving the request

If the OS or the service developer fails to implement both of them, privilege violation can happen.

Finding Violation

Let’s move on to actually finding violations. To do so, let me introduce a simple tool we developed named Dan the D-Bus analyzer.

We send a D-Bus request to a safe service with no argument given. Without the privilege, Access Denied is returned. With the privilege through, “invalid arguments” is returned. When you think about it, the errors suggest privilege validation always happens first, ahead of any other validation of the request.

Then how about we send non-privilege requests to all possible method, then gather ones that return any other error, that is not Access Denied? This would imply the policies accept non-privileged requests, which could lead to violations.

Dan the D-Bus Analyzer

We developed Dan for searching that kind of possible violation cases. Dan automatically evaluates privilege verification of D-Bus services. It spawns a test process on a remote device, then recursively scans the D-Bus structure. It then tries to read every property of every object, also calling every method of every interface.

After round of analysis, Dan writes three files.

• D-Bus structure flattened into JSON file

• Properties log file

• Method log file

Detail of works of Dan skip in this post.

Privilege Violations

We ran our Dan with the target device, Samsung Gear Sport. We took a result of analysis below.

• Total 269 bus names

• Readable Properties: 130,634

• Callable Methods: 2,319 (excluded default interface)

But, we do have some false positives, because of the third check we talked about. The log shows some services check Cynara, and we can see Cynara check FAIL. But the method call itself does not return D-Bus error. So, Dan categorized them “callable”. At this point, we started to manually examine each method.

We discovered many system services that allow privilege violations. A malware without any privilege, could take over Wi-Fi, Bluetooth, Screen, Notification, Email and so many more.

D-Bus API for WPA Supplications

First, we found the D-Bus API for WPA supplicant was fully exposed. This is free software implementation of 802.11i, which can be easily found on Linux. Tizen builds its own APIs and daemons on top. We found every method is callable, and every property is readable. That includes: CreateInterface, RemoveInterface, Scan and GetPin.

This exposure violates Tizen’s network-related privileges, but also, location-related private ones too.  Even though location privilege isn’t granted we can tracking the device by taking over Wi-Fi.

We aquire the BSSID of the first known Wi-Fi network and the signal value. Using Google’s Geolocation API, we can have GPS coordinates of device

Bluetooth 

projectx.bt and core are two Tizen’s own services for controlling Bluetooth. These service partially expose methods where a malware can silently accept incoming Bluetooth pair request, or silently force Bluetooth discovery mode or prompt pairing request.

Besides projectx, there is another daemon for Bluetooth, BlueZ. BlueZ is the underlying Bluetooth stack for Linux, and we found that its APIs are partially exposed as well. A malware can silently force devices to disconnect, gather information and so on.

There’s a bonus though, and that’s hcidump. We found on some devices there is no restriction on hcidump utility. What that means is that any malware can simply dump the incoming/outgoing Bluetooth packets, with no superuser privilege.

By combining the two, a malware can hijacking link key.

1. Start dumping HCI packets

2. Force the paired device to disconnect

3. Automatically reconnect with a new link key

4. Extract link key from the dump

These problems violate Tizen’s Bluetooth-related privilege.

Notification 

Third service is notification service. The service doesn’t only manage notification data, but also can do stuff on behalf of user’s tap on screen. This service is also partially exposed.

As a result, a malware can remove all the notification, launch an application on the phone, read all the incoming messages, internal data, and much more.

In this case, privilege like notification and push are violated, but three is no privilege assigned to this kind of invasive behavior, so no application should be able to do this.

E-mail

Just like the notification, it also lets anyone do stuff. A malware can launch the email app on the smartphone, modify email messages, send any arbitrary email using the user’s email address. Messaging and email-related private privilege are violated

But the most problematic thing is how this service handles “private” methods. Actually, sending an email request does get rejected, but how?

We have the code of email service. First, we have string “wemail-private-send-mail-noti.” Then it does string compare, and nothing more. There is no proper privilege check in place, and the only one string check.

Conclusion

In this post we discussed the Tizen’s security internals. Around the ojects and the privileges, we focused on where they are validated. We talked about the three checkpoints: the client process, the Cynara-aware D-Bus daemon, and the service process.

We use our own tools called Dan and disclosed the privilege violations that impact many system services of the smartwatch.

Remaining Goals

We have several remaining goals for expand our research

• Applied to other Tizen system (Smart TV, Refrigerators, etc.)

• Applied to other D-Bus system like Linux

• Applied to highest version of new Tizen

Please contact author if you have any questions.
dlwjdgh100@o365.skku.edu

We are looking for students who are interested in security.

If you want join us please contact us.

- Tel. 031-290-7981

- Email. ejin@o365.skku.edu

2 THOUGHTS ON “WEARABLE OS VULNERABILITIES”

• Pianino TBF Kalisz

  1. • 2021/02/06 AT 9:50 AM

     • Straightforward and written well, thanks for the information

• Naprawa Pianin

  1. • 2021/02/07 AT 8:10 PM

     • Keep working, nice post! Just the info I had to know.