Vulnerabilities > CVE-2017-7110 - Improper Restriction of Operations within the Bounds of a Memory Buffer vulnerability in Apple Iphone OS, Tvos and Watchos

047910
CVSS 10.0 - CRITICAL
Attack vector
NETWORK
Attack complexity
LOW
Privileges required
NONE
Confidentiality impact
COMPLETE
Integrity impact
COMPLETE
Availability impact
COMPLETE
network
low complexity
apple
CWE-119
critical
nessus

Summary

An issue was discovered in certain Apple products. iOS before 11 is affected. tvOS before 11 is affected. watchOS before 4 is affected. The issue involves the "Wi-Fi" component. It might allow remote attackers to execute arbitrary code in a privileged context or cause a denial of service (memory corruption) via crafted Wi-Fi traffic.

Vulnerable Configurations

Part Description Count
OS
Apple
227

Common Attack Pattern Enumeration and Classification (CAPEC)

  • Buffer Overflow via Environment Variables
    This attack pattern involves causing a buffer overflow through manipulation of environment variables. Once the attacker finds that they can modify an environment variable, they may try to overflow associated buffers. This attack leverages implicit trust often placed in environment variables.
  • Overflow Buffers
    Buffer Overflow attacks target improper or missing bounds checking on buffer operations, typically triggered by input injected by an attacker. As a consequence, an attacker is able to write past the boundaries of allocated buffer regions in memory, causing a program crash or potentially redirection of execution as per the attackers' choice.
  • Client-side Injection-induced Buffer Overflow
    This type of attack exploits a buffer overflow vulnerability in targeted client software through injection of malicious content from a custom-built hostile service.
  • Filter Failure through Buffer Overflow
    In this attack, the idea is to cause an active filter to fail by causing an oversized transaction. An attacker may try to feed overly long input strings to the program in an attempt to overwhelm the filter (by causing a buffer overflow) and hoping that the filter does not fail securely (i.e. the user input is let into the system unfiltered).
  • MIME Conversion
    An attacker exploits a weakness in the MIME conversion routine to cause a buffer overflow and gain control over the mail server machine. The MIME system is designed to allow various different information formats to be interpreted and sent via e-mail. Attack points exist when data are converted to MIME compatible format and back.

Nessus

NASL familyMisc.
NASL idAPPLETV_11.NASL
descriptionAccording to its banner, the version of Apple TV on the remote device is prior to 11. It is, therefore, affected by multiple vulnerabilities as described in the HT208113 security advisory. Note that only 4th generation models are affected by these vulnerabilities.
last seen2020-06-01
modified2020-06-02
plugin id103419
published2017-09-22
reporterThis script is Copyright (C) 2017-2019 and is owned by Tenable, Inc. or an Affiliate thereof.
sourcehttps://www.tenable.com/plugins/nessus/103419
titleApple TV < 11 Multiple Vulnerabilities
code
#
# (C) Tenable Network Security, Inc.
#

include("compat.inc");

if (description)
{
  script_id(103419);
  script_version("1.10");
  script_cvs_date("Date: 2019/11/12");

  script_cve_id(
    "CVE-2017-7080",
    "CVE-2017-7081",
    "CVE-2017-7083",
    "CVE-2017-7086",
    "CVE-2017-7087",
    "CVE-2017-7090",
    "CVE-2017-7091",
    "CVE-2017-7092",
    "CVE-2017-7093",
    "CVE-2017-7094",
    "CVE-2017-7095",
    "CVE-2017-7096",
    "CVE-2017-7098",
    "CVE-2017-7099",
    "CVE-2017-7100",
    "CVE-2017-7102",
    "CVE-2017-7103",
    "CVE-2017-7104",
    "CVE-2017-7105",
    "CVE-2017-7107",
    "CVE-2017-7108",
    "CVE-2017-7109",
    "CVE-2017-7110",
    "CVE-2017-7111",
    "CVE-2017-7112",
    "CVE-2017-7114",
    "CVE-2017-7115",
    "CVE-2017-7116",
    "CVE-2017-7117",
    "CVE-2017-7120",
    "CVE-2017-7127",
    "CVE-2017-7128",
    "CVE-2017-7129",
    "CVE-2017-7130",
    "CVE-2017-11120",
    "CVE-2017-11121"
  );
  script_bugtraq_id(
    100924,
    100927,
    100984,
    100985,
    100986,
    100987,
    100990,
    100992,
    100994,
    100995,
    100998,
    101005,
    101006
  );

  script_name(english:"Apple TV < 11 Multiple Vulnerabilities");
  script_summary(english:"Checks the build number.");

  script_set_attribute(attribute:"synopsis", value:
"The remote Apple TV device is affected by multiple vulnerabilities.");
  script_set_attribute(attribute:"description", value:
"According to its banner, the version of Apple TV on the remote device
is prior to 11. It is, therefore, affected by multiple vulnerabilities
as described in the HT208113 security advisory.

Note that only 4th generation models are affected by these
vulnerabilities.");
  script_set_attribute(attribute:"see_also", value:"https://support.apple.com/en-us/HT208113");
  # https://lists.apple.com/archives/security-announce/2017/Sep/msg00004.html
  script_set_attribute(attribute:"see_also", value:"http://www.nessus.org/u?27cd33f6");
  script_set_attribute(attribute:"solution", value:
"Upgrade to Apple TV version 11 or later. Note that this update is only
available for 4th generation models.");
  script_set_cvss_base_vector("CVSS2#AV:N/AC:L/Au:N/C:C/I:C/A:C");
  script_set_cvss_temporal_vector("CVSS2#E:H/RL:OF/RC:C");
  script_set_cvss3_base_vector("CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H");
  script_set_cvss3_temporal_vector("CVSS:3.0/E:H/RL:O/RC:C");
  script_set_attribute(attribute:"cvss_score_source", value:"CVE-2017-11121");

  script_set_attribute(attribute:"exploitability_ease", value:"Exploits are available");
  script_set_attribute(attribute:"exploit_available", value:"true");
  script_set_attribute(attribute:"exploited_by_malware", value:"true");

  script_set_attribute(attribute:"vuln_publication_date", value:"2017/09/22");
  script_set_attribute(attribute:"patch_publication_date", value:"2017/09/22");
  script_set_attribute(attribute:"plugin_publication_date", value:"2017/09/22");

  script_set_attribute(attribute:"plugin_type", value:"remote");
  script_set_attribute(attribute:"cpe", value:"cpe:/a:apple:apple_tv");
  script_end_attributes();

  script_category(ACT_GATHER_INFO);
  script_family(english:"Misc.");

  script_copyright(english:"This script is Copyright (C) 2017-2019 and is owned by Tenable, Inc. or an Affiliate thereof.");

  script_dependencies("appletv_version.nasl");
  script_require_keys("AppleTV/Version", "AppleTV/Model", "AppleTV/URL", "AppleTV/Port");
  script_require_ports("Services/www", 7000);

  exit(0);
}

include("audit.inc");
include("appletv_func.inc");

url = get_kb_item('AppleTV/URL');
if (empty_or_null(url)) exit(0, 'Cannot determine Apple TV URL.');
port = get_kb_item('AppleTV/Port');
if (empty_or_null(port)) exit(0, 'Cannot determine Apple TV port.');

build = get_kb_item('AppleTV/Version');
if (empty_or_null(build)) audit(AUDIT_UNKNOWN_DEVICE_VER, 'Apple TV');

model = get_kb_item('AppleTV/Model');
if (empty_or_null(model)) exit(0, 'Cannot determine Apple TV model.');

fixed_build = "15J381";
tvos_ver = '11';

# determine gen from the model
gen = APPLETV_MODEL_GEN[model];

appletv_check_version(
  build          : build,
  fix            : fixed_build,
  affected_gen   : 4,
  fix_tvos_ver   : tvos_ver,
  model          : model,
  gen            : gen,
  port           : port,
  url            : url,
  severity       : SECURITY_HOLE
);

Seebug

bulletinFamilyexploit
descriptionBroadcom produces Wi-Fi HardMAC SoCs which are used to handle the PHY and MAC layer processing. These chips are present in both mobile devices and Wi-Fi routers, and are capable of handling many Wi-Fi related events without delegating to the host OS. On iOS, the "AppleBCMWLANBusInterfacePCIe" driver is used in order to handle the PCIe interface and low-level communication protocols with the Wi-Fi SoC (also referred to as "dongle"). Similarly, the "AppleBCMWLANCore" driver handles the high-level protocols and the Wi-Fi configuration. Along with the regular flow of frames transferred between the host and the dongle, the two communicate with one another via a set of "ioctls" which can be issued to read or write dongle configuration from the host. This information is exchanged using the "Control Completion" ring, rather than the regular "RX" ring. When handling certain events such as setting up an access-point, the Wi-Fi chip must be configured to broadcast new information elements for the created network. This is achieved by calling the "setVendorIE" function, which supplies the firmware with a new vendor-specified information element. Before the information element can be added, the driver must first ensure that no previous IE with the same tag and data has already been configured. This is done by querying the Wi-Fi chip for the current list of Vendor IEs. Each IE's tag and contents are compared to the newly provided IE -- if a match is found, the function issues an additional ioctl to the Wi-Fi chip in order to request that the previous IE be deleted. The list of IEs returned by the Wi-Fi firmware starts with a 32-bit "count" field, indicating the number of IEs in the list. Each IE is a TLV, where the "tag" and the "length" are both 8-bits fields. Here is a snippet of the approximate high-level code for "setVendorIE": ``` uint64_t setVendorIE(void* this, void* new_ie) { ... //Extracting some information about the new IE uint8_t* new_ie_buffer = *((uint8_t**)new_ie + 3); uint32_t new_ie_length = *((uint32_t*)new_ie + 4); uint8_t new_ie_tag = new_ie_buffer[0]; ... //Reading the Vendor IE list from the firmware - the IOVar is "vndr_ie" uint8_t* vendor_ie_list = (uint8_t*)IOMalloc(...); uint64_t res = issueCommand(..., &vendor_ie_list, ...); //Searching for a matching IE uint32_t count = *((uint32_t*)vendor_ie_list); uint8_t* current_ie = vendor_ie_list + sizeof(uint32_t); if (count >= 1) { for (uint32_t i=0; i<count; i++, current_ie += 4) { //Is this a matching IE? if (current_ie[8] == new_ie_tag && new_ie_length != 1 && !bcmp(new_ie + 1, current_ie + 10, new_ie_length-1)) { //Found a match! Ask the firmware to delete the old IE void* ie_buffer = IOMalloc(new_ie_length + 13); strlcpy(ie_buffer, "del", 4); *(uint32_t*)(ie_buffer + 4) = 1; ovbcopy(current_ie + 4, ie_buffer + 8, current_ie[9] + 6); issueCommand(...); //Send the deletion request ... } } ... } ... } ``` As can be seen above, "setVendorIE" fails to verify both the "count" field in the returned IE list, and the length of each individual IE. As a result, an attacker controlling the firmware may choose arbitrarily large values for these fields. For example, an attacker controlling the firmware could return a list containing an IE with the same tag and payload bytes as the IE being set, but with a large length field (larger than the previous IE's length + 13). Doing so will cause the match above to succeed (as it only compares the contents up to the new IE's length), but will then trigger the "obvcopy" using the attacker-controlled IE length (current_ie[9] + 6), thus overflowing the heap-allocated buffer (ie_buffer). Alternately, an attacker may choose to supply a large "count" field. Doing so will cause the loop above to read data past the end of the buffer containing the ioctl's results. If, at any point, a sequence of bytes matching the new vendor IE is encountered, the matching conditions above will be satisfied. An attacker can use this as an "oracle" to leak information from the host by spraying sequences containing the vendor IE's contents and slowly incrementing the "count" field. When a match occurs, the driver will issue the deletion ioctl to the firmware, allowing the firmware to deduce that a match occurred at the current offset.
idSSV:96625
last seen2017-11-19
modified2017-10-10
published2017-10-10
reporterRoot
titleApple: Heap overflow and information disclosure in "setVendorIE" when handling ioctl results(CVE-2017-7110)