CVE Vulnerabilities

CVE-2018-14980

Incorrect Permission Assignment for Critical Resource

Published: Apr 25, 2019 | Modified: Oct 03, 2019
CVSS 3.x
7.1
HIGH
Source:
NVD
CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
CVSS 2.x
3.6 LOW
AV:L/AC:L/Au:N/C:P/I:P/A:N
RedHat/V2
RedHat/V3
Ubuntu

The ASUS ZenFone 3 Max Android device with a build fingerprint of asus/US_Phone/ASUS_X008_1:7.0/NRD90M/US_Phone-14.14.1711.92-20171208:user/release-keys contains the android framework (i.e., system_server) with a package name of android (versionCode=24, versionName=7.0) that has been modified by ASUS or another entity in the supply chain. The system_server process in the core android package has an exported broadcast receiver that allows any app co-located on the device to programmatically initiate the taking of a screenshot and have the resulting screenshot be written to external storage (i.e., sdcard). The taking of a screenshot is not transparent to the user; the device has a screen animation as the screenshot is taken and there is a notification indicating that a screenshot occurred. If the attacking app also requests the EXPAND_STATUS_BAR permission, it can wake the device up using certain techniques and expand the status bar to take a screenshot of the users notifications even if the device has an active screen lock. The notifications may contain sensitive data such as text messages used in two-factor authentication. The system_server process that provides this capability cannot be disabled, as it is part of the Android framework. The notification can be removed by a local Denial of Service (DoS) attack to reboot the device.

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
Zenfone_3_max_firmware Asus - (including) - (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