Archives

VMware Security Response Center

New VMware Security Advisory VMSA-2017-0014

Today, VMware has released the following new security advisory:

VMSA-2017-0014 – VMware NSX-V Edge updates address OSPF Protocol LSA DoS

The advisory documents a hard to exploit denial of service vulnerability in the implementation of the OSPF protocol in NSX-V Edge. This issue is present due to incorrect handling of link-state advertisements (LSA). NSX-V Edge 6.2.8 and NSX-V Edge 6.3.3 address the issue.

We would like to thank Adi Sosnovich, Orna Grumberg and Gabi Nakibly for reporting this issue to us.

Please sign up to the Security-Announce mailing list to receive new and updated VMware Security Advisories.

Customers should review the security advisory and direct any questions to VMware Support.

The post New VMware Security Advisory VMSA-2017-0014 appeared first on VMware Security & Compliance Blog.

Read more..

New VMware Security Advisory VMSA-2017-0013

Today VMware has released the following new security advisory:

&#rsquo;VMSA-2017-0013 – VMware vCenter Server and Tools updates resolve multiple security vulnerabilities&#rdquo;

This documents an insecure library loading issue (CVE-2017-4921) and two information disclosure issues (CVE-2017-4922 and CVE-2017-4923) affecting VMware vCenter 6.5 release line. These issues are of moderate severity.

This also documents a moderate severity local privilege escalation issue (CVE-2015-5191) affecting VMware Tools.

CVE-2017-4921 is an insecure library loading issue that occurs due to the use of ‘LD_LIBRARY_PATH’ variable in an unsafe manner. Successful exploitation of this issue may allow unprivileged host users to load a shared library that may lead to privilege escalation.

CVE-2017-4922 is an information disclosure issue that occurs due to the service startup script using world writable directories as temporary storage for critical information. Successful exploitation of this issue may allow unprivileged host users to access certain critical information when the service gets restarted.

CVE-2017-4923 is also an information disclosure vulnerability. Exploiting this issue may allow an attacker to obtain plaintext credentials when using the vCenter Server Appliance file-based backup feature.

CVE-2015-5191 is a local privilege escalation issue that exists because VMware Tools contains multiple file system races in libDeployPkg.

VMware vCenter Server 6.5 U1 and VMware Tools 10.0.9 and above fix these issues.

We would like to thank Thorsten Tüllmann, researcher at Karlsruhe Institute of Technology, Joe Womack of Expedia, Florian Weimer and Kurt Seifried of Red Hat Product Security for reporting these issues to us.

Please sign up to the Security-Announce mailing list to receive new and updated VMware Security Advisories.

Customers should review the security advisories and direct any questions to VMware Support.

The post New VMware Security Advisory VMSA-2017-0013 appeared first on VMware Security & Compliance Blog.

Read more..

Guest Access: BlackHat 2017

The Black Hat USA 2017 conference includes a talk by Ofri Ziv of Guardicore Labs about using the VIX API to obtain privileged access to a guest operating system with unexpectedly low VIM API permissions. VMSA-2017-0012 contains details of impacted versions and workarounds. The Common Vulnerabilities and Exposures project has assignedCVE-2017-4919 for this issue, with thanks toOfri Ziv and Itamar Tal of Guardicore for discovering and reporting it.

Permissions

Understanding the privilege escalation here requires understandingthe interaction between several vSphere permissions.

  • Host.Config.AdvancedConfig. This permission amounts to full host control. Setting host advanced configurations is equivalent to adjusting VIB acceptance levels or disabling firewalls.
    • In proof-of-concept code, authors used this permission to enablethe “shared secret” mechanism at the host level. VMware considers use of this permission equivalent to full control (e.g. root) and thususing it in an attack chain does not amount to a privilege escalation.
    • However, someVMware products(SRM, VUM, and VIN) operate with this permission, and the settingis host-global. When such software enables “shared secret”, they allow a lower privilege user to gain guest access for the window when it is enabled.
    • The issue reporters argue that a typical datacenter would frequently enable “shared secret”. VMware believes such enablements are uncommon, and collisionsare unlikely and can be mitigated. But as the collision is possible, VMware is treating this as an exploitable issue.
  • VirtualMachine.Config.AdvancedConfig. This is the “vulnerable” permission. Virtual machine advanced configurations are a lower privilege level than host advanced configurations, and this setting should have been safe to give to lower-privilege users.
  • VirtualMachine.Interact.GuestControl. This is the “guest control” permission; users with this permission may establish VIX API connections and thus present some form of authentication.

To compute a CVSS v3 score, VMware recommends “Access Vector: Local” to represent the need to be on the management network (equivalent to local access in a non-virtual environment), and “Attack Complexity: High” to represent the difficulty in bypassing the Host.Config.AdvancedConfig permission.

Impact andWorkarounds

Accessing a virtual machine should require two authentications: a VIM API authentication to provide a “route” to a virtual machine, and a VIX API guest authentication to access the virtual machine itself. The security issue here bypasses only the second authentication; the first authentication remains a requirement.

Before worrying about this security issue, an organization should first confirm that their configuration does assumea separation of privilege, with some users being given rights to configure or access virtual machines but being denied rights to configure hosts, and vice versa. Such least-privilege configurations are a best-practice recommendation, but manydeployments have so few vSphere users that all users operate with full permissions - at which point there is no escalation from a low-privilege user to a high-privilege user.

The escalation of privilege here requires both an ESXi host version capable of reading “shared secret” information, and a VMware Guest Tools version willing to accept “shared secret” authentication. All current versions of VMware ESXi are impacted by this issue.VMware Guest Tools prior toversion 10.1.0(released October 2016) are impacted by this issue, as beginning with Tools 10.1.0 we have disabled the “shared secret” authentication mechanism.

VMware has two recommended workarounds. Either is sufficient.

  1. Upgrade VMware Guest Tools to at least version 10.1.0, in combination with running ESXiat least version 6.0. Without an in-guest endpoint willing to accept “shared secret” authentication, there is no privilege escalation.
    • However, some older products are incompatible with newer VMware Guest Tools (see “known issues” in the 10.1.0 release notes). Those products are incompatible precisely because they depend on “shared secret” authentication.
    • VMware Guest Tools version 9.10 and later have an in-guest configuration option to disable this functionality, which is enabled by default. Version 10.1.0 changes the default to disabled. See KB 2151027for further details.
  2. Remove theVirtualMachine.Interact.GuestControl permission from vSphere users, applicable to allvSphere versions. This permissionenables VIX API access, which is necessary to present any credential at all via the VIX API (whether “shared secret”, username/password, or SAML token).
    • Most vSphere customers do not use the VIX API (and those that do, are probably aware of it). Any existing users of the VIX API should prioritize moving to the replacement Guest Operations VIM API discussed below.

VMware believes the above workaroundsare sufficient for most customers.In particular, either a Tools upgrade or removing GuestControl are straightforward to apply inmost scenarios.Regarding ESXi releases:

  • ESXi5.5 will retain “shared secret” behavior as a “mis-feature”; the only workaround is to disable the VIX API entirely via the GuestControl permission. This is ultimately a recognition that in vSphere 5.5, guest authentication was designedas a mechanism to run guest operations as a particular user and not as a security barrier. As described below, adequate securitymechanisms to provide a barrier are not available architecturally until vSphere 6.0.
  • Any future major release of ESXi will have “shared secret” authenticationremoved entirely, due to VIX API end-of-life as describedbelow.

VIX API: a slow path to deprecation

The VIX API is an old VMware API written in C, primarily intended for automation use cases. Originally created for Workstation 6 (released 2008), VIX version 1.6.2 (released 2010) added vSphere support.

That heritage embedded some toxic assumptions. The automation use case around 2008 envisioned deployingVMs under API control, and “obviously” the user invoking automation would have full control of those VMs to run processing tasks - so the VIX API offered full guest control without authentication.

Around 2010, VMware recognized that holistically, the VIX API bypassed too many important checks offered by the VIM API and needed to be removed. However, as some bloggers had noticed, the VIX API was unique in being the only mechanism to run a command in guest, which turns out to be a very powerful tool for automating virtualized software. Thus, we added Guest Operations support in the VIM API, a project that started vSphere5.0 and culminated with vSphere6.0’s support for SAML tokens to share pre-authenticated access (allowing a guest to opt-in and mapVIM users to guest users as a bridge betweentwo security domains). Simultaneously, we moved the guest-unauthenticated access to be off by default and enabled only via higher-privilege “shared secret” settings, to prevent new usages of this functionality.

Deprecation of the VIX API was announced in 2011 with VIX version 1.11, indicating “VIX will be unsupported in the second major release after vSphere 5”.Nominally those next two releases were ESXi 5.5 and 6.0, with VIX scheduled for removal in ESXi6.5. That didn’t happen.

Now for the bad news. As anyone familiar with IT or software engineering knows, anytime a feature is deprecated, somebody will build a new product depending on it before the deprecation window expires. We initially tried disabling VIX’s unauthenticated guest access entirely… and regressed many VMware products, so needed another release. SRM ported to the Guest Operations API in the 6.5 release. VUM dropped the only feature which used VIX (appliance upgrade). vRealize Infrastructure Navigator chose to end-of-life, with the replacement being the Service Discovery Management Pack.As most of those were completed late in the release, we were uncomfortable removing VIX (or even VIX’s “shared secret”) inthe 6.5 release, so delayed removal to the first major release after 6.5.

Astute observers will notice the dilemma here. On one hand, bypassing guest authenticationis increasingly an untenable security posture. On the other hand, removing this functionality will break mission-critical functionality like SRM (for disaster recovery). And there are no good answers.

Conclusions

Deprecating and removing concerning code is always a tradeoff between the risk of unknown security bugs, and unknown functional regression - a hard tradeoff to make for enterprise products where functional regressions can bring an entire business down. The removal of the entire VIX API will occur promptly as planned; thanks to this security research,the securitycosts of any further delay are more obvious.

The post Guest Access: BlackHat 2017 appeared first on VMware Security & Compliance Blog.

Read more..

New VMware Security Advisory VMSA-2017-0011

Today, VMware has released the following new security advisory:

&#rsquo;VMSA-2017-0011 – Horizon View Client update addresses a command injection vulnerability&#rdquo;

This documents an important severity command injection vulnerability (CVE-2017-4918) in the service startup script that affects VMware Horizon View Client for Mac (versions 2.x, 3.x and 4.x ).

Successful exploitation of this issue may allow unprivileged users to escalate their privileges to root on the Mac OS X system where the client is installed.

VMware Horizon View Client for Mac 4.5.0 fixes this issue.

We would like to thank Florian Bogner from Kapsch BusinessCom AG for reporting this issue to us.

Please sign up to the Security-Announce mailing list to receive new and updated VMware Security Advisories.

Customers should review the security advisories and direct any questions to VMware Support.

The post New VMware Security Advisory VMSA-2017-0011 appeared first on VMware Security & Compliance Blog.

Read more..

New VMware Security Advisory VMSA-2017-0010 and Updated Security Advisory VMSA-2016-0024.1

On 6th of June 2017, VMware released the following new and updated security advisories:

VMSA-2017-0010 - vSphere Data Protection (VDP) updates address multiple security issues.

This new security advisory documents two issues.

VDP contains a deserialization issue (CVE-2017-4914). Exploitation of this issue may allow a remote attacker to execute commands on the appliance. VMware would like to thank Tim Roberts, Arthur Chilipweli, and Kelly Correll from NTT Security for reporting this issue to us.

VDP locally stores vCenter Server credentials using reversible encryption (CVE-2017-4917). This issue may allow plaintext credentials to be obtained. VMware would like to thank Marc Ströbel aka phroxvs from HvS-Consulting for reporting this issue to VMware.

These issues have been addressed in VDP 6.1.4 and 6.0.5.

VMware has released the following updated security advisory:

VMSA-2016-0024.1 - vSphere Data Protection (VDP) updates address SSH key-based authentication issue

This issue has been addressed in VDP 6.1.4 and 6.0.5.

Please sign up to the Security-Announce mailing list to receive new and updated VMware Security Advisories.

Customers should review the security advisories and direct any questions to VMware Support.

The post New VMware Security Advisory VMSA-2017-0010 and Updated Security Advisory VMSA-2016-0024.1 appeared first on VMware Security & Compliance Blog.

Read more..

New VMware Security Advisory VMSA-2017-0009

Today VMware has released the following new security advisory:

&#rsquo;VMSA-2017-0009 – VMware Workstation update addresses multiple security issues&#rdquo;

This documents an important severity insecure library loading issue via ALSA sound driver configuration files (CVE-2017-4915) and a moderate severity NULL pointer dereference issue (CVE-2017-4916) affecting Workstation Pro/Player.

All VMware Workstation Pro/Player 12.x are affected.

Successful exploitation of the insecure library loading issue may allow unprivileged host users to escalate their privileges to root in a Linux host machine.

The NULL pointer dereference vulnerability exists in the vstor2 driver and may allow host users with normal user privileges to trigger a denial-of-service in a Windows host machine.

Workstation Pro/Player 12.5.6 fixes all these issues.

VMware would like to thank Jann Horn of Google Project Zero and Borja Merino for reporting these issues to us.

Please sign up to the Security-Announce mailing list to receive new and updated VMware Security Advisories.

Customers should review the security advisories and direct any questions to VMware Support.

The post New VMware Security Advisory VMSA-2017-0009 appeared first on VMware Security & Compliance Blog.

Read more..

New VMware Security Advisory VMSA-2017-0008

Today VMware has released the following new security advisory:

VMSA-2017-0008 – VMware Unified Access Gateway, Horizon View and Workstation updates resolve multiple security vulnerabilities

This documents several critical memory corruption vulnerabilities affecting VMware Unified Access Gateway (formerly called Access Point) (8.2.x), Horizon View (7.x, 6.2.x) and Workstation (12.5.x).

Issue (a) is a heap-based buffer overflow vulnerability (CVE-2017-4907) which affects VMware Unified Access Gateway and Horizon View. This issue may be exploited remotely to execute code on the security gateway. VMware Unified Access Gateway 2.9 is not affected. This issue has been addressed in VMware Unified Access Gateway 2.8.1, Horizon View 7.1.0 and 6.2.4.

Issues (b), (c) and (d) are heap-based buffer-overflow, out-of-bounds read/write and integer-overflow vulnerabilities (CVE-2017-4908, CVE-2017-4909, CVE-2017-4910, CVE-2017-4911, CVE-2017-4912, CVE-2017-4913) in JPEG2000 and TrueType Font (TTF) parsers in the TPView.dll. These issues exist due the use of vulnerable Cortado ThinPrint component and impact VMware Horizon View Client for Windows and Workstation. Exploitation is possible only if virtual printing has been enabled. This feature is not enabled by default on Workstation but it is enabled by default on Horizon View. These issues have been addressed in VMware Workstation 12.5.3, Horizon View Client for Windows 7.1.0 and 6.2.4.

We would like to thank Claudio Moletta (redr2e), and Ke Liu of Tencent&#rsquo;s Xuanwu Lab, Gogil and Giwan Go of STEALIEN working with ZDI for reporting these issues to us.

Please sign up to the Security-Announce mailing list to receive new and updated VMware Security Advisories.

Customers should review the security advisories and direct any questions to VMware Support.

The post New VMware Security Advisory VMSA-2017-0008 appeared first on VMware Security & Compliance Blog.

Read more..

New VMware Security Advisory VMSA-2017-0007

On Tuesday, 4th of April 2017 a remote code-execution issue in the BlazeDS library (CVE-2017-5641) was disclosed in a US-CERT security advisory. We have reviewed the issue and determined that VMware vCenter Server 6.5 and 6.0 are affected due to the use of BlazeDS to process AMF3 messages. VMware vCenter Server 5.5 is not affected.

We have released the following new security advisory which documents the fixes for VMware vCenter Server 6.5 and 6.0 along with the workarounds:

VMSA-2017-0007- VMware vCenter Server update resolves a remote code execution vulnerability via BlazeDS

Successful exploitation of this issue may allow an attacker to execute arbitrary code when deserializing an untrusted Java object. We have also investigated this issue against the other VMware products. VMware products which are not listed in the security advisory are not affected.

We would like to thank Markus Wulftange of Code White GmbH for reporting this issue to us.

Please sign up to the Security-Announce mailing list to receive new and updated VMware Security Advisories.

The post New VMware Security Advisory VMSA-2017-0007 appeared first on VMware Security & Compliance Blog.

Read more..

New VMware Security Advisory VMSA-2017-0007

On Tuesday, 4th of April 2017 a remote code-execution issue in the BlazeDS library (CVE-2017-5641) was disclosed in a US-CERT security advisory. We have reviewed the issue and determined that VMware vCenter Server 6.5 and 6.0 are affected due to the use of BlazeDS to process AMF3 messages. VMware vCenter Server 5.5 is not affected.

We have released the following new security advisory which documents the fixes for VMware vCenter Server 6.5 and 6.0 along with the workarounds:

VMSA-2017-0007- VMware vCenter Server update resolves a remote code execution vulnerability via BlazeDS

Successful exploitation of this issue may allow an attacker to execute arbitrary code when deserializing an untrusted Java object. We have also investigated this issue against the other VMware products. VMware products which are not listed in the security advisory are not affected.

We would like to thank Markus Wulftange of Code White GmbH for reporting this issue to us.

Please sign up to the Security-Announce mailing list to receive new and updated VMware Security Advisories.

The post New VMware Security Advisory VMSA-2017-0007 appeared first on VMware Security & Compliance Blog.

Read more..

The Security Landscape: Pwn2Own 2017

During the 2017 Pwn2Own competition at CanSecWest, two teams succeededin demonstrating arbitrary host code execution on VMware Workstation. Today, VMwareis releasing updated versions of VMware vSphere ESXi, VMware Fusion, andVMware Workstation to address these vulnerabilities. VMSA-2017-0006 contains details on impacted versions and the releases which contain fixes.

No active exploitation

VMware is not aware of any active exploitation of the vulnerabilitiesrevealed in this competition.Though the vulnerabilities seem to applyto all VMware virtual platforms (ESXi, Fusion, and Workstation),demonstration exploit code appears to exist only for VMware Workstationfor Windows.

The rules of the Pwn2Own competition stipulate thatcontestants provide their vulnerabilities exclusively to ZDI (the contest organizer), whoin turn provides the vulnerability only to the affected company. Weappreciate ZDI and the contestant’s commitment to responsible disclosurepractices, enabling VMware to release updates before details of thevulnerabilities become known.

Vulnerabilities Found

The following vulnerabilities were identified and analyzed:

  • SVGA I: CVE-2017-4902 critical
    Heap overflow leading to arbitrary code execution
  • SVGA II: CVE-2017-4903 critical
    Uninitialized stack value leading to arbitrary code execution
  • XHCI: CVE-2017-4904 critical
    Uninitialized stack value leading to arbitrary code execution
  • CVE-2017-4905 moderate
    Uninitialized memory read leading to information disclosure

VMware also recommends examining thevSphere Hardening Guide and
vSphere Security Guide.Among the recommendations in the guides is to remove unnecessary virtual hardware. Removing unnecessary virtual hardware increases the complexity of exploitation and can partially mitigate the issues, but cannot be a full mitigation due to the nature of modern graphics functionality.Exercise caution: removingvirtual hardware can have adverse effects on functionality or performance, and oftenrequires the virtual machine be powered off for reconfiguration.

RiskManagement

The best response is to apply the patches which correct these defects. VMwareemploys technologies like vMotion and VUM to reduce the disruption ofdeploying security patches. Further, VMware recognizes that deploying patchesdoes carry operational complexities, and understands that further improving thissituation is among our customer’s greatest needs.

One common aspect of all these vulnerabilities is the need to run arbitrary code in the guest to begin the exploit chain. (VMware categorizes guest escapes as “remotely exploitable” only for CVSS scoring purposes, as our security model assumes untrustworthy guests). Normal defensive mechanisms like antivirus and firewalls installed in the guest can prevent an attacker from having the degree of access necessary to attack the hypervisor. Locked-down environments like a production database should already disallowrunning arbitrary code, and thus mitigate this sort of attack.

Customers should consider the need to update for a full mitigation, the absence of active exploitation, the pace at which updates can safely be deployed, and any other risk mitigations (like IDS applications) which may protect their environments. At this point VMware’s recommendation is that customers expedite updating, though need not takeemergency measures like taking environments offline.


Some readers may be interested in a more detailed discussion of VMware’s approach to the security landscape.

Pwn2Own and Hypervisor Security Research

VMware engineers have been attending security conferences on a regular basisfor many years. This enables us to respond to any discovered vulnerabilities asquickly as possible, and also allows us to develop a constructive relationship with security researchers from around the world. Our engineers havebeen in contact with the Qihoo 360 team for quite some time, beginning with lastyear’s Pwn2Own 2016 competition. This year was our first introduction to theTencent team.

At CanSecWest 2016, Qihoo 360 presented work on using fuzzers to detectvirtual machine escapes. That work was primarily on QEMU-basedhypervisors (CVEs disclosed) but also including VMware hypervisors (novulnerabilities disclosed). For the first time, the Pwn2Own 2016 competitionincluded a hypervisor platform (VMware Workstation running on MicrosoftWindows 10) as a target; no teams chose to make an attempt.

At Power Of Community 2016 (Seoul, South Korea) during the PwnFest competition, Qihoo 360 and Lokihardt independently demonstrated the same guest escape for VMware Workstation via drag-and-drop functionality(not included in ESXi). VMware engineers were on hand to receiveinformation about that vulnerability (CVE-2016-7461), leadingto the release of VMware Workstation 12.5.2 and VMware Fusion 8.5.2several days later. Further mitigations and fixes for related bugs wereincluded in the 12.5.3/8.5.4 (VMSA-2017-0003) and 12.5.4/8.5.5 (VMSA-2017-0005) releases.

At CanSecWest 2017, the Qihoo 360 team presenteddetails on how they had found and exploited the drag-and-drop bug severalmonths before at PwnFest. Again VMware engineers were on hand, and communicatedwith the team before the presentation occurred to discuss what wouldbe covered, and understand what techniques the team used to find andexploit vulnerabilities. The same engineers also received full details and clarifications about the vulnerabilities used in Pwn2Own 2017 directly from the researchers from Qihoo 360 and Tencent.

These connections are important within the securitycommunity. The Qihoo 360 and Tencent teams arepremier commercialsecurity research teams in this space; as much as they profit (in bothreputation and financially) from VMware software, VMware benefitsin understanding modern offensive security research techniques and beingheld accountable to modern security practices. The learning andaccountability gained from these events is vital to maintaining the highquality our customers expect from VMware’s flagship hypervisor products.

The security landscape has changed dramaticallyover the past several years. Whereas twenty years ago it took a single bug tobreak software, and ten years ago it generally tooktwo bugs (aninformation leak to break ASLR, and the actual exploit), today’s cuttingedge defensive technologies can force an attacker to construct a chain of as manyas six bugs to break out of a web browser and its associated sandbox.Modern fuzzers likeAFL havebecome several orders of magnitudemore efficient at revealing exploitable bugs. With theprinciples of responsible disclosure to connect researchers and softwareauthors, the end result is ever-better software.

As an anecdote, a significant number of researchers at the CanSecWestconference used VMware Workstation or VMware Fusion to give live demonstrations of their work (both offensive anddefensive). We saw researchers use debuggers to simulate (destructive) exploits, show techniques on multiple operating systems during a single talk, or use a virtual machine to simultaneously run their slides and unsafe (un-patched) software to demonstrate a particular technique.VMware recognizesthe responsibility that goes with being an importanttool for cutting-edgesecurity research, and the inherent requirements of those securityresearchers to ensure any malware or vulnerable software they may be researching remainscontained within virtual machines. As security knowledge moves forward, so doVMware’s technologies and techniques to keep researchers protected.

The Evolving Security Landscape

A “guest escape” - arbitrary code execution on a virtual machinehost - is the worst category of bug for virtualization software (CVSS of 10.0).VMware software has done well over time in defending against malicioussoftware, though this is not the first guest escape demonstrated inVMware’s history (see most notably CVE-2009-1244“Cloudburst”,which also affected the virtual SVGA device implementation).

The single best defense against this type of security issue is depth. A robustchain of defenses includes using firewalls / network IDS to control accessto virtual machines, running anti-virus or other host IDS to block malicioussoftware from running on a virtual machine, and the hypervisor itself to isolatevirtual machines from each other. At some point in time, any of these layers maymiss something important or have a bug; the goal is to have enough layers thatnot all can be breached simultaneously.

At VMworld 2016 (Las Vegas and Barcelona), VMware included a session onsecurity risks around “guest escapes”. The message then remains the sameas the message now: security risks are both human and technical, and weconsistently see the human aspect under-prioritized when the technicalaspect becomes newsworthy. Hypervisor arbitrary code execution bugs are stillVERY complicated to discover and exploit; they command the highest prizes at competition and onlythe best-resourced teams have been able to enter the space, though the barrier to entry is lessening. By contrast, our experiencehas consistently shown that the biggest threat to IT of any kind is misconfigurationand laxoperational practices. We should also learnfrom web browsers: the average user is at greater risk from phishing than from a webbrowser vulnerability, and the most effectivedefense is to stay up to date withpatches.

VMware’s Software Development Lifecycleapplies a similar defense in depth strategy. We use code reviews to get humaneyeballs looking for problems, and also deploy static analysis tools, threat modeling,external audits, and testing (including fuzz testing) to minimize the chances of avulnerability escaping detection.

To characterize the change we are seeing in the security landscape right now, thereis a gradual evolution in targets that can be attacked. When VMware models threats, weconsider three categories of actor. The “nation-state”actor has vast resources but generally employs them against limited targets; such an actor will find a wayto breach security, whether by technical means or something simpler (money, ideology). The“professional” actor has more limited resources, and tends to look for the softest andmost profitable target; defending against this actor amounts to staying on or ahead ofthe security research curve. And the “script kiddie” uses off-the-shelf resources andpreviously-known issues; defending here generally requires littlemore than stayingup to date, and the biggest risk is installations which fail to deploy existing patches.The Pwn2Own competition shows that the difficulty of hypervisor attacks is movingfrom the “nation-state” category to the upper end of the “professional” category. This is a trend we have been expectingfor a while, as security researchtools become more powerful.

As offensive security evolves,so does defensive security. With vSphere 6.5, VMware began deploying sandboxingtechnology around virtual machines to prevent a single arbitrary code execution fromspreading across a host -a technique we have adaptedfrom studying how web browsers and cell phones have evolvedto defend against offensive security research. We are proactively disabling or removing legacy features - the loss incompatibility is increasingly outweighed by the reduction in attacksurface. And we are investing deeply in ease-of-upgrade, recognizingthat prompt security patches do little good if they cannot be deployedto production in time.

Conclusion

Ultimately, our security mindset is to ask “when”, not “if”, asecurity vulnerability will occur. This means being proactive in looking forvulnerabilities, staying in touch with the security community to be aware ofcurrent trends and research, and developing more efficient means to deploy theinevitable fixes as they become ready.

As always, our goal is to provide customers with the tools they need tooperate at their most efficient, while retaining the security mechanismswe all depend upon in the modern IT environment.

The post The Security Landscape: Pwn2Own 2017 appeared first on VMware Security & Compliance Blog.

Read more..

Go Que Newsroom

Categories