CyRC analysis: CVE-2020-7958 biometric data extraction in Android devices

On a non-rooted device, you would only be able to access the biometric authentication APIs exposed by the Android framework:

However, on a rooted device, you can start your attack from anywhere in the REE:

You could go ahead and invoke any functionality already present in libgf_ud_hal library. Our reverse engineering efforts discovered that REE fingerprint libraries contain many more features beyond what is needed to support the high-level Android framework APIs. This is a standard practice, as in most cases removing this functionality does not make any difference and the overhead of ring-fencing production code in these libraries carries no additional benefit.

Alternatively, you could invoke the raw transport that sets up a shared memory buffer and passes your input to the TEE. This function typically lives in libQSEEComAPI or the TEE-specific equivalent in the case of other TEEs.

The difference is that in the former case, the functions in libgf_ud_hal library will have filled out the buffer with a proprietary structure specific to the command you want to invoke, and it would have made the call to the raw transport. In the latter case, you need to know what to put in that buffer and how to structure it so that the TEE routes it correctly and the trustlet can understand it.

From here, the buffer traverses through a long chain of calls in the Android OS kernel, the Secure Monitor in EL3, the TEE OS in S-EL1, and ultimately lands in the trustlet in S-EL0.

Once this buffer reaches the trustlet, it lands in a “routing” function (the command handler). This function examines the first few bytes of the buffer to find out what functionality of the trustlet needs to be executed. This is where things start to get very interesting.

The libgf_ud_hal.so shared object contains a method called goodix::SZCustomizedProductTest::factoryCaptureImage(). Our reverse engineering efforts have resulted in the following deconstructed pseudocode*:

* Note that we spent the bulk of our reverse engineering effort turning meaningless v1, v2, and v3+X’s into readable code. This is true for all code samples in this post.

__int64 __fastcall goodix::SZCustomizedProductTest::factoryCaptureImage(goodix::SZCustomizedProductTest *this, GF_SZ_TEST_RAWDATA *raw_data_out, unsigned __int16 ae_expo_start_time, unsigned __int8 uchar, unsigned __int16 ushort2)

{

  goodix::command::FactoryCaptureImage *Command; // x0 MAPDST

  unsigned int rv; // w21

  const char *errfmt; // x0

  if ( raw_data_out )

  {

    Command = malloc(0x1502Cu);

    if ( Command )

    {

      memset(Command, 0, sizeof(goodix::command::FactoryCaptureImage));

      Command->ae_expo_start_time = ae_expo_start_time;

      Command->field_1C = uchar;

      Command->field_1E = ushort2;

      Command->Parent.target = 1003;

      Command->Parent.cmd_id = 17;

      rv = goodix::HalBase::invokeCommand(&this->HalBase, &Command->Parent, 0x1502C);

      if ( !rv )

      {

        memcpy(raw_data_out, &Command->captureImageResponseBuffer, sizeof(GF_SZ_TEST_RAWDATA));

        free(Command);

        return rv;

      }

      free(Command);

    }

    else

    {

      __android_log_print(6, "[GF_HAL][SZCustomizedProductTest]", "[%s] out of memory, cmd", "factoryCaptureImage");

      rv = 1001;

    }

  }

  else

  {

    __android_log_print(6, "[GF_HAL][SZCustomizedProductTest]", "[%s] param is erro", "factoryCaptureImage");

    rv = 1004;

  }

  errfmt = gf_strerror(rv);

  __android_log_print(

    6,

    "[GF_HAL][SZCustomizedProductTest]",

    "[%s] exit. err=%s, errno=%d",

    "factoryCaptureImage",

    errfmt,

    rv);

  return rv;

}

This function accepts a buffer (raw_data_out), which will receive the image from the fingerprint sensor. This buffer should be at least 86024 bytes in size to accommodate the output image—the size of GF_SZ_TEST_RAWDATA structure, which we reverse engineered on the trustlet side.

Other arguments, such as exposure time (ae_expo_start_time), are passed to this function and are included in the resulting TEE command.

The TEE command is a structure that differs per command but, importantly, contains the following routing information:

1. Target ID (target), which is set to 1003. The trustlet will use this to route the command to the correct module that handles commands with this target ID.
2. Command ID (cmd_id), which is 17. This parameter routes the command to a specific branch in the module inside the trustlet.

Note that at this point, we are not talking to the TEE yet. We are a couple of layers of abstraction away, and we are talking in fingerprint sensor concepts. We suspect that this library may be part of an SDK provided by the sensor vendor and that device vendors, such as OnePlus, apply minimal changes and reconfigurations specific to the hardware sensor that they are using.

Once the command structure is prepared, the goodix::HalBase::invokeCommand() function is used to communicate with a Qualcomm-supplied TEE communication library, libQSEEComAPI.so.

This library will vary per TEE vendor. At this point, the fingerprint sensor command built earlier is basically just an abstract buffer with some data. This library talks to the kernel driver for TEE communication and passes this buffer to the correct trustlet. If we didn’t have goodix::factoryCaptureImage to prepare the command structure for us, we could still build an appropriate one by reversing the trustlet and call libQSEEComAPI.so directly to deliver our command to the trustlet.

In this case, we do have a high-level function to call. Because we did not fully understand how all parameters to this call affected the result, we started with a simple call as our goal:

goodix::SZCustomizedProductTest::factoryCaptureImage(SZCustomizedProductTest _object, image_buffer , ae_expo_start_time, 1, 0);

This call required us to have a reference to a SZCustomizedProductTest instance as well as ae_expo_start_time.

The latter could be retrieved by calling goodix::SZCustomizedProductTest::getSensorInfo, which would mimic the behavior of a real call found in the library.

Creating an instance of SZCustomizedProductTest required a valid reference to a HalContext instance.

Luckily for us, goodix::HalBase::invokeCommand() was something that would frequently get called during normal operation of the fingerprint sensor, and the instance of goodix::HalBase included a valid pointer to HalContext that we could borrow. The logic of our exploit, therefore, became the following:

1. Hook goodix::HalBase::invokeCommand and retrieve a pointer to HalContext.
2. At some point after such a pointer is retrieved, call goodix::createProductTest with a pointer to HalContext.
3. Call any further product test initialization routines with valid arguments, such as goodix::SZCustomizedProductTest::getSensorInfo.
4. Call goodix::factoryCaptureImage with all the appropriate parameters and dump the output buffer to disk for further examination.

We achieved all the above on a rooted device. Tools like Frida can help make dynamic trustlet exploitation practical.

Logic in the trustlet

In this part, we explain why our simple exploit worked and how it was fixed.

In the OnePlus 7 Pro’s fingerprint authentication trustlet, we identified the following routing functions by looking at the error handlers and exported symbols:

app_main.tz_app_cmd_handler -> gf_modules.gf_modules_cmd_entry_point

This is where a list of “modules” is iterated, and for each module, a check is performed to see if the module metadata entry has a “target id” that matches the “target id” of the command being handled. If it does, the module’s entry point address is read from the metadata structure and called, so that it can continue handling the command:

__int64 __fastcall gf_modules_cmd_entry_point(cmd_routing_info *cmd_routing_info, unsigned int buffer_size)

{

  // ...

  loop_idx_stopgap = -1LL;

  for ( module_table_entry = g_module_table;

        (*module_table_entry)->target_id != cmd_routing_info->target_id;

        ++module_table_entry )

  {

    if ( ++loop_idx_stopgap > 2 )

      return 0;

  }

  errno = ((*module_table_entry)->entry)(cmd_routing_info, buffer_size);

  *cmd_routing_info[1].gap0 = errno;

  strerr = gf_strerror(errno);

  gf_dump_log(3LL, "[gf_modules][%s] err = %d, errno = %s", "cmd_entry_point", errno, strerr);

  // ...

  return errno;

}

We discovered a symbol called g_dump_module in the trustlet:

This symbol actually points at a module with functionality to dump the image from the sensor into the REE. But this module is not present in the table that gf_modules_cmd_entry_point uses:

This is good: The image dumping component is excluded from the command routing logic.

However, there was another interesting module here: the g_product_test_module. It is not unusual for testing code to have functionality that could be useful to us. Searching the strings in this binary for anything to do with image dumping revealed the following interesting function name: sz_factory_test_capture_image.

A graph of cross-references to this showed that it was somehow related to the product testing module: