Tag Archives: vulnerabilities

September Patch Tuesday addresses 2 Windows zero-days

September Patch Tuesday arrived with fixes for two zero-day vulnerabilities and three public disclosures that make patching the OS on both clients and servers a priority for administrators.

Microsoft addressed 79 unique vulnerabilities — 17 with a critical severity rating — including two Windows zero-days that administrators should put near the top of their patching priority list. As part of its September Patch Tuesday releases, Microsoft also closed bugs in its Internet Explorer and Edge browsers, Microsoft Office, Skype for Business, Exchange Server and Yammer. 

Microsoft squashes two Windows zero-days

A zero-day (CVE-2019-1214) in the Windows Common Log File System driver gives an attacker, who needs to have prior access to the network, a way to elevate privileges by running a specially crafted application. This vulnerability, rated important, affects all supported versions of Windows on the server and client side.

Chris Goettl, director of product management and security, IvantiChris Goettl

“This is what attackers will use to elevate their privilege level and be able to gain persistent access and start to pivot and move elsewhere the environment,” said Chris Goettl, director of product management and security at Ivanti, a security and IT management vendor based in South Jordan, Utah.

Microsoft patched another zero-day (CVE-2019-1215). This flaw in the Winsock component, rated important, lets an intruder who has gained access with local authentication run code with elevated privileges. This vulnerability affects all supported Windows systems on desktops and clients.

It’s important to weigh other factors in addition to the severity rating and the Common Vulnerability Scoring System (CVSS) score when determining the precedence of updates for systems, Goettl said. An administrator who gives critical updates top billing might miss these sorts of zero-days that have a less severe rating, he said.

“Typically, we recommend vendor severity, plus CVSS score, and use indicators like exploited or publicly disclosed as additional risk indicators that would raise the priority,” Goettl said.

Fixes issued for three public disclosures

In August, Tavis Ormandy of Google Project Zero revealed an elevation-of-privilege vulnerability in the Windows Text Service Framework. The exploit, which requires prior authentication on the system, lets the intruder run a specially crafted program to overtake the system. Microsoft closed this vulnerability (CVE-2019-1235), rated important for all supported Windows versions, by adjusting how the Text Service Framework server and client certify input from each other.

Our speculation is that the threat actors who are going to take advantage of BlueKeep are less likely to do so from a ransomware perspective.
Chris GoettlDirector of product management and security, Ivanti

“The risk of a public disclosure is that there is enough information about how to exploit this vulnerability in the wild. An attacker has an advanced start on research. They don’t have to reverse-engineer and try to figure it all out for themselves,” Goettl said.

CVE-2019-1253 — an elevation-of-privilege vulnerability rated important for Windows 10 and Windows Server 2019 systems — follows the same pattern as the other vulnerabilities: An attacker who has logged into a system can run code to elevate privileges. Microsoft’s update corrects the flaw in the Windows AppX Deployment Server, which handles tasks related to apps in the Microsoft Store.

The last public disclosure is a bug in the Windows secure boot security feature (CVE-2019-1294), rated important, that affects Windows 10 and Windows Server 2019 systems. The exploit requires physical access to a device running the OS, such as a laptop. Systems that use BitLocker and full-disk encryption would not be susceptible to this kind of attack, Goettl said.

Several Microsoft development tools patched

Administrators who manage Windows developer environments will need to examine the September Patch Tuesday releases closely for fixes affecting several coding-related tools and technologies, including the ChakraCore JavaScript component in the Edge browser, Visual Studio, the Project Rome software development kit, the .NET Framework and Team Foundation Server.

“The .NET Framework update was only for 3.5 and later, nothing earlier. This is one of those areas where people need to focus on moving forward from those older development tool sets that have reached end-of-life to continue to get security coverage from Microsoft,” Goettl said.

BlueKeep vulnerability continues to remain a concern

Microsoft continued to close holes in the Remote Desktop Client by addressing four critical vulnerabilities — CVE-2019-0787, CVE-2019-0788, CVE-2019-1290 and CVE-2019-1291 — that do not have the same “wormable” threat potential as BlueKeep and DejaBlue. The bugs fixed by the September Patch Tuesday updates would require some interaction from a user to trigger the exploit.

Even after multiple warnings from Microsoft, there has been no BlueKeep outbreak on Windows systems, despite recent exploit code releases. In one recent example, Metasploit — an open source penetration testing framework sponsored by security company Rapid7 — published a BlueKeep module on Sept. 6. The coders purposefully limited the module’s abilities to curb potential misuse.

“By default, Metasploit’s BlueKeep exploit only identifies the target operating system version and whether the target is likely to be vulnerable. The exploit does not currently support automatic targeting; it requires the user to manually specify target details before it will attempt further exploitation,” Rapid7 wrote in a blog.

Despite the outcry on Twitter related to the Metasploit release, other security vendors have released similar code, and Goettl said he suspects a global catastrophe might not come to fruition for one specific reason.

“Our speculation is that the threat actors who are going to take advantage of BlueKeep are less likely to do so from a ransomware perspective,” Goettl said. “If somebody did this from a cryptomining perspective and spread this out to hundreds of thousands of systems simultaneously — even for a few months — the revenue stream could be on the order of tens of millions of dollars, compared to the $200,000 WannaCry was able to extort over its five-month life.”

All Windows systems get critical servicing stack update

In what may be a prelude to upcoming changes to Windows updates, Microsoft issued an advisory (ADV990001) related to the servicing stack in all supported client and server Windows OSes.

The corresponding Knowledge Base articles indicate administrators should apply servicing stack updates before the latest cumulative update to ensure security updates arrive and install properly. The fact that all Windows systems require this update points to a significant change coming from Microsoft, possibly over the next few months, Goettl said. He recommended administrators put this update near the top of their priority list; otherwise, they could be in for a surprise when Patch Tuesday comes and their systems cannot install security updates.

“You should definitely start testing and planning this out. Ideally, if they can have it installed before October, that’s the best-case scenario, but definitely have it in place before November to avoid any last-minute scrambles,” Goettl said.

Go to Original Article
Author:

September Patch Tuesday addresses 2 Windows zero-days

September Patch Tuesday arrived with fixes for two zero-day vulnerabilities and three public disclosures that make patching the OS on both clients and servers a priority for administrators.

Microsoft addressed 79 unique vulnerabilities — 17 with a critical severity rating — including two Windows zero-days that administrators should put near the top of their patching priority list. As part of its September Patch Tuesday releases, Microsoft also closed bugs in its Internet Explorer and Edge browsers, Microsoft Office, Skype for Business, Exchange Server and Yammer. 

Microsoft squashes two Windows zero-days

A zero-day (CVE-2019-1214) in the Windows Common Log File System driver gives an attacker, who needs to have prior access to the network, a way to elevate privileges by running a specially crafted application. This vulnerability, rated important, affects all supported versions of Windows on the server and client side.

Chris Goettl, director of product management and security, IvantiChris Goettl

“This is what attackers will use to elevate their privilege level and be able to gain persistent access and start to pivot and move elsewhere the environment,” said Chris Goettl, director of product management and security at Ivanti, a security and IT management vendor based in South Jordan, Utah.

Microsoft patched another zero-day (CVE-2019-1215). This flaw in the Winsock component, rated important, lets an intruder who has gained access with local authentication run code with elevated privileges. This vulnerability affects all supported Windows systems on desktops and clients.

It’s important to weigh other factors in addition to the severity rating and the Common Vulnerability Scoring System (CVSS) score when determining the precedence of updates for systems, Goettl said. An administrator who gives critical updates top billing might miss these sorts of zero-days that have a less severe rating, he said.

“Typically, we recommend vendor severity, plus CVSS score, and use indicators like exploited or publicly disclosed as additional risk indicators that would raise the priority,” Goettl said.

Fixes issued for three public disclosures

In August, Tavis Ormandy of Google Project Zero revealed an elevation-of-privilege vulnerability in the Windows Text Service Framework. The exploit, which requires prior authentication on the system, lets the intruder run a specially crafted program to overtake the system. Microsoft closed this vulnerability (CVE-2019-1235), rated important for all supported Windows versions, by adjusting how the Text Service Framework server and client certify input from each other.

Our speculation is that the threat actors who are going to take advantage of BlueKeep are less likely to do so from a ransomware perspective.
Chris GoettlDirector of product management and security, Ivanti

“The risk of a public disclosure is that there is enough information about how to exploit this vulnerability in the wild. An attacker has an advanced start on research. They don’t have to reverse-engineer and try to figure it all out for themselves,” Goettl said.

CVE-2019-1253 — an elevation-of-privilege vulnerability rated important for Windows 10 and Windows Server 2019 systems — follows the same pattern as the other vulnerabilities: An attacker who has logged into a system can run code to elevate privileges. Microsoft’s update corrects the flaw in the Windows AppX Deployment Server, which handles tasks related to apps in the Microsoft Store.

The last public disclosure is a bug in the Windows secure boot security feature (CVE-2019-1294), rated important, that affects Windows 10 and Windows Server 2019 systems. The exploit requires physical access to a device running the OS, such as a laptop. Systems that use BitLocker and full-disk encryption would not be susceptible to this kind of attack, Goettl said.

Several Microsoft development tools patched

Administrators who manage Windows developer environments will need to examine the September Patch Tuesday releases closely for fixes affecting several coding-related tools and technologies, including the ChakraCore JavaScript component in the Edge browser, Visual Studio, the Project Rome software development kit, the .NET Framework and Team Foundation Server.

“The .NET Framework update was only for 3.5 and later, nothing earlier. This is one of those areas where people need to focus on moving forward from those older development tool sets that have reached end-of-life to continue to get security coverage from Microsoft,” Goettl said.

BlueKeep vulnerability continues to remain a concern

Microsoft continued to close holes in the Remote Desktop Client by addressing four critical vulnerabilities — CVE-2019-0787, CVE-2019-0788, CVE-2019-1290 and CVE-2019-1291 — that do not have the same “wormable” threat potential as BlueKeep and DejaBlue. The bugs fixed by the September Patch Tuesday updates would require some interaction from a user to trigger the exploit.

Even after multiple warnings from Microsoft, there has been no BlueKeep outbreak on Windows systems, despite recent exploit code releases. In one recent example, Metasploit — an open source penetration testing framework sponsored by security company Rapid7 — published a BlueKeep module on Sept. 6. The coders purposefully limited the module’s abilities to curb potential misuse.

“By default, Metasploit’s BlueKeep exploit only identifies the target operating system version and whether the target is likely to be vulnerable. The exploit does not currently support automatic targeting; it requires the user to manually specify target details before it will attempt further exploitation,” Rapid7 wrote in a blog.

Despite the outcry on Twitter related to the Metasploit release, other security vendors have released similar code, and Goettl said he suspects a global catastrophe might not come to fruition for one specific reason.

“Our speculation is that the threat actors who are going to take advantage of BlueKeep are less likely to do so from a ransomware perspective,” Goettl said. “If somebody did this from a cryptomining perspective and spread this out to hundreds of thousands of systems simultaneously — even for a few months — the revenue stream could be on the order of tens of millions of dollars, compared to the $200,000 WannaCry was able to extort over its five-month life.”

All Windows systems get critical servicing stack update

In what may be a prelude to upcoming changes to Windows updates, Microsoft issued an advisory (ADV990001) related to the servicing stack in all supported client and server Windows OSes.

The corresponding Knowledge Base articles indicate administrators should apply servicing stack updates before the latest cumulative update to ensure security updates arrive and install properly. The fact that all Windows systems require this update points to a significant change coming from Microsoft, possibly over the next few months, Goettl said. He recommended administrators put this update near the top of their priority list; otherwise, they could be in for a surprise when Patch Tuesday comes and their systems cannot install security updates.

“You should definitely start testing and planning this out. Ideally, if they can have it installed before October, that’s the best-case scenario, but definitely have it in place before November to avoid any last-minute scrambles,” Goettl said.

Go to Original Article
Author:

USBAnywhere vulnerabilities put Supermicro servers at risk

Security researchers discovered a set of vulnerabilities in Supermicro servers that could allow threat actors to remotely attack systems as if they had physical access to the USB ports.

Researchers at Eclypsium, based in Beaverton, Ore., discovered flaws in the baseboard management controllers (BMCs) of Supermicro servers and dubbed the set of issues “USBAnywhere.” The researchers said authentication issues put servers at risk because “BMCs are intended to allow administrators to perform out-of-band management of a server, and as a result are highly privileged components.

“The problem stems from several issues in the way that BMCs on Supermicro X9, X10 and X11 platforms implement virtual media, an ability to remotely connect a disk image as a virtual USB CD-ROM or floppy drive. When accessed remotely, the virtual media service allows plaintext authentication, sends most traffic unencrypted, uses a weak encryption algorithm for the rest, and is susceptible to an authentication bypass,” the researchers wrote in a blog post. “These issues allow an attacker to easily gain access to a server, either by capturing a legitimate user’s authentication packet, using default credentials, and in some cases, without any credentials at all.”

The USBAnywhere flaws make it so the virtual USB drive acts in the same way a physical USB would, meaning an attacker could load a new operating system image, deploy malware or disable the target device. However, the researchers noted the attacks would be possible on systems where the BMCs are directly exposed to the internet or if an attacker already has access to a corporate network.

Rick Altherr, principal engineer at Eclypsium, told SearchSecurity, “BMCs are one of the most privileged components on modern servers. Compromise of a BMC practically guarantees compromise of the host system as well.”

Eclypsium said there are currently “at least 47,000 systems with their BMCs exposed to the internet and using the relevant protocol.” These systems would be at additional risk because BMCs are rarely powered off and the authentication bypass vulnerability can persist unless the system is turned off or loses power.

Altherr said he found the USBAnywhere vulnerabilities because he “was curious how virtual media was implemented across various BMC implementations,” but Eclypsium found that only Supermicro systems were affected.

According to the blog post, Eclypsium reported the USBAnywhere flaws to Supermicro on June 19 and provided additional information on July 9, but Supermicro did not acknowledge the reports until July 29.

“Supermicro engaged with Eclypsium to understand the vulnerabilities and develop fixes. Supermicro was responsive throughout and worked to coordinate availability of firmware updates to coincide with public disclosure,” Altherr said. “While there is always room for improvement, Supermicro responded in a way that produced an amicable outcome for all involved.”

Altherr added that customers should “treat BMCs as a vulnerable device. Put them on an isolated network and restrict access to only IT staff that need to interact with them.”

Supermicro noted in its security advisory that isolating BMCs from the internet would reduce the risk to USBAnywhere but not eliminate the threat entirely . Firmware updates are currently available for affected Supermicro systems, and in addition to updating, Supermicro advised users to disable virtual media by blocking TCP port 623.

Go to Original Article
Author:

What is the Hyper-V Core Scheduler?

In the past few years, sophisticated attackers have targeted vulnerabilities in CPU acceleration techniques. Cache side-channel attacks represent a significant danger. They magnify on a host running multiple virtual machines. One compromised virtual machine can potentially retrieve information held in cache for a thread owned by another virtual machine. To address such concerns, Microsoft developed its new “HyperClear” technology pack. HyperClear implements multiple mitigation strategies. Most of them work behind the scenes and require no administrative effort or education. However, HyperClear also includes the new “core scheduler”, which might need you to take action.

The Classic Scheduler

Now that Hyper-V has all new schedulers, its original has earned the “classic” label. I wrote an article on that scheduler some time ago. The advanced schedulers do not replace the classic scheduler so much as they hone it. So, you need to understand the classic scheduler in order to understand the core scheduler. A brief recap of the earlier article:

  • You assign a specific number of virtual CPUs to a virtual machine. That sets the upper limit on how many threads the virtual machine can actively run.
  • When a virtual machine assigns a thread to a virtual CPU, Hyper-V finds the next available logical processor to operate it.

To keep it simple, imagine that Hyper-V assigns threads in round-robin fashion. Hyper-V does engage additional heuristics, such as trying to keep a thread with its owned memory in the same NUMA node. It also knows about simultaneous multi-threading (SMT) technologies, including Intel’s Hyper-Threading and AMD’s recent advances. That means that the classic scheduler will try to place threads where they can get the most processing power. Frequently, a thread shares a physical core with a completely unrelated thread — perhaps from a different virtual machine.

Risks with the Classic Scheduler

The classic scheduler poses a cross-virtual machine data security risk. It stems from the architectural nature of SMT: a single physical core can run two threads but has only one cache.

Classic SchedulerIn my research, I discovered several attacks in which one thread reads cached information belonging to the other. I did not find any examples of one thread polluting the others’ data. I also did not see anything explicitly preventing that sort of assault.

On a physically installed operating system, you can mitigate these risks with relative ease by leveraging antimalware and following standard defensive practices. Software developers can make use of fencing techniques to protect their threads’ cached data. Virtual environments make things harder because the guest operating systems and binary instructions have no influence on where the hypervisor places threads.

The Core Scheduler

The core scheduler makes one fairly simple change to close the vulnerability of the classic scheduler: it never assigns threads from more than one virtual machine to any physical core. If it can’t assign a second thread from the same VM to the second logical processor, then the scheduler leaves it empty. Even better, it allows the virtual machine to decide which threads can run together.

Hyper-V Core Scheduler

We will move on through implementation of the scheduler before discussing its impact.

Implementing Hyper-V’s Core Scheduler

The core scheduler has two configuration points:

  1. Configure Hyper-V to use the core scheduler
  2. Configure virtual machines to use two threads per virtual core

Many administrators miss that second step. Without it, a VM will always use only one logical processor on its assigned cores. Each virtual machine has its own independent setting.

We will start by changing the scheduler. You can change the scheduler at a command prompt (cmd or PowerShell) or by using Windows Admin Center.

How to Use the Command Prompt to Enable and Verify the Hyper-V Core Scheduler

For Windows and Hyper-V Server 2019, you do not need to do anything at the hypervisor level. You still need to set the virtual machines. For Windows and Hyper-V Server 2016, you must manually switch the scheduler type.

You can make the change at an elevated command prompt (PowerShell prompt is fine):

Note: if bcdedit does not accept the setting, ensure that you have patched the operating system.

Reboot the host to enact the change. If you want to revert to the classic scheduler, use “classic” instead of “core”. You can also select the “root” scheduler, which is intended for use with Windows 10 and will not be discussed further here.

To verify the scheduler, just run bcdedit by itself and look at the last line:

bcdedit

bcdedit will show the scheduler type by name. It will always appear, even if you disable SMT in the host’s BIOS/UEFI configuration.

How to Use Windows Admin Center to Enable the Hyper-V Core Scheduler

Alternatively, you can use Windows Admin Center to change the scheduler.

  1. Use Windows Admin Center to open the target Hyper-V host.
  2. At the lower left, click Settings. In most browsers, it will hide behind any URL tooltip you might have visible. Move your mouse to the lower left corner and it should reveal itself.
  3. Under Hyper-V Host Settings sub-menu, click General.
  4. Underneath the path options, you will see Hypervisor Scheduler Type. Choose your desired option. If you make a change, WAC will prompt you to reboot the host.

windows admin center

Note: If you do not see an option to change the scheduler, check that:

  • You have a current version of Windows Admin Center
  • The host has SMT enabled
  • The host runs at least Windows Server 2016

The scheduler type can change even if SMT is disabled on the host. However, you will need to use bcdedit to see it (see previous sub-section).

Implementing SMT on Hyper-V Virtual Machines

With the core scheduler enabled, virtual machines can no longer depend on Hyper-V to make the choice to use a core’s second logical processor. Hyper-V will expect virtual machines to decide when to use the SMT capabilities of a core. So, you must enable or disable SMT capabilities on each virtual machine just like you would for a physical host.

Because of the way this technology developed, the defaults and possible settings may seem unintuitive. New in 2019, newly-created virtual machines can automatically detect the SMT status of the host and hypervisor and use that topology. Basically, they act like a physical host that ships with Hyper-Threaded CPUs — they automatically use it. Virtual machines from previous versions need a bit more help.

Every virtual machine has a setting named “HwThreadsPerCore”. The property belongs to the Msvm_ProcessorSettingData CIM class, which connects to the virtual machine via its Msvm_Processor associated instance. You can drill down through the CIM API using the following PowerShell (don’t forget to change the virtual machine name):

The output of the cmdlet will present one line per virtual CPU. If you’re worried that you can only access them via this verbose technique hang in there! I only wanted to show you where this information lives on the system. You have several easier ways to get to and modify the data. I want to finish the explanation first.

The HwThreadsPerCore setting can have three values:

  • 0 means inherit from the host and scheduler topology — limited applicability
  • 1 means 1 thread per core
  • 2 means 2 threads per core

The setting has no other valid values.

A setting of 0 makes everything nice and convenient, but it only works in very specific circumstances. Use the following to determine defaults and setting eligibility:

  • VM config version < 8.0
    • Setting is not present
    • Defaults to 1 if upgraded to VM version 8.x
    • Defaults to 0 if upgraded to VM version 9.0+
  • VM config version 8.x
    • Defaults to 1
    • Cannot use a 0 setting (cannot inherit)
    • Retains its setting if upgraded to VM version 9.0+
  • VM config version 9.x
    • Defaults to 0

I will go over the implications after we talk about checking and changing the setting.

You can see a VM’s configuration version in Hyper-V Manager and PowerShell’s Get-VM :

Hyper-V Manager

The version does affect virtual machine mobility. I will come back to that topic toward the end of the article.

How to Determine a Virtual Machine’s Threads Per Core Count

Fortunately, the built-in Hyper-V PowerShell module provides direct access to the value via the *-VMProcessor cmdlet family. As a bonus, it simplifies the input and output to a single value. Instead of the above, you can simply enter:

If you want to see the value for all VMs:

You can leverage positional parameters and aliases to simplify these for on-the-fly queries:

You can also see the setting in recent version of Hyper-V Manager (Windows Server 2019 and current versions of Windows 10). Look on the NUMA sub-tab of the Processor tab. Find the Hardware threads per core setting:

settings

In Windows Admin Center, access a virtual machine’s Processor tab in its settings. Look for Enable Simultaneous Multithreading (SMT).

processors

If the setting does not appear, then the host does not have SMT enabled.

How to Set a Virtual Machine’s Threads Per Core Count

You can easily change a virtual machine’s hardware thread count. For either the GUI or the PowerShell commands, remember that the virtual machine must be off and you must use one of the following values:

  • 0 = inherit, and only works on 2019+ and current versions of Windows 10 and Windows Server SAC
  • 1 = one thread per hardware core
  • 2 = two threads per hardware core
  • All values above 2 are invalid

To change the setting in the GUI or Windows Admin Center, access the relevant tab as shown in the previous section’s screenshots and modify the setting there. Remember that Windows Admin Center will hide the setting if the host does not have SMT enabled. Windows Admin Center does not allow you to specify a numerical value. If unchecked, it will use a value of 1. If checked, it will use a value of 2 for version 8.x VMs and 0 for version 9.x VMs.

To change the setting in PowerShell:

To change the setting for all VMs in PowerShell:

Note on the cmdlet’s behavior: If the target virtual machine is off, the setting will work silently with any valid value. If the target machine is on and the setting would have no effect, the cmdlet behaves as though it made the change. If the target machine is on and the setting would have made a change, PowerShell will error. You can include the -PassThru parameter to receive the modified vCPU object:

Considerations for Hyper-V’s Core Scheduler

I recommend using the core scheduler in any situation that does not explicitly forbid it. I will not ask you to blindly take my advice, though. The core scheduler’s security implications matter, but you also need to think about scalability, performance, and compatibility.

Security Implications of the Core Scheduler

This one change instantly nullifies several exploits that could cross virtual machines, most notably in the Spectre category. Do not expect it to serve as a magic bullet, however. In particular, remember that an exploit running inside a virtual machine can still try to break other processes in the same virtual machine. By extension, the core scheduler cannot protect against threats running in the management operating system. It effectively guarantees that these exploits cannot cross partition boundaries.

For the highest level of virtual machine security, use the core scheduler in conjunction with other hardening techniques, particularly Shielded VMs.

Scalability Impact of the Core Scheduler

I have spoken with one person who was left with the impression that the core scheduler does not allow for oversubscription. They called into Microsoft support, and the engineer agreed with that assessment. I reviewed Microsoft’s public documentation as it was at the time, and I understand how they reached that conclusion. Rest assured that you can continue to oversubscribe CPU in Hyper-V. The core scheduler prevents threads owned by separate virtual machines from running simultaneously on the same core. When it starts a thread from a different virtual machine on a core, the scheduler performs a complete context switch.

You will have some reduced scalability due to the performance impact, however.

Performance Impact of the Core Scheduler

On paper, the core scheduler presents severe deleterious effects on performance. It reduces the number of possible run locations for any given thread. Synthetic benchmarks also show a noticeable performance reduction when compared to the classic scheduler. A few points:

  • Generic synthetic CPU benchmarks drive hosts to abnormal levels using atypical loads. In simpler terms, they do not predict real-world outcomes.
  • Physical hosts with low CPU utilization will experience no detectable performance hits.
  • Running the core scheduler on a system with SMT enabled will provide better performance than the classic scheduler on the same system with SMT disabled

Your mileage will vary. No one can accurately predict how a general-purpose system will perform after switching to the core scheduler. Even a heavily-laden processor might not lose anything. Remember that, even in the best case, an SMT-enabled core will not provide more than about a 25% improvement over the same core with SMT disabled. In practice, expect no more than a 10% boost. In the simplest terms: switching from the classic scheduler to the core scheduler might reduce how often you enjoy a 10% boost from SMT’s second logical processor. I expect few systems to lose much by switching to the core scheduler.

Some software vendors provide tools that can simulate a real-world load. Where possible, leverage those. However, unless you dedicate an entire host to guests that only operate that software, you still do not have a clear predictor.

Compatibility Concerns with the Core Scheduler

As you saw throughout the implementation section, a virtual machine’s ability to fully utilize the core scheduler depends on its configuration version. That impacts Hyper-V Replica, Live Migration, Quick Migration, virtual machine import, backup, disaster recovery, and anything else that potentially involves hosts with mismatched versions.

Microsoft drew a line with virtual machine version 5.0, which debuted with Windows Server 2012 R2 (and Windows 8.1). Any newer Hyper-V host can operate virtual machines of its version all the way down to version 5.0. On any system, run  Get-VMHostSupportedVersion to see what it can handle. From a 2019 host:

So, you can freely move version 5.0 VMs between a 2012 R2 host and a 2016 host and a 2019 host. But, a VM must be at least version 8.0 to use the core scheduler at all. So, when a v5.0 VM lands on a host running the core scheduler, it cannot use SMT. I did not uncover any problems when testing an SMT-disabled guest on an SMT-enabled host or vice versa. I even set up two nodes in a cluster, one with Hyper-Threading on and the other with Hyper-Threading off, and moved SMT-enabled and SMT-disabled guests between them without trouble.

The final compatibility verdict: running old virtual machine versions on core-scheduled systems means that you lose a bit of density, but they will operate.

Summary of the Core Scheduler

This is a lot of information to digest, so let’s break it down to its simplest components. The core scheduler provides a strong inter-virtual machine barrier against cache side-channel attacks, such as the Spectre variants. Its implementation requires an overall reduction in the ability to use simultaneous multi-threaded (SMT) cores. Most systems will not suffer a meaningful performance penalty. Virtual machines have their own ability to enable or disable SMT when running on a core-scheduled system. All virtual machine versions prior to 8.0 (WS2016/W10 Anniversary) will only use one logical processor per core when running on a core-scheduled host.

Go to Original Article
Author: Eric Siron

Zoom security issues leave vendor scrambling

Zoom was caught flatfooted this week by the reaction to a security researcher’s report on the vulnerabilities of a web server it had quietly installed on Apple computers. The debacle raised broader questions on whether unified communications vendors were too quick to sacrifice privacy and security for ease of use.

The Zoom security issue stemmed from the use of the web server as a workaround for a privacy feature on version 12 of the Safari web browser, which Apple released for the Mac last fall. The feature forced users to consent to open Zoom’s video app every time they tried to join a meeting. In contrast, browsers like Chrome and Firefox let users check a box telling them to automatically trust Zoom’s app in the future.

Zoom felt the extra click in Safari would undermine its frictionless experience for joining meetings, so it installed the web server on Mac computers to launch a meeting immediately.

That left Mac users vulnerable to being instantly joined to a Zoom meeting by clicking on a spam link or loading a malicious website or pop-up advertisement. A similar risk still exists for all Mac and PC users who choose to have their web browsers automatically launch Zoom.

Another issue with the Mac web server was that it would remain in place even after users deleted the Zoom app, and would automatically reinstall Zoom upon receiving a request to join a meeting, according to the security researcher. It also created an avenue for denial-of-service attacks, a risk that Zoom released an optional patch for in May.

In a broader sense, the permanent installation of a web server on local devices troubled independent researcher Jonathan Leitschuh, who sparked this week’s events with a blog post Monday.

“First off, let me start off by saying having an installed app that is running a web server on my local machine with a totally undocumented API feels incredibly sketchy to me,” Leitschuh wrote in his public disclosure. “Secondly, the fact that any website that I visit can interact with this web server running on my machine is a huge red flag for me as a security researcher.”

Leitschuh’s disclosure forced Zoom to issue multiple statements as user outrage grew. The security threat received widespread international news coverage, with many headlines containing the chilling combination of “hacker” and “webcam.” In an interview Wednesday, Zoom’s chief information security officer, Richard Farley, said the news coverage caused “maybe some panic that was unnecessary.”

“Part of the challenge for us, of course, is controlling that message out there that this was not as big a deal as it’s been made out to be,” Farley said. “There’s a lot of misinformation that went out there. … People just didn’t understand it.”

Zoom initially tried to assuage fears about the Mac web server without removing it. The company pointed out that it would be obvious to users they had just joined a meeting because a window would open in the foreground and their webcam’s indicator light would flash on. Also, a hacker couldn’t gain access to a webcam in secret or retain access to that video feed after users exited a meeting.  

Ultimately, Zoom reversed its original position and released a software update Tuesday that removed the web server from its Mac architecture. The next day, Apple pushed out a software patch that wiped the web server from all Mac devices, even for users who had previously deleted Zoom.

“We misjudged the situation and did not respond quickly enough — and that’s on us,” Zoom CEO Eric Yuan wrote in a blog post. “We take full ownership, and we’ve learned a great deal.”

Zoom’s default preferences added fuel to the fire. Unless users go out of their way to alter Zoom’s out-of-the-box settings, their webcams will be on by default when joining meetings. Also, Zoom does not by default have a pre-meeting lobby in which users confirm their audio and video settings before connecting.

Zoom said it would release an update over the July 13 weekend to make it easier for new users to control video settings. The first time a user joins a meeting, they will be able to instruct the app to join them to all future sessions with their webcams turned off.

Zoom has also taken heat for allowing embedded IFrame codes to launch Zoom meetings. In a statement, the company said IFrames — a method for adding HTML content to webpages — was necessary to support its integrations.

Leitschuh first raised the security issues with Zoom in March. The company invited him to its private bug bounty program, offering money in exchange for Leitschuh agreeing not to disclose his research publicly. Leitschuh, who said the proposed bounty was less than $1,000, declined because of the demand for secrecy.

Despite clashing over whether to remove the web server, Leitschuh and Zoom were able to agree on the severity of the risk it posed. They gave it a Common Vulnerability Scoring System rating of 5.4 out of 10. That score is in the “medium” range — riskier than “low” but not as severe as “high” or “critical.”

Zoom’s response to Leitschuh’s concerns was an indicator that companies have to verify the security architectures of UC vendors, analysts said.

“This event should be a clear reminder to both vendors and customers using UC and collaboration tools that there are very real threats to their platforms,” said Michael Brandenburg, analyst at Frost & Sullivan. “We are long past the days of only having to worry about toll fraud, and businesses have to be as mindful of the security risks on their UC platforms as they are with any other business application.”

Go to Original Article
Author:

Microsoft patches two Windows zero-days in July Patch Tuesday

The July 2019 Patch Tuesday release included fixes for 77 vulnerabilities, two of which were Windows zero-days that were actively exploited in the wild.

The two Windows zero-days are both local escalation-of-privilege flaws that cannot be used alone to perform an attack. One zero-day, CVE-2019-0880, is a flaw in how splwow64.exe handles certain calls. The issue affects Windows 8.1, Windows 10 and Windows Server 2012, 2016 and 2019.

“This vulnerability by itself does not allow arbitrary code execution; however, it could allow arbitrary code to be run if the attacker uses it in combination with another vulnerability that is capable of leveraging the elevated privileges when code execution is attempted,” according to Microsoft.

The other Windows zero-day the vendor patched was CVE-2019-1132, which caused the Win32k component to improperly handle objects in memory. This issue affects Windows 7 and Windows Server 2008.

“To exploit this vulnerability, an attacker would first have to log on to the system,” Microsoft noted. “An attacker could then run a specially crafted application that could exploit the vulnerability and take control of an affected system.”

This zero-day was reported to Microsoft by ESET. Anton Cherepanov, senior malware researcher for ESET, detailed a highly targeted attack in Eastern Europe and recommended upgrading systems as the best remediation against attacks.

“The exploit only works against older versions of Windows, because since Windows 8 a user process is not allowed to map the NULL page. Microsoft back-ported this mitigation to Windows 7 for x64-based systems,” Cherepanov wrote in a blog post. “People who still use Windows 7 for 32-bit systems Service Pack 1 should consider updating to newer operating systems, since extended support of Windows 7 Service Pack 1 ends on January 14th, 2020. Which means that Windows 7 users won’t receive critical security updates. Thus, vulnerabilities like this one will stay unpatched forever.”

Other patches

Beyond the two Windows zero-days patched this month, there were six vulnerabilities patched that had been publicly disclosed, but no attacks were seen in the wild. The disclosures could potentially aid attackers in exploiting the issues faster, so enterprises should prioritize the following:

  • CVE-2018-15664, a Docker flaw in the Azure Kubernetes Service;
  • CVE-2019-0962, an Azure Automation escalation-of-privilege flaw;
  • CVE-2019-0865, a denial-of-service flaw in SymCrypt;
  • CVE-2019-0887, a remote code execution (RCE) flaw in Remote Desktop Services;
  • CVE-2019-1068, an RCE flaw in Microsoft SQL Server; and
  • CVE-2019-1129, a Windows escalation-of-privilege flaw.

The Patch Tuesday release also included 15 vulnerabilities rated critical by Microsoft. Some standout patches in that group included CVE-2019-0785, a DHCP Server RCE issue, and four RCE issues affecting Microsoft browsers, which Trend Micro labeled as noteworthy — CVE-2019-1004, CVE-2019-1063, CVE-2019-1104 and CVE-2019-1107.

Go to Original Article
Author:

Congress wants CVE program changes from DHS and MITRE

The House Energy and Commerce Committee completed its investigation of the Common Vulnerabilities and Exposures program this week and requested “significant changes to the very foundation of the CVE program.”

The investigation began in March of 2017 following media reports on extensive issues with the CVE tracking system, including long backlogs for assigning vulnerability scores. In letters to both the Department of Homeland Security (DHS) and MITRE Corporation — the two entities that manage the CVE program — members of the E&C Committee noted that changes have already been made to the CVE program, but said these changes didn’t address root issues with the program.

“The historical practices for managing the CVE program are clearly insufficient. Barring significant improvements, they will likely lead again to challenges that have direct, negative impacts on stakeholders across society,” Committee members wrote in the letters. “The Committee understands and appreciates that DHS and MITRE have already undertaken reforms to try and address the issues that prompted the Committee’s initial request. However, many of these reforms target symptoms that stem from what the Committee considers to be underlying root-causes — the contract-based nature of the program and the lack of oversight — which have yet to be addressed.”

During its investigation into the CVE program, the E&C Committee found red flags right from the start.

“Given the importance of the CVE program as critical cyberinfrastructure, the Committee expected to receive substantially more documentation in response to its request than was produced,” the Committee wrote in the letter to DHS. “[T]he Committee was surprised by the dearth of produced analyses, timelines, and other oversight materials documenting the year-over-year health of the program. The Committee finds the lack of documentation produced by DHS and MITRE to be revealing in and of itself.” 

The Committee members said the contract-based nature of the CVE program led to inconsistent funding, short-term planning and thousands of vulnerabilities per year that didn’t receive CVE numbers. The Committee suggested this be changed to make funding a PPA (Program, Project, or Activity) line item in the DHS budget in the hopes of forcing DHS and MITRE to take the program more seriously.

“The documentation produced to the Committee suggests that neither DHS nor MITRE fully recognize CVE’s status as critical cyberinfrastructure. Instead, both organizations continued to manage and fund the program through a series of contract which themselves were unstable,” the committee wrote. “This approach was perhaps to be expected given that neither organization, according to produced documentation, performed the lever of oversight needed to ensure the program continued to fulfill its purpose and meet stakeholder needs.”

The Committee also requested DHS and MITRE perform biennial reviews of the CVE program “to ensure its effectiveness and stability.”

“Since the CVE program’s inception, the nature of cybersecurity threats it is meant to address has drastically evolved. So, too, have stakeholders’ needs. Yet the scope and mission of the CVE program have not undergone similar transformation,” the Committee wrote. “By conducting regular reviews of the program, officials would be able to develop short, medium and long-term goals and then evaluate their progress at achieving those goals.”

However, even these changes to so-called “root-causes” of the CVE program’s issues weren’t enough for all experts. K. Reid Wightman, vulnerability analyst at Dragos Inc., said on Twitter the recommendations showed “the wildly inaccurate CVSS scores that accompany most CVEs was out of scope,” but added he would be “glad if some progress is made on assignments at least.”

DHS and MITRE have until Sept. 4 to respond to the recommendations made by the E&C Committee.

August Patch Tuesday closes CPU bug, two zero-day exploits

Microsoft closed two zero-day vulnerabilities and released a fix for a new exploit for Intel processors on August Patch Tuesday.

Microsoft released an advisory (ADV-180018) on the latest speculative execution side channel vulnerability in Intel Core and Xeon processors called L1 Terminal Fault. Dubbed Foreshadow by security researchers, the vulnerability lets an attacker read data as it passes between a host and a virtual machine and a hypervisor.

The earlier Spectre and Meltdown variants allowed process-to-process interactions, but this latest hardware exploit allows a guest system to retrieve data from another guest system, said Brian Secrist, content manager at Ivanti, based in South Jordan, Utah.  

Once again, we have a bunch of hoops to jump through to get to full remediation… 2018 is keeping us real busy.
Brian Secristcontent manager, Ivanti

Full protection from Foreshadow (CVE-2018-3615, CVE-2018-3620 and CVE-2018-3646) on Windows requires a registry change, Microsoft patch and Intel firmware update to close the vulnerability.

“Once again, we have a bunch of hoops to jump through to get to full remediation,” Secrist said. “2018 is keeping us real busy.”

Microsoft addresses two zero-day exploits

Microsoft also closed a pair of zero-day remote code execution vulnerabilities. The first (CVE-2018-8373), in the Microsoft Scripting Engine with known exploits that affect all versions of Internet Explorer, allows an attacker to run arbitrary code on unpatched machines in the context of users who visit a specially crafted website. Depending on the user’s rights, the attacker could install programs or view and delete data. The patch changes how the scripting engine handles objects in memory. This CVE is critical for Windows desktop systems and important for server versions.

Rated important, the second zero-day (CVE-2018-8414) uses a Windows Shell bug in Windows 10 and Windows Server SAC Server Core for remote-code execution attacks. This vulnerability requires the user to run a malicious file either from email or a web site, after which an attacker can run code at the privilege level of the current user. The patch makes Windows Shell validate file paths properly.

August Patch Tuesday closes more than 60 vulnerabilities

More than half of the 60 vulnerabilities disclosed in August Patch Tuesday affect browsers or the scripting engine. Administrators should prioritize patching workstations and servers for a critical remote code execution vulnerability (CVE-2018-8345) that triggers when viewed by a user. Microsoft resolved this exploit by correcting the processing of shortcut .LNK references.

“Because the user doesn’t have to click on the malicious .LNK file to actually exploit the vulnerability, compared to browser vulnerability, it’s more likely for a server admin to be browsing through files. If they see this shortcut and the system renders it, then that’s when the exploit runs,” said Jimmy Graham, director of product management at Qualys, based in Foster City, Calif.

Jimmy Graham, QualysJimmy Graham, Qualys

Almost every major third-party vendor released patches and updates between the July and August Patch Tuesday, said Secrist. Adobe released four updates, including fixes for Adobe Flash and Acrobat. Google Chrome released version 68, and Firefox released updates for Thunderbird.

“We haven’t seen any increase in attacks or anything, just an example of better research and better coverage of vulnerabilities,” Secrist said.

July Patch Tuesday issues anger IT workers

After the July Patch Tuesday releases, Microsoft warned customers of potential SQL Server startup problems on Windows desktop (7 and 8.1) and server (2008 R2 and 2012 R2) versions on July 26. The company released several hotfixes and recommended uninstalling the July patches. Such rollbacks of faulty Microsoft updates have become a recurring headache for administrators.

Microsoft security updates for July also caused problems for the .NET Framework. On July 16, Microsoft posted a blog that “encouraged” Exchange customers to delay applying the July 10 updates to avoid disruptions with mail delivery. Hotfixes for affected systems — all supported versions of Windows Server — did not arrive until July 17. Up until that point, the only remedy was to uninstall the .NET Framework 4.7.2 update.

“Clearly there is a quality assurance issue of some kind,” Secrist said. “There’s another .NET release this month. Hopefully they spend more time on this one. We always strongly recommend you run [patches] through a test group and make sure they are stable before you push them out.”

Jeff Guillet, CEO of EXPTA Consulting in Pacifica, Calif., reached out to the Exchange product group for more information when the disruptions first occurred and said it was a two-fold problem of “really bad patches and bad communication.”

“Nobody even acknowledged that there was a problem and then all of a sudden they said, ‘Oh, by the way, we fixed this.’ [Administrators] had to troubleshoot it themselves because there was no communication from Microsoft saying this was a problem,” said Guillet.

While the intent of Patch Tuesday is to protect systems from vulnerabilities, the recent spate of patching issues concerns some IT administrators.

“Everybody’s kind of come to terms with [monthly patching], but the expectation was that a patch isn’t going to break stuff,” said Guillet. “So if it’s going to start breaking things, now I need to worry about testing it and I don’t have time because the next patches are coming up next Tuesday.”

Critical Cisco vulnerabilities patched in Policy Suite

Cisco disclosed and patched a handful of critical and high-severity vulnerabilities in its products this week.

The company fixed four critical vulnerabilities in its Policy Suite: Two are flaws that enabled remote unauthenticated access to the Policy Builder interface; one flaw is in the Open Systems Gateway initiative (OSGi) interface; and the last is in the Cluster Manager.

A successful exploit of one of the critical Cisco vulnerabilities in Policy Builder — tracked as CVE-2018-0374 — gave attackers access to the database and the ability to change any data in that database. The other vulnerability in the Policy Builder interface — tracked as CVE-2018-0376 — could have enabled an attacker to change existing repositories and create new repositories through the interface.

The third critical vulnerability could have enabled an attacker to directly connect to the OSGi interface remotely and without authentication. Once exploited, an attacker could have accessed or changed any files accessible by the OSGi process.

The last of the critical Cisco vulnerabilities — CVE-2018-0375 — was in the Cluster Manager of Cisco Policy Suite. With this flaw, an attacker could have logged in to remotely use the root account, which has static default credentials, and execute arbitrary commands.

The Cisco Policy Suite manages policies and subscriber data for service providers by connecting to network routers and packet data gateways.

The Cisco vulnerabilities affected Policy Suite releases prior to 18.2.0. The Cisco Product Security Incident Response team has already patched the vulnerabilities and has not seen any exploits in the wild.

Cisco also disclosed and patched seven high-severity flaws in its software-defined WAN (SD-WAN) products, though only one of them can be exploited remotely and without authentication — unlike the four critical vulnerabilities. One vulnerability requires authentication and local access to successfully exploit, but the others only needed authentication to be successfully exploited.

The SD-WAN vulnerabilities gave attackers the ability to overwrite arbitrary files on the operating system and execute arbitrary commands. One was a zero-touch denial-of-service vulnerability, and there were four command injection vulnerabilities.

The company also patched a high-severity denial-of-service vulnerability in the Cisco Nexus 9000 Series Fabric Switches, as well as 16 other medium-severity issues in a variety of its other products.

In other news:

  • Venmo, the mobile payment app owned by PayPal, has its API set to public by default and is exposing user data. According to researcher Hang Do Thi Duc, if a Venmo user accepts the default settings on their account, their transaction details are publicly accessible through the API. “It’s incredibly easy to see what people are buying, who they’re sending money to, and why,” Do Thi Duc said in a blog post. She noted that she was able to gather data on cannabis retailers, lovers’ quarrels and the unhealthy eating habits of users — along with their identifying information. Do Thi Duc was able to gather all of this and more by perusing the public Venmo API and looking specifically at the 207,984,218 transactions left accessible to the public in 2017. “I think it’s problematic that there is a public feed which includes real names, their profile links (to access past transactions), possibly their Facebook IDs and essentially their network of friends they spend time with,” she wrote. “And all of this is so easy to access! I believe this could be designed better.”
  • Multinational telecommunications company Telefonica suffered a data breach that exposed the data of millions of customers. Spanish users of Telefonica’s Movistar telecommunication services may have had their personal and financial information exposed because of the breach, including phone numbers, full names, national ID numbers, addresses, banking information, and call and data records. The breach was discovered after a Movistar user reported it to FACUA, a Spanish consumer rights nonprofit. Because of a design flaw in the Movistar online portal, anyone with a Movistar account could access other users’ data. FACUA notified Telefonica of the breach, and the company responded the next day, at which point FACUA made a public disclosure.
  • Oracle’s July Critical Patch Update (CPU) patched 334 security vulnerabilities, including 61 critical flaws, across many of its products. The most vulnerable affected product is the Oracle Financial Services application, which has 56 vulnerabilities — 21 of which can be exploited over the network without authentication. The vulnerabilities with the highest severity ratings — with a CVSS score of 9.8 — are in Oracle’s Financial Services, Fusion Middleware, PeopleSoft, E-Business Suite, retail applications and others. Over 200 vulnerabilities noted in the Oracle CPU affected business-critical applications. This month’s CPU has the highest number of patches at 334; the runner-up was 308 patches in July 2017.

Microsoft launches identity bounty program, offers up to $100,000

Microsoft this week expanded its bug bounty program to include security vulnerabilities in its identity services.

The software giant launched the Microsoft Identity Bounty Program, which offers payouts between $500 and $100,000 for vulnerabilities reported in Microsoft’s identity services. The scope of the identity bounty includes both consumer and enterprise services — Microsoft Accounts and Azure Active Directory, respectively — as well as login tools such as login.live.com, account.windowsazure.com, portal.office.com and the Microsoft Authenticator for iOS and Android applications.

In addition, Microsoft said the identity bounty will be available for bugs reported in the company’s implementations of specific OpenID standards.

“If you are a security researcher and have discovered a security vulnerability in the Identity services, we appreciate your help in disclosing it to us privately and giving us an opportunity to fix it before publishing technical details,” wrote Phillip Misner, principal security group manager for the Microsoft Security Response Center, in a blog post. “Further in our commitment to the industry identity standards work that we have worked hard with the community to define, we are extending our bounty to cover those certified implementations of select OpenID standards.”

The expanded bug bounty program will pay up to $100,000 for the most serious vulnerabilities, including design vulnerabilities in identity standards and bypasses for multifactor authentication. Standards-based implementation flaws will pay a maximum of $75,000, while “significant” authentication bypasses will pay a maximum of $40,000.

The identity bounty program is the latest expansion of Microsoft’s bug bounty efforts. In 2015, the company announced a major expansion of its bug bounty program that included Microsoft’s Azure platform as well as specific vulnerabilities for its Hyper-V virtualization software.