close

Samsung Mobile Security
Cookie Policy

Updated on Jan 17, 2022

This Cookie Policy describes the different types of cookies that may be used in connection with Samsung Mobile Security website which is owned and controlled by Samsung Electronics Co., Ltd (“Samsung Electronics”). This Cookie Policy also describes how you can manage cookies.

It’s important that you check back often for updates to the Policy as we may change it from time to time to reflect changes to our use of cookies. Please check the date at the top of this page to see when this Policy was last revised. Any changes to this Policy will become effective when we make the revised Policy available on our website.

Samsung Electronics has offices across Europe, so we can ensure that your request or query will be handled by the data protection team based in your region. If you have any questions, the easiest way to contact us is through our Privacy Support Page at https://www.samsung.com/request-desk.

You can also contact us at:

European Data Protection Officer
Samsung Electronics (UK) Limited
Samsung House, 2000 Hillswood Drive, Chertsey, Surrey KT16 0RS

Cookies

Cookies are small files that store information on your computer, TV, mobile phone, or other device. They enable the entity that put the cookie on your device to recognize you across different websites, services, devices, and/or browsing sessions.

We use the following types of cookies on this website:

Essential Cookies: enable you to receive the services you request via our website. Without these cookies, services that you have asked for cannot be provided. For example, these enable to identify users and provide proper service for each user. These cookies are automatically enabled and cannot be turned off because they are essential to enable you to browse our website. Without these cookies this Samsung Mobile Security website could not be provided.

Cookie Domain Purpose
JSESSIONID security.samsungmobile.com to keep login session
lastActivityTime security.samsungmobile.com to save the user's last activity time to automatically logout after 30 minutes of inactivity

Managing Cookies and Other Technologies

You can also update your browser settings at any time, if you want to remove or block cookies from your device (consult your browser's "help" menu to learn how to remove or block cookies). Samsung Electronics is not responsible for your browser settings. You can find good and simple instructions on how to manage cookies on the different types of web browsers at http://www.allaboutcookies.org.

Go straight to the menu Go straight to the text

Security Reporting

Sample of High-Quality Report

The following write-up is a redacted sample of a previously reported security vulnerability report with a high severity security impact. You may refer to this sample as a template and guidance when reporting the security vulnerability you have identified.

Title

Stack-based buffer overflow in the trusted storage Trusted Application (TA).

Issue

A possible invalid bounds check vulnerability in trusted storage TA allows stack-based buffer overflow and arbitrary code execution.

Issue details

There is a stack-based buffer overflow in the Trusted storage TA (TRUSTED_STORAGE_TA_FILE_NAME-XXXXX.ext with sha256 hash e98574f290b281a0f7808409037bf3f8********************************), within the getTlv**** function.

This function takes a parsed TLV structure and generates a new TLV-encoded buffer on the stack based on its contents. The beginning of the function looks as follows:

signed int __fastcall getTlv****(int state, tlv_t *tlvin) { [ ... ] char tlvbuf[1024]; /** 1 **/ char pubkey[512]; tlv_write_t tlvw; state_plus_12 = state + 12; tlvw.tlv = tlvin; tlvw.offset = 0; if ( !find_tag(&tlvw, (int)&tag_0x52, (int)tlvbuf) ) /** 2 **/ { if ( find_tag(&tlvw, (int)&tag_0x71, (int)tlvbuf) ) { v5 = 265; goto LABEL_5;

The tlvbuf is allocated in the stack with a size of 1024 bytes at /** 1 **/. Then it is passed to find_tag to find tags 0x52 and 0x71 at /** 2 **/. The find_tag function does the following:

thetag = find_tag(tlvw->tlv, tag); if ( !thetag ) return -1; v6 = tlv_write(thetag, data, 1024, tlvw->offset); if ( v6 <= 0 ) return -1; tlvw->offset += v6;

The problem appears in tlv_write (offset 0x22C** within the TA binary), where bounds checks are performed:

len = update_and_return_len(obj); if ( len && len <= max_len ) /** 3 **/ { after_tag_offset = write_tag(obj->tag, data, offset) + offset; obj_len_len = write_object_length(obj, data, after_tag_offset); type = (unsigned __int8)obj->num_17_or_18; data_offset = obj_len_len + after_tag_offset; if ( type == 17 ) { [ ... ] } else if ( type == 18 ) { memcpy((char *)(data + data_offset), &obj->num_sub_tlv_or_buffer, obj->obj_len); /** 4 **/ }

At /** 3 **/ the output length is checked against the buffer length. However, at /** 4 **/ the tlv contents are copied to 'data + data_offset' with data_offset potentially out of bounds.

The attached proof-of-concept exploit uses this vulnerability to achieve code execution within the TA. The exploit uses a ROP chain to call Print****** with controlled parameters for demonstration purposes.

Note that the exploit requires system or root privileges.

Affected products

At least the Galaxy S* and Galaxy S* Exynos / Qualcomm versions are affected, with the latest firmware available.

The exploit has been tested on G9**FXXU*****, with security patch level 201*-01-01.

Steps to reproduce

On the host:

$ ndk-build ; adb push libs/armeabi-v7a/attack /data/local/tmp

On the phone, in an adb root shell:

/data/local/tmp # ./attack ; dmesg -c | grep Exploit
****************************************************************
* Tested with G9**FXXU***** firmware on a Galaxy S* phone. *
****************************************************************
[+] Exploit finished. Check the logs.
[ 2132.327013] **** TEE: e01|Exploit successful! Printed from TA.

The last line should contain the output of the TEE log printed by the exploit.

Suggested remediation

Proper bounds checking should be performed. In particular, the tlv_*****() function should take the output offset into account in the bounds check.

Furthermore, the TA should be compiled with stack canaries enabled to prevent trivial exploitation of this type of vulnerability.