Vulnerabilities > CVE-2017-0563 - Insufficient Verification of Data Authenticity vulnerability in Linux Kernel 3.10

047910
CVSS 9.3 - CRITICAL
Attack vector
NETWORK
Attack complexity
MEDIUM
Privileges required
NONE
Confidentiality impact
COMPLETE
Integrity impact
COMPLETE
Availability impact
COMPLETE
network
linux
CWE-345
critical

Summary

An elevation of privilege vulnerability in the HTC touchscreen driver could enable a local malicious application to execute arbitrary code within the context of the kernel. This issue is rated as Critical due to the possibility of a local permanent device compromise, which may require reflashing the operating system to repair the device. Product: Android. Versions: Kernel-3.10. Android ID: A-32089409.

Vulnerable Configurations

Part Description Count
OS
Linux
1

Common Attack Pattern Enumeration and Classification (CAPEC)

  • JSON Hijacking (aka JavaScript Hijacking)
    An attacker targets a system that uses JavaScript Object Notation (JSON) as a transport mechanism between the client and the server (common in Web 2.0 systems using AJAX) to steal possibly confidential information transmitted from the server back to the client inside the JSON object by taking advantage of the loophole in the browser's Same Origin Policy that does not prohibit JavaScript from one website to be included and executed in the context of another website. An attacker gets the victim to visit his or her malicious page that contains a script tag whose source points to the vulnerable system with a URL that requests a response from the server containing a JSON object with possibly confidential information. The malicious page also contains malicious code to capture the JSON object returned by the server before any other processing on it can take place, typically by overriding the JavaScript function used to create new objects. This hook allows the malicious code to get access to the creation of each object and transmit the possibly sensitive contents of the captured JSON object to the attackers' server. There is nothing in the browser's security model to prevent the attackers' malicious JavaScript code (originating from attacker's domain) to set up an environment (as described above) to intercept a JSON object response (coming from the vulnerable target system's domain), read its contents and transmit to the attackers' controlled site. The same origin policy protects the domain object model (DOM), but not the JSON.
  • Cache Poisoning
    An attacker exploits the functionality of cache technologies to cause specific data to be cached that aids the attackers' objectives. This describes any attack whereby an attacker places incorrect or harmful material in cache. The targeted cache can be an application's cache (e.g. a web browser cache) or a public cache (e.g. a DNS or ARP cache). Until the cache is refreshed, most applications or clients will treat the corrupted cache value as valid. This can lead to a wide range of exploits including redirecting web browsers towards sites that install malware and repeatedly incorrect calculations based on the incorrect value.
  • DNS Cache Poisoning
    A domain name server translates a domain name (such as www.example.com) into an IP address that Internet hosts use to contact Internet resources. An attacker modifies a public DNS cache to cause certain names to resolve to incorrect addresses that the attacker specifies. The result is that client applications that rely upon the targeted cache for domain name resolution will be directed not to the actual address of the specified domain name but to some other address. Attackers can use this to herd clients to sites that install malware on the victim's computer or to masquerade as part of a Pharming attack.
  • Cross-Site Scripting Using MIME Type Mismatch
    An attacker creates a file with scripting content but where the specified MIME type of the file is such that scripting is not expected. Some browsers will detect that the specified MIME type of the file does not match the actual type of the content and will automatically switch to using an interpreter for the real content type. If the browser does not invoke script filters before doing this, the attackers' script may run on the target unsanitized. For example, the MIME type text/plain may be used where the actual content is text/javascript or text/html. Since text does not contain scripting instructions, the stated MIME type would indicate that filtering is unnecessary. However, if the target application subsequently determines the file's real type and invokes the appropriate interpreter, scripted content could be invoked. In another example, img tags in HTML content could reference a renderable type file instead of an expected image file. The file extension and MIME type can describe an image file, but the file content can be text/javascript or text/html resulting in script execution. If the browser assumes all references in img tags are images, and therefore do not need to be filtered for scripts, this would bypass content filters. In a cross-site scripting attack, the attacker tricks the victim into accessing a URL that uploads a script file with an incorrectly specified MIME type. If the victim's browser switches to the appropriate interpreter without filtering, the attack will execute as a standard XSS attack, possibly revealing the victim's cookies or executing arbitrary script in their browser.
  • Spoofing of UDDI/ebXML Messages
    An attacker spoofs a UDDI, ebXML, or similar message in order to impersonate a service provider in an e-business transaction. UDDI, ebXML, and similar standards are used to identify businesses in e-business transactions. Among other things, they identify a particular participant, WSDL information for SOAP transactions, and supported communication protocols, including security protocols. By spoofing one of these messages an attacker could impersonate a legitimate business in a transaction or could manipulate the protocols used between a client and business. This could result in disclosure of sensitive information, loss of message integrity, or even financial fraud.

Seebug

  • bulletinFamilyexploit
    description#### Product * Google Nexus 9 #### Vulnerable Version * Nexus 9 Android Builds before N4F27B - May 2017, i.e. before bootloader 3.50.0.0143. #### Mitigation * Install N4F27B or later (bootloader version 3.50.0.0143). #### Technical Details The Nexus 9 device contains a sensor SoC manufactured by Cypress. The sensor is managed by a driver available under drivers/input/touchscreen/cy8c_sar.c. The driver uses the sensor’s data in order to regulate the radiation level emitted by the device. The sensor communicates with the application processor via I2C bus #1, which also provides a firmware update interface. During the platform boot, the driver samples the SoC’s firmware’s version via chip address 0x5{c,d}, register 0x6. If it is different than the one available under /vendor/firmware/sar{0,1}.img, it initiates with a firmware flashing process (via I2C chip address 0x6{0,1}). It seems though that the firmware is not signed by Cypress, thus anyone having access to the I2C bus, can reflash the firmware of the SoC. On Nexus 9 before build N4F27B, the I2C bus could be accessed in four ways: * Directly by the kernel. * Via the /dev/i2c-N character devices. However, as per the SElinux policy in Nexus 9, these devices have the i2c_device context which can only be accessed when one is under the su domain – only available on eng/userdebug builds, i.e. not on production. * Via the USB fastboot interface, accessible by the ```fastboot oem {i2cr, i2cw, i2crNoAddr, i2cwNoAddr}```commands: ``` $ fastboot oem i2cr 1 0xb8 6 1 ... (bootloader) ret:0 (bootloader) > [1] = 1f 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 OKAY [ 0.012s] finished. total time: 0.013s ``` * Via the HBOOT interface, available by UART (exposed by the headphones jack). The I2C buses could be accessed by the i2cr, i2cw, i2crNoAddr, i2cwNoAddr commands: ``` hboot> i2cr 1 0xb8 6 1 ret:0 > [1] = 1f 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 hboot> ``` Vectors 3 & 4 are especially significant because theoretically they can be used by either a physical attacker (rebooting the device into fastboot) or by malicious chargers / headphones. For example, a malicious charger connected to an ADB-enabled device may reboot the device into fastboot if the user authorizes the charger. As for headphones, on builds before N4F26T they could reboot the device into HBOOT by issuing reboot oem-42 on the FIQ debugger prompt. See our blog post for more details. #### Proof-of-Concept To demonstrate the SoC can be attacked via I2C, we modified its firmware image. Then we managed to flash the modified image via the I2C bus by the second vector using i2ctools (i.e. the test device ran our own AOSP-compiled, non-production build). The first firmware image we flashed, available on GitHub increases the version to 0x3f: ``` flounder:/ # /data/local/tmp/i2cget -f -y 1 0x5c 0x6 /data/local/tmp/i2cget -f -y 1 0x5c 0x6 0x3f flounder:/ # ``` The second broke the operation of the chip – from that point forward, we could not reflash the chip since it stopped responding via I2C: ``` [ 21.431832] CYPRESS_SAR: probe of 1-005d failed with error -1 [ 61.118692] [SAR] active=80 ``` As for the 3rd and 4th vectors, HBOOT limits the number of command arguments to 16 which creates a technical difficulty controlling the last bytes of each firmware image line (which also contains the checksum) during the flashing process, however further research may show it can be bypassed as well. #### Patch Google patched the vulnerability on build N4F27B / bootloader 3.50.0.0143 by restricting access to the I2C buses – removing vectors 3 and 4. The I2C related bootloader commands are no longer available: ``` $ fastboot oem i2cr 1 0xb8 6 1 ... (bootloader) [ERR] Command error !!! OKAY [ 0.011s] finished. total time: 0.012s ``` Please note that although Google published the advisory on the April Security Bulletin, the patch has been included only since the April 5 2017 Security Patch Level, where the April Nexus 9 image (N4F26X) has the April 1 2017 Security Patch Level, hence it does not contain the patched bootloader. #### Timeline * 03-May-17: Public disclosure. * 01-May-17: Patch available. * 03-Apr-17: Vendor advisory available. * 01-Mar-17: Added as ALEPH-2017009. * 21-Dec-16: Vulnerability triaged by vendor (Critical). * 09-Oct-16: Reported.
    idSSV:93104
    last seen2017-11-19
    modified2017-05-12
    published2017-05-12
    reporterRoot
    titleGoogle Nexus 9 Cypress SAR Firmware Injection via I2C(CVE-2017-0563)
  • bulletinFamilyexploit
    description# Nexus 9 vs. Malicious Headphones, Take Two # In March 2017 we [disclosed](https://alephsecurity.com/2017/03/08/nexus9-fiq-debugger/) `CVE-2017-051`0, a critical vulnerability in Nexus 9, that allowed for quite unique an attack by malicious headphones. Interestingly, its patch was insufficient. We had responsibly reported that finding (`CVE-2017-0648`) to Google, which patched it in the J[une 2017 Android Security Bulletin](https://source.android.com/security/bulletin/2017-06-01#kernel-components). In this blog post we will begin with a short recap of `CVE-2017-0510`, analyze why its original patch is insufficient (`CVE-2017-0648`), and demonstrate a sample attack against it. We will end by presenting `CVE-2017-0648`’s patch, which seems to completely block the attack. ## Recap of CVE-2017-0510 ## It’s a common practice in Google Nexus / Pixel devices that when the voltage on the `MIC` pin of the TRRS connector exceeds some threshold, the headphone jack turns into a UART debug interface ([see our survey](https://alephsecurity.com/2017/03/08/nexus9-fiq-debugger#a-new-survey)). Here is a sample cable we assembled using the standard [FTDI232RL breakout board](https://www.sparkfun.com/products/12731): ![](https://images.seebug.org/1497415199035-w331s) The vulnerability in Nexus 9 was that the debug interface also gave access to a capable FIQ debugger: <hit enter to activate fiq debugger> debug> help FIQ Debugger commands: pc PC status regs Register dump allregs Extended Register dump bt Stack trace reboot [<c>] Reboot with command <c> reset [<c>] Hard reset with command <c> irqs Interupt status kmsg Kernel log version Kernel version sleep Allow sleep while in FIQ nosleep Disable sleep while in FIQ console Switch terminal to console cpu Current CPU cpu <number> Switch to CPU<number> ps Process list sysrq sysrq options sysrq <param> Execute sysrq with <param> That had interesting consequences, such as: 1. [Preemption of arbitrary processes](https://alephsecurity.com/2017/03/08/nexus9-fiq-debugger#fiq-debugger), allowing for leakage of user data. 1. [Leakage of Stack Canaries](https://alephsecurity.com/2017/03/08/nexus9-fiq-debugger#listening-to-your-stack-canaries) 1. [Derandomization of ASLR](https://alephsecurity.com/2017/03/08/nexus9-fiq-debugger#aslr) 1. [Access to SysRq](https://alephsecurity.com/2017/03/08/nexus9-fiq-debugger#sysrq) 1. [Rebooting into HBOOT (HTC’s Android Bootloader)](https://alephsecurity.com/2017/03/08/nexus9-fiq-debugger#42-answer-to-the-ultimate-question-of-life-the-universe-and-everything) by issuing `reboot oem-42`, which also enabled attacks against internal SoCs (further patched in the [May 2017 update](https://source.android.com/security/bulletin/2017-05-01) – `CVE-2017-0563` & `CVE-2017-0582`) 1. [Factory Resets](https://alephsecurity.com/2017/03/08/nexus9-fiq-debugger#factory-reset), by issuing `reboot oem-76`. ## CVE-2017-0510’s Attempted Patch ## Google has tried to patch `CVE-2017-0510` by reducing the capabilities of the `FIQ Debugger`. In recent builds since the patch, when the platform is fully loaded, it is no longer possible to dump the registers nor reboot with an `oem-N` parameter (preventing reboots into `HBOOT` and Factory Resets): debug> help FIQ Debugger commands: reboot Reboot reset Hard reset irqs Interrupt status sleep Allow sleep while in FIQ nosleep Disable sleep while in FIQ console Switch terminal to console ps Process list debug> The relevant commit in the tegra kernel tree is [a075f8ab69f6](https://android.googlesource.com/kernel/tegra/+/a075f8ab69f679f221f9e2001363aae83cbdd2e8). Analyzing the patch shows that the critical FIQ debugger commands are now governed by the `sysrq_on()` function. For example, let’s examine `fiq_debugger_fiq_exec` under [fiq_debugger.c](https://android.googlesource.com/kernel/tegra/+/a075f8ab69f679f221f9e2001363aae83cbdd2e8/drivers/staging/android/fiq_debugger/fiq_debugger.c): static bool fiq_debugger_fiq_exec(struct fiq_debugger_state *state, const char *cmd, const struct pt_regs *regs, void *svc_sp) { [...] } else if (!strcmp(cmd, "pc")) { if (sysrq_on()) fiq_debugger_dump_pc(&state->output, regs); } else if (!strcmp(cmd, "regs")) { if (sysrq_on()) fiq_debugger_dump_regs(&state->output, regs); } else if (!strcmp(cmd, "allregs")) { if (sysrq_on()) fiq_debugger_dump_allregs(&state->output, regs); } else if (!strcmp(cmd, "bt")) { if (sysrq_on()) fiq_debugger_dump_stacktrace(&state->output, regs, 100, svc_sp); [...] } `sysrq_on` is implemented under [drivers/tty/sysrq.c](https://android.googlesource.com/kernel/tegra/+/a075f8ab69f679f221f9e2001363aae83cbdd2e8/drivers/tty/sysrq.c) as follows: bool sysrq_on(void) { return sysrq_enabled || sysrq_always_enabled; } Since the value of `sysrq_always_enabled` is 0, we can conclude that the effectiveness of this patch solely depends on the value of `sysrq_enabled`. ## Ephemeral Access to Unrestricted FIQ Debugger and SysRq (CVE-2017-0648) ## Unfortunately, as explained in the [previous blog post](https://alephsecurity.com/2017/03/08/nexus9-fiq-debugger/), the default value of `sysrq_enabled` was 1: static int __read_mostly sysrq_enabled = SYSRQ_DEFAULT_ENABLE; where under [include/linux/sysrq.h](https://android.googlesource.com/kernel/tegra/+/a075f8ab69f679f221f9e2001363aae83cbdd2e8/include/linux/sysrq.h): /* Enable/disable SYSRQ support by default (0==no, 1==yes). */ #define SYSRQ_DEFAULT_ENABLE 1 Now, during the platform boot-up, an [`init` script](https://android.googlesource.com/platform/system/core/+/android-7.1.2_r17/rootdir/init.rc) writes 0 to `/proc/sys/kernel/sysrq`: [...] on early-init # Set init and its forked children's oom_adj. write /proc/1/oom_score_adj -1000 # Disable sysrq from keyboard write /proc/sys/kernel/sysrq 0 [...] The `/proc/sys/kernel/sysrq` proc file is backed by code under kernel/sysctl.c that eventually toggles `sysrq_enabled`. Therefore, despite `CVE-2017-0510`’s patch, there was a very short window of time (a few milliseconds) during boot, until the `init` script was executed, that one could still access the unrestricted FIQ debugger (and also [SysRq commands](https://alephsecurity.com/2017/03/08/nexus9-fiq-debugger/#sysrq)). Since the attacker could force a reboot even from the limited FIQ debugger, he could access the unrestricted FIQ even if the victim inserted the malicious cable after the platform had been fully loaded: Ephemeral Access to Unrestricted FIQ and SysRq (CVE-2017-0648) ============================================================= .------. (1) .------------------. .--> | BOOT | -------> | Unrestricted FIQ | --. | `------' `---------.--------' | (4) .-------. | | |---> | HBOOT | | (3) .-------------. (2) | | `-------' `--------- | Limited FIQ | <-----' | `-------------' | (5) .---------------. `---> | Factory Reset | `---------------' Transitions: (1) sysrq_enabled = SYSRQ_DEFAULT_ENABLE = 1 (2) init: write 0 /proc/sys/kernel/sysrq 0 => sysrq_enabled = 0 (3) attacker @ limited FIQ: 'reboot' (4) attacker @ unrestricted FIQ: 'reboot oem-42' (5) attacker @ unrestricted FIQ: 'reboot oem-76' It should be noted that the recovery init.rc script does not disable sysrq at all, which allowed for **non-ephemeral** unrestricted FIQ access while the device was in the recovery mode. (It also mitigated by the new patch.) ## Proof-of-Concept ## The following demonstrates how we preempt an arbitrary process, and also get into the HBOOT mode, bypassing `CVE-2017-0510`’s patch. We assume the attack begins when the platform is fully-loaded. We force a (normal) reboot, and then get an early and temporary access to the FIQ debugger, during which we issue the capable-FIQ bt command. Afterwards we reboot into the HBOOT mode by issuing `reboot oem-42`: debug> help FIQ Debugger commands: reboot Reboot reset Hard reset irqs Interrupt status sleep Allow sleep while in FIQ nosleep Disable sleep while in FIQ console Switch terminal to console ps Process list debug> bt debug> reboot debug> [0000.045] Battery Present [0000.069] Battery Voltage: 3743 mV [0000.072] Battery charge sufficient [0000.076] Override BCT configs [0000.078] NvBootEmcReadMrr+++ [...] [hboot query] query 24 is not implemented Platform Pre OS Boot configuration... [INFO] booting linux @ 0x80080000, tags @ 0x83a80000, ramdisk @ 0x82a80000, machine type: -1 [...] <hit enter to activate fiq debugger> debug> help FIQ Debugger commands: pc PC status regs Register dump allregs Extended Register dump bt Stack trace reboot [<c>] Reboot with command <c> reset [<c>] Hard reset with command <c> irqs Interupt status kmsg Kernel log version Kernel version sleep Allow sleep while in FIQ nosleep Disable sleep while in FIQ console Switch terminal to console cpu Current CPU cpu <number> Switch to CPU<number> ps Process list sysrq sysrq options sysrq <param> Execute sysrq with <param> [...] debug> bt pid: 89 comm: kworker/u4:1 x0 0000000000002ee0 x1 0000000000002d09 x2 000000000859c84a x3 ffffffc002968c00 x4 0000000000defde8 x5 ffffffc000f56aa8 x6 ffffffc0029c8400 x7 ffffffc0029c8800 x8 ffffffc002935130 x9 0000000010624dd3 x10 000000000001a1b6 x11 0000000000000066 x12 000000000000006f x13 0000000000000075 x14 000000000000006e x15 0000000000000064 x16 000000000000000a x17 0000000000000004 [...] debug> reboot oem-42 [...] ###[ Bootloader Mode ]### [...] hboot> ? #. <command> : <brief description> security_command: 1. boot : no desc. [...] 14. readconfig : no desc. 15. readimei : no desc. 16. readmeid : no desc. 17. readpid : no desc. 18. rebootRUU : no desc. 19. refurbish : no desc. 20. reset : no desc. [...] hboot> ## CVE-2017-0648’s Patch ## Google has patched the vulnerability by commit [34597d088801](https://android.googlesource.com/kernel/tegra/+/34597d088801ad8060b45026df2435f52136032f) (available in the [N9F27C June 2017 build](https://developers.google.com/android/images#volantis). The value of `SYSRQ_DEFAULT_ENABLE` is now 0, preventing the temporary access to the unrestricted FIQ debugger and `SysRq` interface: diff --git a/include/linux/sysrq.h b/include/linux/sysrq.h index 5a0bd93..d393eeb 100644 --- a/include/linux/sysrq.h +++ b/include/linux/sysrq.h @@ -18,7 +18,7 @@ #include <linux/types.h> /* Enable/disable SYSRQ support by default (0==no, 1==yes). */ -#define SYSRQ_DEFAULT_ENABLE 1 +#define SYSRQ_DEFAULT_ENABLE 0 /* Possible values of bitmask for enabling sysrq functions */ /* 0x0001 is reserved for enable everything *
    idSSV:93197
    last seen2017-11-19
    modified2017-06-14
    published2017-06-14
    reporterRoot
    titleNexus 9 vs. Malicious Headphones, Take Two