Vulnerabilities > CVE-2017-4941 - Improper Restriction of Operations within the Bounds of a Memory Buffer vulnerability in VMWare Esxi, Fusion and Workstation

047910
CVSS 8.8 - HIGH
Attack vector
NETWORK
Attack complexity
LOW
Privileges required
LOW
Confidentiality impact
HIGH
Integrity impact
HIGH
Availability impact
HIGH
network
low complexity
vmware
CWE-119
nessus

Summary

VMware ESXi (6.0 before ESXi600-201711101-SG, 5.5 ESXi550-201709101-SG), Workstation (12.x before 12.5.8), and Fusion (8.x before 8.5.9) contain a vulnerability that could allow an authenticated VNC session to cause a stack overflow via a specific set of VNC packets. Successful exploitation of this issue could result in remote code execution in a virtual machine via the authenticated VNC session. Note: In order for exploitation to be possible in ESXi, VNC must be manually enabled in a virtual machine's .vmx configuration file. In addition, ESXi must be configured to allow VNC traffic through the built-in firewall.

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 familyVMware ESX Local Security Checks
    NASL idVMWARE_VMSA-2017-0021.NASL
    descriptiona. ESXi, Workstation, and Fusion stack overflow via authenticated VNC session VMware ESXi, Workstation, and Fusion contain a vulnerability that could allow an authenticated VNC session to cause a stack overflow via a specific set of VNC packets. Successful exploitation of this issue could result in remote code execution in a virtual machine via the authenticated VNC session. Note: In order for exploitation to be possible in ESXi, VNC must be manually enabled in a virtual machine
    last seen2020-06-01
    modified2020-06-02
    plugin id105410
    published2017-12-21
    reporterThis script is Copyright (C) 2017-2019 Tenable Network Security, Inc.
    sourcehttps://www.tenable.com/plugins/nessus/105410
    titleVMSA-2017-0021 : VMware ESXi, vCenter Server Appliance, Workstation and Fusion updates address multiple security vulnerabilities
    code
    #
    # (C) Tenable Network Security, Inc.
    #
    # The descriptive text and package checks in this plugin were  
    # extracted from VMware Security Advisory 2017-0021. 
    # The text itself is copyright (C) VMware Inc.
    #
    
    include("compat.inc");
    
    if (description)
    {
      script_id(105410);
      script_version("3.11");
      script_cvs_date("Date: 2019/09/26 15:14:18");
    
      script_cve_id("CVE-2017-4933", "CVE-2017-4940", "CVE-2017-4941", "CVE-2017-4943");
      script_xref(name:"VMSA", value:"2017-0021");
    
      script_name(english:"VMSA-2017-0021 : VMware ESXi, vCenter Server Appliance, Workstation and Fusion updates address multiple security vulnerabilities");
      script_summary(english:"Checks esxupdate output for the patches");
    
      script_set_attribute(
        attribute:"synopsis", 
        value:
    "The remote VMware ESXi host is missing one or more security-related
    patches."
      );
      script_set_attribute(
        attribute:"description", 
        value:
    "a. ESXi, Workstation, and Fusion stack overflow via authenticated
    VNC session
    
    VMware ESXi, Workstation, and Fusion contain a vulnerability that
    could allow an authenticated VNC session to cause a stack overflow
    via a specific set of VNC packets. Successful exploitation of this
    issue could result in remote code execution in a virtual machine via
    the authenticated VNC session.
    
    Note: In order for exploitation to be possible in ESXi, VNC must be
    manually enabled in a virtual machine's .vmx configuration file. In
    addition, ESXi must be configured to allow VNC traffic through the
    built-in firewall.
    
    VMware would like to thank Lilith Wyatt and another member of Cisco
    Talos for reporting this issue to us.
    
    The Common Vulnerabilities and Exposures project (cve.mitre.org) has
    assigned the identifier CVE-2017-4941 to this issue.
    
    b. ESXi, Workstation, and Fusion heap overflow via authenticated
    VNC session
    
    VMware ESXi, Workstation, and Fusion contain a vulnerability that
    could allow an authenticated VNC session to cause a heap overflow
    via a specific set of VNC packets resulting in heap corruption.
    Successful exploitation of this issue could result in remote code
    execution in a virtual machine via the authenticated VNC session.
    
    Note: In order for exploitation to be possible in ESXi, VNC must be
    manually enabled in a virtual machine's .vmx configuration file. In
    addition, ESXi must be configured to allow VNC traffic through the
    built-in firewall.
    
    VMware would like to thank Lilith Wyatt of Cisco Talos for reporting
    this issue to us.
    
    The Common Vulnerabilities and Exposures project (cve.mitre.org) has
    assigned the identifier CVE-2017-4933 to this issue.
    
    c. ESXi Host Client stored cross-site scripting vulnerability
    
    The ESXi Host Client contains a vulnerability that may allow for
    stored cross-site scripting (XSS). An attacker can exploit this
    vulnerability by injecting Javascript, which might get executed
    when other users access the Host Client.
    
    VMware would like to thank Alain Homewood of Insomnia Security
    for reporting this issue to us.
    
    The Common Vulnerabilities and Exposures project (cve.mitre.org) has
    assigned the identifier CVE-2017-4940 to this issue.
    d. Privilege escalation in vCenter Server Appliance (vCSA)
    
    VMware vCenter Server Appliance (vCSA) contains a local privilege
    escalation vulnerability via the 'showlog' plugin. Successful
    exploitation of this issue could result in a low privileged user
    gaining root level privileges over the appliance base OS.
    
    VMware would like to thank Lukasz Plonka for reporting this issue
    to us.
    
    The Common Vulnerabilities and Exposures project (cve.mitre.org) has
    assigned the identifier CVE-2017-4943 to this issue."
      );
      script_set_attribute(
        attribute:"see_also",
        value:"http://lists.vmware.com/pipermail/security-announce/2017/000394.html"
      );
      script_set_attribute(attribute:"solution", value:"Apply the missing patches.");
      script_set_cvss_base_vector("CVSS2#AV:L/AC:L/Au:N/C:C/I:C/A:C");
      script_set_cvss_temporal_vector("CVSS2#E:U/RL:OF/RC:C");
      script_set_cvss3_base_vector("CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H");
      script_set_cvss3_temporal_vector("CVSS:3.0/E:U/RL:O/RC:C");
      script_set_attribute(attribute:"exploitability_ease", value:"No known exploits are available");
      script_set_attribute(attribute:"exploit_available", value:"false");
    
      script_set_attribute(attribute:"plugin_type", value:"local");
      script_set_attribute(attribute:"cpe", value:"cpe:/o:vmware:esxi:5.5");
      script_set_attribute(attribute:"cpe", value:"cpe:/o:vmware:esxi:6.0");
      script_set_attribute(attribute:"cpe", value:"cpe:/o:vmware:esxi:6.5");
    
      script_set_attribute(attribute:"patch_publication_date", value:"2017/12/19");
      script_set_attribute(attribute:"plugin_publication_date", value:"2017/12/21");
      script_end_attributes();
    
      script_category(ACT_GATHER_INFO);
      script_copyright(english:"This script is Copyright (C) 2017-2019 Tenable Network Security, Inc.");
      script_family(english:"VMware ESX Local Security Checks");
    
      script_dependencies("ssh_get_info.nasl");
      script_require_keys("Host/local_checks_enabled", "Host/VMware/release", "Host/VMware/version");
      script_require_ports("Host/VMware/esxupdate", "Host/VMware/esxcli_software_vibs");
    
      exit(0);
    }
    
    
    include("audit.inc");
    include("vmware_esx_packages.inc");
    
    
    if (!get_kb_item("Host/local_checks_enabled")) audit(AUDIT_LOCAL_CHECKS_NOT_ENABLED);
    if (!get_kb_item("Host/VMware/release")) audit(AUDIT_OS_NOT, "VMware ESX / ESXi");
    if (
      !get_kb_item("Host/VMware/esxcli_software_vibs") &&
      !get_kb_item("Host/VMware/esxupdate")
    ) audit(AUDIT_PACKAGE_LIST_MISSING);
    
    
    init_esx_check(date:"2017-12-19");
    flag = 0;
    
    
    if (esx_check(ver:"ESXi 5.5", vib:"VMware:esx-base:5.5.0-3.103.6480267")) flag++;
    if (esx_check(ver:"ESXi 5.5", vib:"VMware:esx-ui:1.12.0-6027315")) flag++;
    
    if (esx_check(ver:"ESXi 6.0", vib:"VMware:esx-base:6.0.0-3.76.6856897")) flag++;
    if (esx_check(ver:"ESXi 6.0", vib:"VMware:esx-ui:1.22.0-6282878")) flag++;
    if (esx_check(ver:"ESXi 6.0", vib:"VMware:vsan:6.0.0-3.76.6769077")) flag++;
    if (esx_check(ver:"ESXi 6.0", vib:"VMware:vsanhealth:6.0.0-3000000.3.0.3.76.6769078")) flag++;
    
    if (esx_check(ver:"ESXi 6.5", vib:"VMware:esx-base:6.5.0-1.29.6765664")) flag++;
    if (esx_check(ver:"ESXi 6.5", vib:"VMware:esx-tboot:6.5.0-1.29.6765664")) flag++;
    if (esx_check(ver:"ESXi 6.5", vib:"VMware:esx-ui:1.23.0-6506686")) flag++;
    if (esx_check(ver:"ESXi 6.5", vib:"VMware:vsan:6.5.0-1.29.6765666")) flag++;
    if (esx_check(ver:"ESXi 6.5", vib:"VMware:vsanhealth:6.5.0-1.29.6765667")) flag++;
    
    
    if (flag)
    {
      if (report_verbosity > 0) security_hole(port:0, extra:esx_report_get());
      else security_hole(0);
      exit(0);
    }
    else audit(AUDIT_HOST_NOT, "affected");
    
  • NASL familyWindows
    NASL idVMWARE_PLAYER_WIN_VMSA_2017_0021.NASL
    descriptionThe version of VMware Player installed on the remote Windows host is 12.x prior to 12.5.8. It is, therefore, affected by multiple vulnerabilities that can allow code execution in a virtual machine via the authenticated VNC session as well as cause information disclosure from one virtual machine to another virtual machine on the same host.
    last seen2020-06-01
    modified2020-06-02
    plugin id105555
    published2018-01-04
    reporterThis script is Copyright (C) 2018-2019 and is owned by Tenable, Inc. or an Affiliate thereof.
    sourcehttps://www.tenable.com/plugins/nessus/105555
    titleVMware Player 12.x < 12.5.8 Multiple Vulnerabilities (VMSA-2017-0021) (VMSA-2018-0002) (Spectre)
  • NASL familyWindows
    NASL idVMWARE_WORKSTATION_WIN_VMSA_2017_0021.NASL
    descriptionThe version of VMware Workstation installed on the remote Windows host is 12.x prior to 12.5.8. It is, therefore, affected by multiple vulnerabilities that can allow code execution in a virtual machine via the authenticated VNC session as well as cause information disclosure from one virtual machine to another virtual machine on the same host.
    last seen2020-06-01
    modified2020-06-02
    plugin id105487
    published2017-12-29
    reporterThis script is Copyright (C) 2017-2019 and is owned by Tenable, Inc. or an Affiliate thereof.
    sourcehttps://www.tenable.com/plugins/nessus/105487
    titleVMware Workstation 12.x < 12.5.8 Multiple Vulnerabilities (VMSA-2017-0021) (VMSA-2018-0002) (Spectre)
  • NASL familyMacOS X Local Security Checks
    NASL idMACOSX_FUSION_VMSA_2017_0021.NASL
    descriptionThe version of VMware Fusion installed on the remote macOS or Mac OS X host is 8.x prior to 8.5.9. It is, therefore, affected by multiple vulnerabilities that can allow code execution in a virtual machine via the authenticated VNC session as well as cause information disclosure from one virtual machine to another virtual machine on the same host.
    last seen2020-06-01
    modified2020-06-02
    plugin id105485
    published2017-12-29
    reporterThis script is Copyright (C) 2017-2019 and is owned by Tenable, Inc. or an Affiliate thereof.
    sourcehttps://www.tenable.com/plugins/nessus/105485
    titleVMware Fusion 8.x < 8.5.9 Multiple Vulnerabilities (VMSA-2017-0021) (VMSA-2018-0002) (Spectre) (macOS)
  • NASL familyMisc.
    NASL idVMWARE_ESXI_VMSA-2017-0021.NASL
    descriptionThe remote VMware ESXi host is version 5.5, 6.0, or 6.5 and is missing a security patch. It is, therefore, affected by multiple vulnerabilities that can allow code execution in a virtual machine via the authenticated VNC session as well as cause information disclosure from one virtual machine to another virtual machine on the same host.
    last seen2020-06-01
    modified2020-06-02
    plugin id105486
    published2017-12-29
    reporterThis script is Copyright (C) 2017-2019 and is owned by Tenable, Inc. or an Affiliate thereof.
    sourcehttps://www.tenable.com/plugins/nessus/105486
    titleESXi 5.5 / 6.0 / 6.5 / Multiple Vulnerabilities (VMSA-2017-0021) (VMSA-2018-0002) (Spectre) (remote check)

Seebug

bulletinFamilyexploit
description### Summary An exploitable code execution vulnerability exists in the remote management functionality of VMware . A specially crafted set of VNC packets can cause a type confusion resulting in stack overwrite, which could lead to code execution. An attacker can initiate a VNC session to trigger this vulnerability. ### Tested Versions VMware Workstation Pro 12.5.7, Linux/Windows ### Product URLs https://my.vmware.com/web/vmware/info/slug/desktopendusercomputing/vmwareworkstationpro/120 ### CVSSv3 Score 9.0 - CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H ### CWE CWE-843: Access of Resource Using Incompatible Type ### Details VMware's VNC implementation is used for remote management, remote access, and automation purposes in VMware products, such as Workstation, Player, and ESXi, which share a common VMW VNC code base between them all. As specified by the RFB protocol[1], all VNC servers have to support a specific set of VNC messages. The relevant messages for the purposes of this write-up are listed (format: [byteLen,Varname]): ``` VncPointerEvent [\x05][1'button-mask'][2,x'Cord'][2,'yCord'] VncSetPixelFormat [\x00][3,'pad'],[1,'bpp'],[1,'depth'],[1,'bigE_fl'],[1,'true_col_fl'], [2,'redmax'], [2,'greenmax'],[2,'bluemax'],[1,'redshift'],[1,'greenshift'],[1,'blueshift'], [3,'pad'], VncFrameBufferUpdateRequest [\x03][1,'incremental'],[2,'xpos'],[2,'ypos'],[2,'width'],[2,'height'] ``` The high level overview of this bug is that we request the VNC server to create a frame buffer (a screenshot essentially), and then we cause the mouse cursor to have to be re-rendered. During this period, we also ask the VNC server to turn off “TrueColor” mode (as gathered from the VncServerInit packet) via the VncSetPixelFormat message. Turning TrueColor mode off causes the server to mis-interpret the type of the cursor when it tries to decode the cursor, leading to a high value (0xff00000) getting written into the cursor's PNG infoStruct. This value is later mis-interpreted as the amount of palettes or pixels, causing a loop which reads and writes to the stack to overflow. A few small details that are required for this crash to occur: ``` 1. The VNCSetPixelFormat must have the 'bits-per-pixel' and 'depth' fields set to 0x8, otherwise the libpng code will not reach the overflow loop. 2. While a VNCPointerEvent message was utilized, any VNC or VmwareVNC message that causes the cursor to be re-rendered is sufficient. This includes the VMware pointer event packet, and also the VNC messages to grab the cursor. 3. The VNCFrameBufferUpdate Request must not have the “incremental” field set. But if it does, you can replay the POC packets to cause the crash. ``` It should also be noted that basically any order of these packets will work, the only way I could get it to not crash was to have the FrameBufferUpdate request first, followed by a .2 second sleep between it and the PixelFormat request. The position of the VNCPointer message is not important. But now onto the lower level details: the following is the disassembly that overwrites the variable on the stack that is eventually used as the loop counter: ``` mov dword ptr [rsp+136], 0FF0000h mov dword ptr [rsp+144], 0FF00h mov [rsp+80], rax 4C8 lea rax, concurency_demangle mov dword ptr [rsp+140], 0FFh ``` The main indicators of this being a type confusion were the above hardcoded values (which also seem to be RGB color bitmasks). Interestingly, before this assignment, there is a check on a byte [rdi+0x413] within a custom VMware structure that also contains PNG struct info, the assumption being that this byte determines whether or not the PNG cursor is currently in TrueColor mode or not. ``` <(^.^)># x/4gx $rdi+0x410 0x7f90900701a0: 0x0000000101000001 0xfffffffcfffffff9 0x7f90900701b0: 0x000000130000000d 0x0000000000000000 ``` Since it seems that if you wait long enough in between sending the FrameBuffer and SetPixelFormat VNC messages (>.20 seconds) this crash does not occur, the current running theory is that there is a race condition between the thread handling the rendering of the cursor onto the frame buffer, and the thread handling the updating of encoding of the cursor and the Framebuffer, such that there is a type mismatch, where one is TrueColor and one is not. Interestingly, in the Linux version of this bug, there is a possibility for exploitation, while for the windows version, there is a lot less of a chance. The disassembly of the crashing loop for Windows and Linux is respectively listed below: ``` // Linux loc_7F350F487A40: movzx ecx, byte ptr [rdx+1Eh] ; extract RGB data .text:00007F350F487A44 398 add esi, 1 mov [rax], cl movzx ecx, byte ptr [rdx+1Dh] mov [rax+1], cl movzx ecx, byte ptr [rdx+1Ch] add rdx, 4 mov [rax+2], cl mov rdi, [rsp+398h+counter_base_obj] add rax, 3 mov ecx, [rdi+18h] ; rdi+0x18==max_loops cmp ecx, esi ; esi==iteration_count ja short loc_7F350F487A40 ; extract RGB data // Windows lea rcx, [rsp+3B8h+var_327] lea rdx, [rdi+1Dh] mov r8, r9 ; Max_loops only read ; once, before loop loc_14044C270: ; Crashing loop movzx eax, byte ptr [rdx+1] add rcx, 3 add rdx, 4 sub r8, 1 mov [rcx-4], al movzx eax, byte ptr [rdx-4] mov [rcx-3], al movzx eax, byte ptr [rdx-5] mov [rcx-2], al jnz short loc_14044C270 ; Crashing loop ``` Since the Linux version reads in the loop counter off the stack with each iteration, eventually the loop counter gets overwritten with another value. If this value ever happens to be less than the current counter, the loop will exit and the program would resume with a modified stack. Since the vmware-vmx binary was compiled without stack-smashing protection, this makes exploitation easier for an attacker. ### Crash Information ``` Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fda8992a700 (LWP 50584)] [----------------------------------registers-----------------------------------] RAX: 0x7fda8992a59f --> 0x0 RBX: 0x7fda54062470 --> 0x0 RCX: 0x49580200 RDX: 0x7fda8992afe4 --> 0x0 RSI: 0x6b5 RDI: 0x7fda89929510 --> 0x7f00409a92da7f00 RBP: 0x40 ('@') RSP: 0x7fda89929110 --> 0xffffffff00000000 RIP: 0x7fda9035bdc0 (movzx ecx,BYTE PTR [rdx+0x1e]) R8 : 0x3 R9 : 0x0 R10: 0xf8a9422d6e103298 R11: 0x13690 R12: 0x7fda89929970 --> 0x0 R13: 0x7fda543e4090 --> 0x700000001 R14: 0xba R15: 0x0 EFLAGS: 0x13216 (carry PARITY ADJUST zero sign trap INTERRUPT direction overflow) [-------------------------------------code-------------------------------------] 0x7fda9035bdb1: lea rax,[rsp+0x70] 0x7fda9035bdb6: xor esi,esi 0x7fda9035bdb8: nop DWORD PTR [rax+rax*1+0x0] => 0x7fda9035bdc0: movzx ecx,BYTE PTR [rdx+0x1e] 0x7fda9035bdc4: add esi,0x1 0x7fda9035bdc7: mov BYTE PTR [rax],cl 0x7fda9035bdc9: movzx ecx,BYTE PTR [rdx+0x1d] 0x7fda9035bdcd: mov BYTE PTR [rax+0x1],cl [------------------------------------stack-------------------------------------] 0000| 0x7fda89929110 --> 0xffffffff00000000 0008| 0x7fda89929118 --> 0x0 0016| 0x7fda89929120 --> 0x0 0024| 0x7fda89929128 --> 0xffffffff0000000e 0032| 0x7fda89929130 --> 0x0 0040| 0x7fda89929138 --> 0x0 0048| 0x7fda89929140 --> 0xffffffff0000000f 0056| 0x7fda89929148 --> 0x0 [------------------------------------------------------------------------------] Legend: code, data, rodata, value Stopped reason: SIGSEGV 0x00007fda9035bdc0 in ?? () ``` ### Mitigation An important factor in this vulnerability is that it requires a successful VNC authentication beforehand, but by default, VMware does not require a username/password for VNC sessions. Turning on VNC authentication should mitigate this, turning it from a no-auth bug to a single-auth one. ### Timeline * 2017-07-12 - Vendor Disclosure * 2017-12-19 - Public Release
idSSV:97000
last seen2017-12-25
modified2017-12-20
published2017-12-20
reporterRoot
titleVMware VNC Pointer Decode Code Execution Vulnerability(CVE-2017-4941)

Talos

idTALOS-2017-0369
last seen2019-05-29
published2017-12-19
reporterTalos Intelligence
sourcehttp://www.talosintelligence.com/vulnerability_reports/TALOS-2017-0369
titleVMware VNC Pointer Decode Code Execution Vulnerability