CVE Vulnerabilities

CVE-2018-14987

Incorrect Permission Assignment for Critical Resource

Published: Dec 28, 2018 | Modified: Aug 24, 2020
CVSS 3.x
7.1
HIGH
Source:
NVD
CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H
CVSS 2.x
5.6 MEDIUM
AV:L/AC:L/Au:N/C:N/I:P/A:C
RedHat/V2
RedHat/V3
Ubuntu

The MXQ TV Box 4.4.2 Android device with a build fingerprint of MBX/m201_N/m201_N:4.4.2/KOT49H/20160106:user/test-keys contains the Android framework with a package name of android (versionCode=19, versionName=4.4.2-20170213) that dynamically registers a broadcast receiver app component named com.android.server.MasterClearReceiver instead of statically registering it in the AndroidManifest.xml file of the core Android package, as done in Android Open Source Project (AOSP) code for Android 4.4.2. The dynamic-registration of the MasterClearReceiver broadcast receiver app component is not protected with the android.permission.MASTER_CLEAR permission during registration, so any app co-located on the device, even those without any permissions, can programmatically initiate a factory reset of the device. A factory reset will remove all user data and apps from the device. This will result in the loss of any data that have not been backed up or synced externally. The capability to perform a factory reset is not directly available to third-party apps (those that the user installs themselves with the exception of enabled Mobile Device Management (MDM) apps), although this capability can be obtained by leveraging an unprotected app component of core Android process.

Weakness

The product specifies permissions for a security-critical resource in a way that allows that resource to be read or modified by unintended actors.

Affected Software

Name Vendor Start Version End Version
Mxq_tv_box_firmware Mxq_project 4.4.2 (including) 4.4.2 (including)

Potential Mitigations

  • Run the code in a “jail” or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which files can be accessed in a particular directory or which commands can be executed by the software.
  • OS-level examples include the Unix chroot jail, AppArmor, and SELinux. In general, managed code may provide some protection. For example, java.io.FilePermission in the Java SecurityManager allows the software to specify restrictions on file operations.
  • This may not be a feasible solution, and it only limits the impact to the operating system; the rest of the application may still be subject to compromise.
  • Be careful to avoid CWE-243 and other weaknesses related to jails.

References