Tag Archives: vulnerabilities

July Patch Tuesday brings three public disclosures

Microsoft announced three public disclosures from the 54 vulnerabilities released in the July Patch Tuesday.

An elevation of privilege public disclosure (CVE-2018-8313) affects all OSes except Windows 7. Attackers could impersonate processes, cross-process communication or interrupt system functionality to elevate their privilege levels. The patch addresses this issue by ensuring that the Windows kernel API enforces permissions.

“The fact that there is some level of detailed description of how to take advantage of this out in the open, it’s a good chance an attacker will look to develop some exploit code around this,” said Chris Goettl, director of product management and security at Ivanti, based in South Jordan, Utah.

A similar elevation-of-privilege vulnerability (CVE-2018-8314) this July Patch Tuesday affects all OSes except Windows Server 2016. Attackers could escape a sandbox to elevate their privileges when Windows fails a check. If this vulnerability were exploited in conjunction with another vulnerability, the attacker could run arbitrary code. The update fixes how Windows’ file picker handles paths.

A spoofing vulnerability in the Microsoft Edge browser (CVE-2018-8278) tricks users into thinking they are on a legitimate website. The attacker could then extract additional code to remotely exploit the system. The patch fixes how Microsoft Edge handles HTML content.

“That type of enticing of a user, we know works,” Goettl said. “It’s not a matter of will they get someone to do it or not; it’s a matter of statistically you only need to entice so many people before somebody will do it.”

Out-of-band updates continue

Chris Goettl of IvantiChris Goettl

Before July Patch Tuesday, Microsoft announced a new side-channel attack called Lazy FP State Restore (CVE-2018-3665) — similar to the Spectre and Meltdown vulnerabilities — on supported versions of Windows. An attacker uses a different side-channel to pull information from other registers on Intel CPUs through speculative execution.

Jimmy Graham of QualysJimmy Graham

Microsoft also updated its Spectre and Meltdown advisory (ADV180012). It does not contain any new releases on the original three variants, but the company did update the Speculative Store Bypass, Variant 4 of the Spectre and Meltdown vulnerabilities. This completed coverage for Intel processors, and Microsoft is still working with AMD to mitigate its processors.

Microsoft released out-of-band patches between June and July Patch Tuesday for a third-party Oracle Outside In vulnerability (ADV180010) that affects all Exchange servers.

“We don’t have a lot of info on the exploitability,” said Jimmy Graham, director of product management at Qualys, based in Foster City, Calif. “It should be treated as critical for Exchange servers.”

New Windows Server 2008 R2 servicing model on its way

Alongside its June Patch Tuesday, Microsoft announced plans to switch the updating system for Windows Server 2008 SP2 to a rollup model. The new monthly model will more closely match the servicing model used for older Windows versions, enabling administrators to simplify their servicing process. This will include a security-only quality update, a security monthly quality rollup and a preview of the monthly quality rollup.

“The 2008 Server users out there now need to adopt the same strategy, where they had the luxury of being able to do one or two updates if they chose to and not the rest,” Goettl said.

The new model will preview on Aug. 21, 2018. Administrators will still receive extended support for Windows Server 2008 SP2 until January 2020. After that, only companies that pay for Premium Assurance will have an additional six years of support.

For more information about the remaining security bulletins for July Patch Tuesday, visit Microsoft’s Security Update Guide.

WebAssembly updates may cancel out Meltdown and Spectre fixes

Impending WebAssembly updates may render mitigations for the Meltdown and Spectre vulnerabilities ineffective.

According to John Bergbom, Forcepoint Security Labs’ senior security researcher, once the WebAssembly updates go through the mitigations for Meltdown and Spectre that were put in place by web browsers will no longer work.

The WebAssembly, or Wasm, standard was released in March 2017 and is a compact binary language meant to improve the speed of delivery and performance of JavaScript code. Currently, all major browsers — including Chrome, Edge, Firefox and Safari — support WebAssembly. One of the benefits of WebAssembly is that programs written in languages such as C and C++ can be compiled into it and run inside the browser.

An unintended consequence of WebAssembly is that there are some potential abuses of the standard. One of these, according to Forcepoint, is the exploitation of hardware bugs, including the CPU vulnerabilities Meltdown and Spectre, which were discovered in January 2018.

“This family of CPU vulnerabilities was mitigated in browsers by lowering the precision of timers in JavaScript,” Bergbom explained in a blog post. “However, once Wasm gets support for threads with shared memory (which is already on the Wasm roadmap) very accurate timers can be created. That may render browser mitigations of certain CPU side channel attacks non-working.”

Meltdown and Spectre have been wreaking havoc on processors from Intel, AMD and ARM since early this year. Both exploit vulnerabilities in CPUs to steal sensitive data stored in memory. After these vulnerabilities were disclosed, most major vendors released patches.

Researchers previously proved that attackers could exploit Meltdown and Spectre remotely using JavaScript code that runs in browsers. In response, the major browsers released updates that affected the accuracy of the attack codes. The WebAssembly updates will effectively negate those browser mitigations.

“Like with many new technologies there are potential security issues which need to be considered,” Bergbom wrote. “Collectively, these present new opportunities for malicious actors. Much as with JavaScript, the possibilities with [WebAssembly] are — if not quite endless — very broad.”

In other news

  • U.S. cybersecurity company FireEye has denied claims that it hacked a Chinese nation-state cyberespionage group. The claims about FireEye spread over social media last week after a book by The New York Times national security journalist, David Sanger, was published. In the book, The Perfect Weapon: War, Sabotage, and Fear in the Cyber Age, Sanger said that FireEye’s 2013 report “APT1, Exposing One of China’s Cyber Espionage Units” was so detailed about the activities of Chinese hackers because FireEye, then Mandiant, obtained the information through hacking back — which is illegal in the U.S. FireEye has since released a statement denying any hacking back efforts. “Mr. Sanger’s description of how Mandiant obtained some of the evidence underlying APT1 has resulted in a serious mischaracterization of our investigative efforts,” FireEye wrote. “To state this unequivocally, Mandiant did not employ ‘hack back’ techniques as part of our investigation of APT1, does not ‘hack back’ in our incident response practice, and does not endorse the practice of ‘hacking back.'”
  • Reality Winner, the former National Security Agency contractor who admitted to leaking classified information as part of a plea deal this week, was previously a linguist with the Air Force and, while working as an NSA contractor, shared a classified report about alleged Russian interference in the 2016 U.S. election with the news outlet The Intercept. Winner, now 26 years old, was arrested in June 2017 and has been in jail since. The plea agreement she reached with federal prosecutors will give her 63 months in prison in exchange for her pleading guilty to one felony count under the Espionage Act. “All of my actions I did willfully, meaning I did so of my own free will,” Winner said in court this week, according to The New York Times. After Winner sent the classified documents to The Intercept, the news outlet published the report, which described two cyberattacks by the Russian government on U.S. elections.
  • Sophos SafeGuard security software is vulnerable to seven privilege escalation flaws. SafeGuard Enterprise Client, SafeGuard Easy and SafeGuard LAN Crypt client are all vulnerable to a flaw disclosed by security researcher Kyriakos Economou from Nettitude, a cybersecurity company headquartered in New York City. “Exploitation of those vulnerabilities requires running malicious code on the target machine and can result in privilege escalation,” the alert from Sophos said, noting that the vulnerability is at least not remotely exploitable. Some of the flaw could also enable an attacker to create an input/output control and modify token privileges. Then the attacker could run commands with system privileges on any computer running Windows and Sophos SafeGuard. Economou first discovered the vulnerabilities in December 2017, notified Sophos in January 2018, and the fix was complete in April.

Spectre v4 fix and Windows DNS patch in June Patch Tuesday

The June 2018 Patch Tuesday release addressed a total of 51 vulnerabilities, 11 of which were deemed critical, but the headline fix was a Windows DNS patch.

Experts uniformly pointed to the Windows DNS patch (CVE-2018-8225) as the most interesting fix of the month and the one that should take priority for most enterprises. Microsoft described the Windows DNS patch as addressing a remote code execution (RCE) vulnerability that affects Windows desktop versions 7 through 10 and Windows Server 2008 and newer.

Microsoft wrote in the advisory for the Windows DNS patch that if an attacker used a malicious DNS server to send corrupted DNS responses to the target, the exploit could allow for running arbitrary code in the context of the local user permissions.

Craig Young, security researcher for Tripwire’s Vulnerability and Exposure Research Team, said the full impact of the Windows DNS vulnerability “is not entirely clear.”

“Microsoft describes it as a problem processing DNS responses. Normally, I would expect that to mean that the attacker must be in a position to respond to DNS requests from a victim. This would mean that the victim is either making a DNS request to a server the attacker controls or that the attacker has a privileged network position allowing them to spoof responses from a legitimate server,” Young wrote via email. “In this case, however, Microsoft’s CVSS v3 score indicates that there is no user interaction required to trigger the vulnerability. It could be that Microsoft did not score the vulnerability properly, but it could also mean that there are circumstances where a vulnerable system will process unsolicited responses.”

Jimmy Graham, director of product management at Qualys Inc., based in Redwood City, Calif., added in a blog post that “mobile workstations that may connect to untrusted Wi-Fi are at high risk” and the Windows DNS patch should be a priority for those users.

Spectre v4 gets OS fixes

Beyond the Windows DNS patch, another highlight of the June Patch Tuesday was an update to Microsoft’s advisory regarding Spectre v4 — the latest Spectre attack method discovered in May 2018.

According to Microsoft’s updated advisory, Windows now supports Speculative Store Bypass Disable (SSBD) in Intel processors, but this in itself will not protect against Spectre v4 and will require microcode patches from Intel to fully remediate.

Microsoft couldn’t provide a timetable for when those microcode updates would be available, but it did warn users that “in testing Microsoft has seen some performance impact when SSBD is turned on. However, the actual performance impact will depend on multiple factors, such as the specific chipset in your physical host and the workloads that are running.”

Another flaw to watch

The final critical flaw for enterprises to prioritize was CVE-2018-8267, a scripting engine memory corruption vulnerability in Internet Explorer. This patch should take priority because although there have not been any attacks seen in the wild, this flaw was publicly disclosed.

According to Microsoft, this RCE vulnerability could allow an attacker to run code in the context of the current user either by luring a target to a malicious website or by embedding a malicious ActiveX control in a Microsoft Office document.

Meltdown and Spectre malware discovered in the wild

Chip makers have said they’ve seen no evidence the Meltdown and Spectre vulnerabilities have been exploited to steal customer data, but those days of relative comfort may be coming to an end.

Researchers at AV-TEST, an independent organization that tests antimalware and security software, announced this week they had discovered 139 samples of malware that “appear to be related to recently reported CPU vulnerabilities.” While the good news is that most of the malware samples appear to be based on previously published proof-of-concepts from security researchers, the bad news is that AV-TEST’s latest findings show the number of unique samples has risen sharply in recent weeks.  

The organization had previously reported the discovery of 77 unique samples of Meltdown and Spectre malware on January 17. At that time, AV-TEST said via Twitter that all identified samples were “original or modified PoC code” and that the majority of the samples were for Spectre rather than Meltdown. AV-TEST posted another update on Jan. 23 showing the unique malware samples had risen to 119.

After analyzing most of those samples, Fortinet’s FortiGuard Labs published a report Tuesday saying it was “concerned” about the potential of Meltdown and Spectre malware attacking users and enterprises.

“FortiGuard Labs has analyzed all of the publicly available samples, representing about 83 percent of all the samples that have been collected [by AV-TEST], and determined that they were all based on proof of concept code,” the research team wrote. “The other 17 percent may have not been shared publicly because they were either under NDA or were unavailable for reasons unknown to us.”

Fortinet also released several antivirus signatures to help users defend against the Meltdown and Spectre malware samples. But detecting other exploits related to these chip vulnerabilities could prove extremely difficult. While Intel and AMD have said there is no evidence the flaws have been exploited in the wild, the researchers who discovered the chip vulnerabilities say it’s “probably not” possible for organizations or users to tell whether Meltdown and Spectre have been used against them.

“The exploitation does not leave any traces in traditional log files,” according to an FAQ on the Meltdown and Spectre research site.

Defending against possible Meltdown and Spectre malware has been further complicated by patch issues. Intel recently announced it was pulling its microcode updates for the chip vulnerabilities because of reboot problems on systems running Intel’s Broadwell and Haswell processors. Microsoft later issued an out-of-band patch that disabled Intel’s update for variant 2 of the Spectre vulnerability, which involves branch target injection.

The Actual Performance Impact of Spectre/Meltdown Hyper-V Updates

The Spectre and Meltdown vulnerabilities have brought a fair amount of panic and havoc to the IT industry, and for good reason. Hardware manufacturers and operating system authors have been issuing microcode updates and patches in a hurry. As administrators, we need to concern ourselves with three things: the risks of running unpatched systems, the performance hit from patching, and quality control problems with the patches. If you’re skimming, then please pay attention to the section on ensuring that you get the update — not everyone will automatically receive the patches. Below I’ll run down what you need to know to ensure you’re protected plus a benchmark analysis of the performance impact of the recently released update patches.

What are Spectre and Meltdown?

Both Spectre and Meltdown are hardware attacks. Your operating system or hypervisor choice does not affect your vulnerability. It might affect fix availability.

Spectre is a category of assault that exploits a CPU’s “branch prediction” optimizations. A CPU looks at an instruction series that contains a decision point (if condition x then continue along path a, else jump to b) and guesses in advance whether it will follow the “else” code branch or continue along without deviation. The Wikipedia article that I linked contains further links to more details for those interested. Because the Spectre vulnerability encompasses multiple attack vectors, the predictor has more than one vulnerability. All of the ones that I’m aware of involve fooling the CPU into retrieving data from a memory location other than the code’s intended target. Spectre affects almost every computing device in existence. Fixes will affect CPU performance out of necessity.

Meltdown affects Intel and some ARM processors. AMD processors appear to be immune (AMD claims immunity; I do not know of any verified tests with contrary results). As with Spectre, Meltdown exploits target the CPU’s optimization capabilities. You can read the linked Wikipedia article for more information. For a less technical description, Luke posted a great analogy on our MSP blog. Whether you read more or not, you should assume that any running process can read the memory of any other running process. The fix for this problem also includes a performance hit. That hit is potentially worse than Spectre’s — an estimated 5 percent to as much as 30 percent. I’ll revisit that later.

What are the Risks of Running without Patches?

Properly addressing Spectre and Meltdown will require more administrative effort than most other problems. Admins in large and complex environments will need to plan deployments. With unpredictable performance impacts, some will want to wait as long as possible before doing anything. The more avoidant of us will want to just ignore it as much as possible and hope that it just sorts itself out. Eventually, we’ll all have new chips, new operating systems, and redesigned applications that won’t be susceptible to these problems. That won’t be ubiquitous for some time, though. We need more immediate solutions.

In one sense, an unpatched system will be fairly easy to assault. Attacks can be carried out via simple Javascript. Unprivileged user code can access privileged kernel memory. The processor cache is an open book for many of these vulnerabilities. It looks to me as though some attack vectors could be used to read essentially any location in memory, although some other accounts dispute that. These are hardware problems, so in the hypervisor world, they transcend the normal boundaries between virtual machines as well as the management operating system. These threats are serious.

However, they cannot be exploited remotely. Attacking code must be executed directly on the target system. That separates the Spectre and Meltdown vulnerabilities from other nefarious vectors, such as Heartbleed. Furthermore, Spectre-class attacks are a bit of a gamble from the attacker’s side. Even if they could read any location in memory, it will be mostly without context. So, something may look like a password, but a password to what? The clues might be alongside the password or they might not.

So, the risk to your systems is extremely high, but the effort-to-reward ratio for an attacker is also high. I do know of one concern: LSASS keeps the passwords for all logged-on users in memory, in clear text. You should assume that a successful Spectre or Meltdown attack might be able to access those passwords. Also, attacks can come from Javascript in compromised websites. You shouldn’t be browsing from a server at all, so that could help. But what about remote desktop sessions? Do you keep those users off of the general Internet? If not, then any of them could unwittingly risk everyone else on the same host.

I cannot outline your risk profile for you, but I would counsel you to work from the assumption that a compromise of an unpatched system is inevitable.

Should I Patch My Hyper-V Hosts, Guests, or Both?

One of my primary research goals was to determine the effects of only applying OS patches, only applying firmware updates, and doing both. I did not find full, definitive answers. However, it does appear that some kernel protections only require OS updates. Others indicated that they would require firmware updates, but they did not make it clear whether or not a firmware update alone would address the problem or if a combination of firmware and OS updates were necessary. However, there is no question that the best protection only comes from updating your hardware and software.

Also, the guests’ kernels must be made aware of the changes to the physical layer in order to fully utilize their mitigation techniques, which can only be done if both the host and the guest are updated.

Therefore, for the fullest protection, you must:

  • Patch the host
  • Perform host configuration changes
  • Update the firmware on the host
  • Patch the guests
  • Cold boot the guests

Also, be aware that “host” means any Hyper-V host. Windows Server, Hyper-V Server, or desktop Windows — patch them all.

We’ll go over the how-to in a bit. Let’s knock out some other questions first.

What Happens if a Hyper-V VM Updates Before Its Host?

Well, the host isn’t patched, so that’s a problem. Aside from that, nothing bad will happen (generally speaking — outliers always exist). But the guest will not be aware of the changed capabilities of the host if it is not cold booted after the host is updated. Until all of the above has been done, the guest will not have the fullest protection.

What If No BIOS Update is Available?

If your hardware does not have an available update, then you still need to apply all software patches. That will mitigate several kernel attacks.

If you are running Windows/Hyper-V Server 2012 R2 or earlier as your management operating system, I’m sad to say that you cannot do much else. Practice defense-in-depth: if no attacker can access your systems, then they cannot execute an attack. Remember that the patches are still applicable and will help — but don’t lose sight of the hardware-based nature of the problems. If possible, upgrade to 2016.

For 2016, you can restrict which processors and cores that the management operating system and guests use. That helps to confine attacks. The relevant features are not well-documented. I had planned on performing some research and writing an article on them, but none of that has happened yet. In the meantime, you can read Microsoft’s article on using these features to mitigate Meltdown and Spectre attacks on systems that do not have an available hardware update. It contains links to instructions on using those features.

What About Non-OS Software?

Software plays an enormous role in all of this. Application developers can take precautions to protect their cached information. Interpreters and compilers can implement their own mitigations. The January updates included patches for IE and Edge to help block Spectre and Meltdown attacks via their Javascript interpreter. Microsoft has released an update to their C++ compiler that will help prevent Spectre attacks.

Expect your software vendors to be releasing updates. Remember that the nature of the attacks means that otherwise benign software can now be an attack vector.

Quality Control Problems with Spectre and Meltdown Patches

I am aware of three problems in the deployment pipeline for the Spectre and Meltdown fixes from Microsoft.

  1. Older AMD processors (Athlon series) reacted very badly to the initial patch group that contained the Spectre and Meltdown fix. In response, Microsoft stopped offering them while working on a fix. I have a Turion x2 system with Hyper-V that was offered the patch after that, so I believe that Microsoft has now issued a new fix.
  2. Many antivirus applications caused blue screen errors after the fixes were applied. To prevent that, Microsoft implemented a technique that will ensure that no system will receive the update until it has been deliberately flagged as being ready. Pay special attention, as that affects every system!
  3. Some systems simply will not take the update. I wish that I could give you some solid guidance on what to do. I do not know of any tips or tricks particular to these patches. I had one installation problem that I was able to rectify by disabling the “Give me updates for other Microsoft products when I update Windows” option. However, that particular system seemed to have problems of its own apart from the patches, so I cannot say for certain if it was anything special with this patch. You may need to open a ticket with Microsoft support.

How to Ensure that You Receive Microsoft’s Spectre and Meltdown Patches

These patches were deployed in the January 2018 security patch bundle. My system showed it as “2018-01 Security Monthly Rollup for OS Name” with a follow-up Quality Rollup. That deployment vehicle might lead you to believe that just running Windows Update will fix everything. However, that’s not necessarily the case. In order to avoid blue screens caused by incompatible antivirus applications, the updater looks for a particular registry key. If it doesn’t exist, then the updater assumes that the local antivirus is not prepared and will decline to offer the update. Since Microsoft now issues security patches in cumulative roll-up packages, it will decline every subsequent security update as well.

If Your System Runs Antivirus

In this case, “system” means host or guest. If you run an antivirus application, it is up to the antivirus program to update the registry key once it has received an update known to be compatible with the Spectre/Meltdown fixes. If you have an antivirus package and the updater will not offer the January 2018 security pack, contact your antivirus vendor. Do not attempt to force the update. Switch antivirus vendors if you must. Your antivirus situation needs to be squared away before you can move forward.

If Your System Does Not Run Antivirus

Personally, I prefer to run antivirus on my Hyper-V host. I recommend that everyone else run antivirus on their Hyper-V hosts. I’m aware that this is a debate topic and I’m aware of the counter-arguments. I’ll save that for another day.

If you do not run antivirus on your Hyper-V host (or any Windows system), then you will never receive the January 2018 security roll-up or any security roll-up thereafter without taking manual action. Microsoft has left the task of updating the related registry key to the antivirus vendors. No antivirus, no registry update. No registry update, no security patches.

In your system’s registry, navigate to HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersion. If it doesn’t already exist, create a new key named “QualityCompat”. Inside that key, create a new DWORD key-value pair named “cadca5fe-87d3-4b96-b7fb-a231484277cc”. Leave it at its default value of 0x0. You do not need to reboot. The updates will be offered on the next run of Windows Update (pursuant to any applicable group policy/WSUS approvals).

For more information, you can read Microsoft’s official documentation: https://support.microsoft.com/en-us/help/4072699/january-3-2018-windows-security-updates-and-antivirus-software.

How to Apply, Configure, and Verify the Spectre and Meltdown Fixes for Hyper-V and Windows

Microsoft has already published solid walk-throughs:

Things to absolutely not miss in all of that:

  • Without the post-install registry changes, your Hyper-V hosts will not have the strongest protection
  • Depending on your hypervisor and guest configurations, one of the additional registry settings may be necessary in order to
  • Each virtual machine must be COLD-booted after the host has been updated! A simple restart of the guest OS will not be sufficient.
  • Live Migrations between patched/unpatched hosts will likely fail. Keep this in mind when you’re attempting to update clusters.

The Performance Impact of the Spectre and Meltdown Patches on a Hyper-V Host

We’ve all seen the estimations that the Meltdown patch might affect performance in the range of 5 to 30 percent. What we haven’t seen is a reliable data set indicating what happens in a real-world environment. The patches are too new for us to have any meaningful levels of historical data to show. I can tell you that my usage trends are not showing any increase, but that is anecdotal information at best. I also know of another installation (using a radically different hardware, hypervisor, and software set) that has experienced crippling slowdowns.

So, for the time being, we’re going to need to take some benchmarks. For anyone who missed the not-so-subtle point: performance bottlenecks found by benchmarks do not automatically translate to performance bottlenecks in production.

Impact on Storage

From what I’ve seen so far, these patches have the greatest detriment on storage performance. Since storage already tends to be the slowest part of our systems, it makes sense that we’d find the greatest impact there.

First up is Storage Space Direct. Ben Thomas has already provided some benchmarks that show a marked slow down. Pay close attention to the differences, as they are substantial. However, most of us would be more than happy with the “slow” number of 1.3 million IOPS. Those numbers are difficult to read in comparison with builds that would be normative in a small or medium-sized business.

I also found an article detailing the storage performance impact on an Ubuntu system using ZFS in a VMware client. This helps reinforce the point that these problems are not caused by or related to your choice of hypervisor or operating system.

I don’t have an S2D environment of my own to do any comparison. However, I will perform some storage benchmarking on a standard Hyper-V build with local storage and remote Storage Spaces (not S2D) storage.

Performance Benchmarks

I ran a number of performance checks to try to help predict the impact of these updates.

The Build Environment and Methodology

I used the build outlined in our eBook on building a Hyper-V cluster for under $2500. To save you a click, the CPUs are Intel Xeon E3-1225 (Sandy Bridge). We should expect to see some of the more “significant” impacts that Microsoft and Intel warn about.

The tests were performed on one of the compute nodes. Some of the storage tests involved the storage system.

The host runs Windows Server 2016. It has multiple guests with multiple operating systems. I chose three representatives: 1 Windows 2012 R2, 1 Windows 10, and 1 Windows Server 2016. All run GUI Windows because Passmark won’t generate a full CPU report under Core.

None of these systems have the patch yet.

I took the following steps:

  1. Collected CPU and storage benchmarks from the host, a Windows 10 guest, the WS2012R2 guest, and the WS2016 guest. Tests were run separately.
  2. Ran a CPU stress utility on some guests while testing others.
  3. Ran a storage stress utility on some guests while testing others.
  4. I applied available firmware updates to the host and the OS patch to the management OS and all guests.
  5. Repeated steps 1-3 for comparison purposes.

I used these tools:

Testing Phase 1: The Pre-Patch Raw Results

To begin, I ran benchmarks against the host and some of the guests separately. This establishes a baseline.

Pre-Patch CPU Benchmark
Host Windows 10 Guest 2012 R2 Guest 2016 Guest
CPU Mark 7404 4198 4055 4197
Integer Math 8226 4209 4077 4212
Prime Numbers 33 24 21 24
Compression 8208 4084 4028 4103
Physics 492 303 295 315
CPU Single Threaded 1905 1882 1847 1886
Floating Point Math 7371 3738 3646 3522
Extended Instructions (SSE) 283 144 138 131
Encryption 1260 632 592 631
Sorting 5165 2590 2541 2608
Pre-Patch Disk Benchmark
Host (internal) Windows 10 Guest (Remote SS) 2012 R2 Guest (internal) 2016 Guest (Remote SS)
Disk Mark 416 505 355 629
Disk Sequential Read 55 124 44 153
Disk Random Seek +RW 6 4 6 4
Disk Sequential Write 53 11 47 15

Phase 1 Analysis

The primary purpose of phase 1 was to establish a performance baseline. The numbers themselves mean: “the systems can do this when not under load”.

The host has four physical cores. Each virtual machine has two vCPU. As expected, each VM’s CPU performance comes out to about half of the host’s metrics.

Testing Phase 2: Pre-Patch Under CPU Load

Next, I needed to have some idea of how a load affects performance. This system serves no real-world purpose, so I needed to fake a load.

Hyper-V is architected so that loads in the management operating system take priority over the guests (I didn’t always know that, in case you find something that I wrote to the contrary). Therefore, I didn’t feel that simulating a load in the management operating system would provide any value. It will drown out the guests and that’s that.

To test, I ran Prime95 on four virtual machines. I set the torture test to use small FFTs because we’re interested in CPU burn, not memory:

melt-prime95

For whatever reason. that only appeared to run the CPUs up to about 25% actual usage:

melt-CPUusage

The guests all believe that they’re burning full-bore, so this might be due to some optimizations. I thought the load would be higher, but we should not be overly surprised; hypervisors should do a decent job at managing their guests’ CPU usage. No matter what, this generates a load that the host distributed across all physical cores, so it works for what we’re trying to do.

While Prime95 ran in those four VMs, I tested each of the originals’ CPU and disk performance separately:

Pre-Patch CPU Benchmark during CPU Load
Host Windows 10 Guest 2012 R2 Guest 2016 Guest
CPU Mark not tested 1553 1339 1261
Integer Math not tested 1549 1356 1335
Prime Numbers not tested 7 5 5
Compression not tested 1570 1345 1308
Physics not tested 108 96 77
CPU Single Threaded not tested 753 646 564
Floating Point Math not tested 1385 1211 1109
Extended Instructions (SSE) not tested 52 45 44
Encryption not tested 232 205 201
Sorting not tested 985 841 817
Pre-Patch Disk Benchmark during CPU Load
Host (internal) Windows 10 Guest (Remote SS) 2012 R2 Guest (internal) 2016 Guest (Remote SS)
Disk Mark 416 349 385 481
Disk Sequential Read 55 90 51 111
Disk Random Seek +RW 6 3 6 4
Disk Sequential Write> 53 2 48 16

Testing Phase 3: Pre-Patch Under Disk Load

Phase 3 is like phase 2 except that we’re simulating heavy disk I/O load. It’s a little different though because the guests are spread out between local and remote storage.

I used DiskSpd.exe with the following command line:

That’s the default from the documentation with the exception of -d600 and #0. The -d600 sets the duration. I used a five-minute timeout so that I would have enough time to start the stress tool on all of the guests and run the CPU and disk benchmarks. The #0 selects a disk that the VMs have.

Pre-Patch CPU Benchmark during I/O Load
Host Windows 10 Guest 2012 R2 Guest 2016 Guest
CPU Mark not tested 3696 3814 3747
Integer Math not tested 3934 3927 3856
Prime Numbers not tested 13 18 16
Compression not tested 3715 3759 3838
Physics not tested 259 249 267
CPU Single Threaded not tested 1760 1852 1775
Floating Point Math not tested 3415 3476 3375
Extended Instructions (SSE) not tested 129 136 131
Encryption not tested 565 577 544
Sorting not tested 2399 2430 2375
Pre-Patch Disk Benchmark during I/O Load
Host (internal) Windows 10 Guest (Remote SS) 2012 R2 Guest (internal) 2016 Guest (Remote SS)
Disk Mark not tested 76 385 94
Disk Sequential Read not tested 12 57 17
Disk Random Seek +RW not tested 2 6 3
Disk Sequential Write> not tested 5 43 5

Testing Phase 4: Post-Patch Raw Results

Now we’re simply going to repeat the earlier processes on our newly-updated systems. Phase 4 aligns with Phase 1: a straight benchmark of the host and representative guests.

Post-Patch CPU Benchmark
Host Windows 10 Guest 2012 R2 Guest 2016 Guest
CPU Mark 7263 3989 3841 3705
Integer Math 8191 4052 3966 3827
Prime Numbers 34 21 17 18
Compression 8015 3890 3919 3336
Physics 489 303 301 273
CPU Single Threaded 1860 1712 1756 1747
Floating Point Math 7205 3464 3528 3281
Extended Instructions (SSE) 249 135 105 121
Encryption 1188 612 598 560
Sorting 5021 2469 2210 2448
Post-Patch Disk Benchmark
Host (internal) Windows 10 Guest (Remote SS) 2012 R2 Guest (internal) 2016 Guest (Remote SS)
Disk Mark 348 505 269 373
Disk Sequential Read 46 124 33 88
Disk Random Seek +RW 5 4 4 3
Disk Sequential Write> 44 11 36 10

Phase 4 Analysis

We don’t see that much CPU performance slowdown, but we do see some reduction in storage speeds.

Testing Phase 5: Post-Patch Under CPU Load

This test series compares against phase 2. Several VMs

Post-Patch CPU Benchmark during CPU Load
Host Windows 10 Guest 2012 R2 Guest 2016 Guest
CPU Mark not tested 1241 1267 1518
Integer Math not tested 1203 1288 1525
Prime Numbers not tested 5 5 7
Compression not tested 1280 1253 1480
Physics not tested 91 94 116
CPU Single Threaded not tested 603 620 700
Floating Point Math not tested 1087 1118 1325
Extended Instructions (SSE) not tested 43 44 45
Encryption not tested 192 192 239
Sorting not tested 811 802 941
Post-Patch Disk Benchmark during CPU Load
Host (internal) Windows 10 Guest (Remote SS) 2012 R2 Guest (internal) 2016 Guest (Remote SS)
Disk Mark 416 349 325 366
Disk Sequential Read 55 90 41 85
Disk Random Seek +RW 6 3 6 4
Disk Sequential Write> 53 2 42 12

Testing Phase 6: Post-Patch Under Disk Load

This is the post-patch equivalent of phase 3. We’ll test performance while simulating high disk I/O.

Again, I used DiskSpd.exe on several VMs with the following command line:

Post-Patch CPU Benchmark during I/O Load
Host Windows 10 Guest 2012 R2 Guest 2016 Guest
CPU Mark not tested 3152 3104 2920
Integer Math not tested 3192 3268 3106
Prime Numbers not tested 14 14 13
Compression not tested 3163 2654 2361
Physics not tested 215 219 211
CPU Single Threaded not tested 1667 1774 1614
Floating Point Math not tested 2678 2885 2672
Extended Instructions (SSE) not tested 105 95 100
Encryption not tested 476 452 449
Sorting not tested 2015 2086 1999
Post-Patch Disk Benchmark during I/O Load
Host (internal) Windows 10 Guest (Remote SS) 2012 R2 Guest (internal) 2016 Guest (Remote SS)
Disk Mark not tested 40 360 54
Disk Sequential Read not tested 5 50 7
Disk Random Seek +RW not tested 1 5 3
Disk Sequential Write not tested 3 44 4

Consolidated Charts

These charts reorganize the above data to align each result with its system rather than its condition.

Host CPU
Pre Post
CPU Mark 7404 7263
Integer Math 8226 8191
Prime Numbers 33 34
Compression 8208 8015
Physics 492 489
CPU Single Threaded 1905 1860
Floating Point Math 7371 7205
Extended Instructions (SSE) 283 249
Encryption 1260 1188
Sorting 5165 5021
Host Disk (Internal)
Pre Post
Disk Mark 416 348
Disk Sequential Read 55 46
Disk Random Seek +RW 6 5
Disk Sequential Write 53 44
Windows 10 Guest CPU
Pre Pre+CPU Pre+I/O Post Post+CPU Post+I/O
CPU Mark 4198 1553 3696 3989 1241 3152
Integer Math 4209 1549 3934 4052 1203 3192
Prime Numbers 24 7 13 21 5 14
Compression 4084 1570 3715 3890 1280 3163
Physics 303 108 259 303 91 215
CPU Single Threaded 1882 753 1760 1712 603 1667
Floating Point Math 3738 1385 3415 3464 1087 2678
Extended Instructions (SSE) 144 52 129 135 43 105
Encryption 632 232 565 612 192 476
Sorting 2590 985 2399 2469 811 2015
Windows 10 Guest Disk (Remote Storage Spaces)
Pre Pre+CPU Pre+I/O Post Post+CPU Post+I/O
Disk Mark 505 349 76 505 349 40
Disk Sequential Read 124 90 12 124 90 5
Disk Random Seek +RW 4 3 2 4 3 1
Disk Sequential Write 11 2 5 11 2 3
Windows 2012 R2 Guest CPU
Pre Pre+CPU Pre+I/O Post Post+CPU Post+I/O
CPU Mark 4055 1339 3814 3841 1267 3104
Integer Math 4077 1356 3927 3966 1288 3268
Prime Numbers 21 5 18 17 5 14
Compression 4028 1345 3759 3919 1253 2654
Physics 295 96 249 301 94 219
CPU Single Threaded 1847 646 1852 1756 620 1774
Floating Point Math 3646 1211 3476 3528 1118 2885
Extended Instructions (SSE) 138 45 136 105 44 95
Encryption 592 205 577 598 192 452
Sorting 2541 841 2430 2210 802 2086
Windows 2012 R2 Guest Disk (Internal)
Pre Pre+CPU Pre+I/O Post Post+CPU Post+I/O
Disk Mark 355 385 385 269 325 360
Disk Sequential Read 44 51 57 33 41 50
Disk Random Seek +RW 6 6 6 4 6 5
Disk Sequential Write 47 48 43 36 42 44
Windows 2016 Guest CPU
Pre Pre+CPU Pre+I/O Post Post+CPU Post+I/O
CPU Mark 4197 1261 3747 3705 1518 2920
Integer Math 4212 1335 3856 3827 1525 3106
Prime Numbers 24 5 16 18 7 13
Compression 4103 1308 3838 3336 1480 2361
Physics 315 77 267 273 116 211
CPU Single Threaded 1886 564 1775 1747 700 1614
Floating Point Math 3522 1109 3375 3281 1325 2672
Extended Instructions (SSE) 131 44 131 121 45 100
Encryption 631 201 544 560 239 449
Sorting 2608 817 2375 2448 941 1999
Windows 2016 Guest Disk (Remote Storage Spaces)
Pre Pre+CPU Pre+I/O Post Post+CPU Post+I/O
Disk Mark 629 481 94 373 366 54
Disk Sequential Read 153 111 17 88 85 7
Disk Random Seek +RW 4 4 3 3 4 3
Disk Sequential Write 15 16 5 10 12 4

Data Analysis

The analysis has a fairly simple conclusion: some CPU functions degraded noticeably, others did not, and not much changed for I/O. The Windows 2016 guest does have a wide disparity in its disk statistics. Based on the other outcomes, I suspect an environmental difference or that I made some error when running the traces more than I believe that the raw speed degraded by 50%.

Conclusion

What we learn from these charts is that the full range of updates causes CPU performance degradation for some functions but leaves others unaffected. Normal storage I/O does not suffer as much. I imagine that the higher impacts that you see in the Storages Spaces Direct benchmarks shared by Ben Thomas are because of their extremely high speed. Since most of us don’t have storage subsystems that can challenge a normal CPU, we aren’t affected as strongly.

Overall, I think that the results show what could be reasonably inferred without benchmarks: high utilization systems will see a greater impact. As far as the exact impact on your systems, that appears to largely depend on what CPU functions they require most. If your pre-patch conditions were not demanding high performance, I suspect that you’ll suffer very little. If you have higher demand workloads, I’d recommend that you try a test environment if possible. If not, see if your software vendors have any knowledge or strategies for keeping their applications running acceptably.

Tell Me Your Experiences

I’ve given a breakdown of the benchmarking from my set-up but I’m curious to know if others have experienced a similar performance impact from the patches. Furthermore, if you still have any lingering doubts about the whole issue I’m ready to answer any questions you have about Meltdown, Spectre or anything else related to these security vulnerabilities and their respective patches. Contact me through the comments section below!

Meltdown and Spectre fixes eyed for SQL Server performance issues

The headlines about Meltdown and Spectre microprocessor vulnerabilities have somewhat subsided, but the patching goes on in IT shops both big and small — creating possible SQL Server performance issues for Microsoft users.

Databases, including SQL Server, could be affected by the architectural flaws in chips widely reported at the start of the year. At risk are processors from Intel and others that use creative design to boost system performance.

As described by Google Project Zero, both Meltdown and Spectre access on-chip cache memory to create vulnerable side-channels of communication. Spectre can inject commands that divulge data. Meltdown, using simpler operations, can monitor data in memory.

In both cases, malicious code would exploit chip-level speculative code execution techniques — ones used in many types of systems, including relational databases.

Early indications are software patches that counter Meltdown can incur SQL Server performance issues. There are no signs of actual hacks yet, but database administrators (DBAs) have been advised to update server-side software. The patches may lead to processing overhead, however.

Problems are by no means limited to on-premises databases. Reports indicated some users of SQL Server cloud versions were first to feel the impact of Meltdown protection, when Microsoft Azure cloud patching activity caused brief blips in operations.

Patches and overhead

Spectre logo

When DBAs apply updates to guard against Meltdown and Spectre vulnerabilities, they will have to judge for themselves how performance overhead of patches may affect their workloads. Performance degradation covering a variety of database, virtual machine, operating system and hardware combinations has been cited in some user web blog entries.

But early estimates should be considered critically, according to Thomas LaRock, who serves as “head geek” at technology infrastructure management software provider SolarWinds, based in Austin, Texas. It is still early in terms of finding clarity when it comes to judging SQL Server performance issues that may be incurred by recent Microsoft patches to counter Meltdown.

“When you factor in the number of patches involved with Meltdown [and] Spectre, it is easy to understand why some people may be reporting a 30% performance hit. You could find hundreds of such claims on Reddit right now, many of them without any understanding of why such a performance hit might have been possible,” LaRock said.

Calling ‘Captain Edgecase’

Meltdown logo

Workloads, hardware, applications and code are among the variables that contribute to different performance measures. This is not to mention the human element.

“There is always one ‘Captain Edgecase’ in the crowd that wants everyone to know they found something different than anyone else,” LaRock mused.

While waiting for chipmakers to create their own patches for Meltdown and Spectre, IT pros will have to look to patch applications not just at the database level, but at the operating system and browser level, too.

La Rock said the basic message boils down to this: “Update all things.”

Meltdown and Spectre lesson: Assess patch risk

Still, it is important for everyone to be able to assess their risk properly before applying patches, according to LaRock, who is a Microsoft MVP.

“To me, any risk is too much risk, and I would want to patch. But I wouldn’t do so without knowing the impact, especially for mission-critical servers,” he said.

The advice here is to, in LaRock’s words, “test, test, test.” Ned Bellavance, who is director of cloud solutions at Anexinet in Blue Bell, Pa., and is also a Microsoft MVP, agreed.

If you didn’t follow best practices for high availability, you may have had a performance hit.
Ned Bellavancedirector of cloud solutions at Anexinet

“There are always going to be vulnerabilities and news about vulnerabilities. So, you have to have an environment for testing patches before rolling out changes into production,” he said.

Bellavance said moving databases to the cloud does not relieve an admin’s responsibility for faults in system settings. That is especially true in the face of vulnerabilities like Meltdown, which can exploit cloud environments that share resources like databases across virtual machines. The cloud provider can be expected to roll out fixes, but databases have to be configured to anticipate such disruptions in the status quo.

Microsoft was quick to roll out patches for SQL Server databases on its cloud, but some users experienced downtime, Bellavance said.

“People were impacted because Microsoft had to do cloud maintenance. If you didn’t follow best practices for high availability, you may have had a performance hit,” he said.

Now is as good a time as any to review such practices, Bellavance advised.

Multiple Intel firmware vulnerabilities in Management Engine

New research has uncovered five Intel firmware vulnerabilities related to the controversial Management Engine, leading one expert to question why the Intel ME cannot be disabled.

The research that led to finding the Intel firmware vulnerabilities was undertaken “in response to issues identified by external researchers,” according to Intel. This likely refers to a flaw in Intel Active Management Technology — part of the Intel ME — found in May 2017 and a supposed Intel ME kill switch found in September. Due to issues like these, Intel “performed an in-depth comprehensive security review of our Intel Management Engine (ME), Intel Server Platform Services (SPS), and Intel Trusted Execution Engine (TXE) with the objective of enhancing firmware resilience.”

In a post detailing the Intel firmware vulnerabilities, Intel said the flaws could allow an attacker to gain unauthorized access to a system, impersonate the ME/SPS/TXE, execute arbitrary code or cause a system crash.

Mark Ermolov and Maxim Goryachy, researchers at Positive Technologies Research, an enterprise security company based in Framingham, Mass., were credited with finding three Intel firmware vulnerabilities, one in each of Intel ME, SPS and TXE.

“Intel ME is at the heart of a vast number of devices worldwide, which is why we felt it important to assess its security status. It sits deep below the OS and has visibility of a range of data, everything from information on the hard drive to the microphone and USB,” Goryachy told SearchSecurity. “Given this privileged level of access, a hacker with malicious intent could also use it to attack a target below the radar of traditional software-based countermeasures such as anti-virus.”

How dangerous are Intel ME vulnerabilities

The Intel ME has been a controversial feature because of the highly-privileged level of access it has and the fact that it can continue to run even when the system is powered off. Some have even suggested it could be used as a backdoor to any systems running on Intel hardware.

Tod Beardsley, research director at Rapid7, said that given Intel ME’s “uniquely sensitive position on the network,” he’s happy the security review was done, but he had reservations.

Controlling privilege isn’t difficult to do, but it is key to securing systems.
James Maudesenior security engineer, Avecto

“It is frustrating that it’s difficult to impossible to completely disable this particular management application, even in sites where it’s entirely unused. The act of disabling it tends to require actually touching a keyboard connected to the affected machine,” Beardsley told SearchSecurity. “This doesn’t lend itself well to automation, which is a bummer for sites that have hundreds of affected devices whirring away in far-flung data centers. It’s also difficult to actually get a hold of firmware to fix these things for many affected IoT devices.”

James Maude, senior security engineer at Avecto Limited, an endpoint security software company based in the U.K., said that the Intel firmware vulnerabilities highlight the importance of controlling user privileges because some of the flaws require higher access to exploit.

“From hardware to software, admin accounts with wide-ranging privilege rights present a large attack surface. The fact that these critical security gaps have appeared in hardware that can be found in almost every organization globally demonstrates that all businesses need to bear this in mind,” Maude told SearchSecurity. “Controlling privilege isn’t difficult to do, but it is key to securing systems. It’s time for both enterprises and individual users to realize that they can’t rely solely on inbuilt security — they must also have robust security procedures in place.”

However, Beardsley noted all of the firmware vulnerabilities across the Intel products require physical access to the machine in order to exploit.

“For the majority of issues that require local access, the best advice is simply not to allow untrusted users physical access to the affected systems,” Beardsley said. “This is pretty easy for server farms, but can get trickier for things like point-of-sale systems, kiosks, and other computing objects where low-level employees or the public are expected to touch the machines. That said, it’s nothing a little epoxy in the USB port can’t solve.”

Federal vulnerability review under new VEP still has questions

Experts said the new Vulnerabilities Equities Process Charter unveiled by the White House should be a good step, but argued the value of VEP overall.

Daniel Castro, vice president for the Information Technology and Innovation Foundation (ITIF), an independent research institute, based in Washington, D.C., said the government’s overall cybersecurity policy is still flawed, but the new VEP Charter “is exactly the right policy.”

“The administration has clearly heard the requests for transparency and oversight from many stakeholders, and it has addressed those concerns head on. Now that we have a fully documented process and commitments to publish annual metrics, businesses, security experts, academics, and government officials can start to have a productive debate about how to assess and improve the disclosure process,” Castro said in a statement released by ITIF. “It remains to be seen how receptive the administration will be to reassessing when to share information on vulnerabilities, but its decision today was the right move to build up goodwill among many stakeholders.”

Balancing vulnerability disclosure

However, the VEP overall is still divisive because experts cannot agree on whether to prioritize offensive cyber capabilities or defensive when it comes to federal vulnerability review and disclosure.

In the VEP Charter announcement, Rob Joyce, special assistant to the president and cybersecurity coordinator for the National Security Council, said that “conducting this risk/benefit analysis is a vital responsibility of the federal government.”

“There are advocates on both sides of the vulnerability equity issue who make impassioned arguments. Some argue that every vulnerability should be immediately disclosed to the vendor and patched,” Joyce wrote in the announcement. “In my view, this is tantamount to unilateral disarmament. Our adversaries, both criminal and nation state, are unencumbered by concerns about transparency and responsible disclosure and will certainly not end their own programs to discover and exploit vulnerabilities.”

Katie Moussouris, CEO of Luta Security, Inc., said Joyce’s statement “is a false dichotomy between 100% disclosure, versus the current process that puts 0-day vulnerabilities at the heart of the matter.”

“My assertion has always been to err on the side of disclosure to the vendor, and seek a mission-focused alternative to using zero-day vulnerabilities in broadly-deployed software,” Moussouris told SearchSecurity. “In some cases, not all, the objective of the mission could be completed via other means, such as exploiting misconfigurations, or well-crafted phishing attacks, or even via zero-day exploits in localized, country-specific software instead. Exploitation of vulnerabilities for which a patch exists but hasn’t been applied on the target system yet is one such alternative.”

J.J. Guy, CTO of JASK, a cybersecurity company based in San Francisco, and former officer in the U.S. Air Force, said it is a flawed argument to claim that vulnerability review and disclosure by the government can keep enterprises safe because “it assumes vulnerabilities are finite and if we can simply fix all the vulnerabilities we will be secure.”  

“If the federal government is forced to release the details of newly discovered vulnerabilities, they will stop looking for them. To do otherwise is a waste of taxpayer dollars. The other intelligence agencies in the world will not be similarly constrained, they will continue their research and discover new vulnerabilities. They will use those against U.S. interests, including those of U.S. companies, to steal intellectual property and accelerate research and development of their own companies,” Guy told SearchSecurity. “For every vulnerability the federal government discovers, there are a dozen others still waiting to be discovered – and dozens more that will be introduced in new versions of software over the following year. To attempt to control that through the VEP is like using an umbrella in a hurricane.”

Experts debate the details of the VEP Charter

Although several experts said the new VEP Charter was a step in the right direction for federal vulnerability review, the document was not perfect.

Willis McDonald, senior threat manager at Core Security, a cybersecurity company headquartered in Roswell, Ga., noted an odd discord in the White House announcement which claimed to represent the interests of commercial equities and international partnership equities, but the VEP council “does not include any representation from either commercial or international entities.”

“For national security purposes this is an obvious exclusion but closes the door on external oversight of decisions deemed in the interest of national security. The VEP Charter limits the scope of vulnerabilities addressed by the council to certain classes which allows the reporting entity to report as they see fit vulnerabilities outside of the VEP scope,” McDonald told SearchSecurity. “Vulnerabilities discovered and shared by international partners are not addressed by the VEP, which would allow a participating entity to report the vulnerability as they see fit. The VEP merely expands the agency participants in procedures and councils already in place for making decisions on reporting vulnerabilities.”

Legislation like PATCH and the VEP Charter are in place to calm the public and paint a facade of transparency rather than actually cause change.
Willis McDonaldsenior threat manager at Core Security

Amie Stepanovich, U.S. policy manager at Access Now, a non-profit human rights and public policy group based in New York, said the new VEP Charter “maintains all of the loopholes of the process as it was previously formulated, and in fact creates new ones as well because of the Charter’s own recognition of the importance of cybersecurity, which is specifically undermined by unpatched vulnerabilities.”

“The VEP appears to apply to any vulnerability that is newly discovered and not publicly known, though third parties can expressly contract or agree that a vulnerability will not go through the process,” Stepanovich told SearchSecurity. “There are also other exceptions which remain classified. Additionally, practically it will require an agency determination that a vulnerability meets that standard and is unclear if they are required to consider that determination with a vulnerability that they discover.”

Early reactions to the VEP Charter said one potential loophole might be with non-disclosure agreements (NDAs) being able to keep a bug out of the federal vulnerability review process, but Moussouris said this reading might not be accurate.

“The NDA mention is likely in reference to the fact that exploit sellers may have terms of service that require their buyers not to disclose the vulnerability, such as providing the sample to the affected vendor. It’s not a loophole as characterized, but rather a deliberate commercial term by the exploit vendor to preserve their IP,” Moussouris said. “A bug is the weakness that can be exploited. An exploit in this context is software written to take advantage of that weakness, and it takes craftmanship to engineer an exploit that works reliably against a given target. That exploit is something the exploit vendor might not want to get into the hands of the software vendor.”

Heather West, senior policy manager and Americas principal at Mozilla, agreed that the exceptions process of the VEP needed work and said there needed to be more detail on how disclosures work.

“A good disclosure makes the difference. The Charter requires the board to agree on guidelines about how to disclose — and we hope that they lean on the established expertise at DHS to put those together. No need to reinvent the wheel,” West wrote in a blog post. “Joyce talked about a six month window for retaining a vulnerability, and a quicker reconsideration for a particularly sensitive vulnerability (or one that there isn’t broad agreement about retaining). This reconsideration is critical: just because something is useful today doesn’t make it useful in six months — and indeed, the longer that it is kept, the more likely that someone else has discovered it too.”

VEP and federal vulnerability review transparency

McDonald said the overall push for transparency with the new VEP Charter could “ultimately be just as effective as policies in place prior.”

“Legislation like [the proposed PATCH Act] and the VEP Charter are in place to calm the public and paint a facade of transparency rather than actually cause change,” McDonald said. “Vulnerabilities such as those used in WannaCry would never have been released through VEP due to their usefulness in providing access to remote systems for collection purposes.”

West said the annual reports should lead to better oversight of the federal vulnerability review process.

“This will significantly help us understand how the process works — including whether or not the government is stockpiling vulnerabilities,” West wrote. “While Congress is not involved in the individual decisions that are made, they have a critical role in the oversight of the process itself.”

Stepanovich agreed “much more remains to be done” with the transparency provisions of the VEP Charter.

“Annual reports should guarantee that they will be made publicly available,” Stepanovich said. “Additionally, the Charter should specify more about what is included in the report, including not only the number of withheld vulnerabilities, but their severity and potential impact, as well as records of the frequency each agency votes to disclose or retain a vulnerability.”

Light workload awaits admins on November Patch Tuesday

Microsoft released updates to close 53 vulnerabilities on November Patch Tuesday. But, of the 14 vulnerabilities that affect Windows Server, none have a critical rating.

All the Windows Server-related vulnerabilities are listed as important, and, per Microsoft’s advice with patching, admins should address them as soon as possible.

CVE-2017-11847 uses an elevation of privilege vulnerability in the Windows kernel that affects Windows Server 2008 and up. An attacker who successfully uses this exploit can undertake a range of actions on the server, from deleting data to creating accounts with full user rights.

This vulnerability requires the attacker to first log on to the system, but Microsoft’s Exploitability Index Assessment gives it a rating of “Exploitation More Likely,” which should spur admins to take action without delay.

“You’d need to have someone who has access to the machines, but that’s how a lot of these guys operate these days,” said Gill Langston, director of product management at Qualys Inc., based in Redwood City, Calif. “They’re in the network for a while and they work their way from machine to machine. In that case, they could get on to that server, they could elevate and then get further access to get more information off the machines.”

Several vulnerabilities involve information disclosure in the Windows kernel: CVE-2017-11842, CVE-2017-11849, CVE-2017-11851 and CVE-2017-11853. An attacker can use these vulnerabilities together to compromise a server and attempt to stay undetected for a significant length of time to steal information from an organization.

“The more systems they have access to, the more privilege they have, the more opportunity they have to get into the network and get more information about the network,” Langston said. “This definitely wouldn’t be one of those crimes of opportunity where they enter remotely and grab some data. It would be a long game.”

Semi-Annual Channel release requires adjustments

Microsoft added Windows Server to a Semi-Annual Channel this fall, beginning with Windows Server version 1709. The company plans to release a new edition of Windows Server every six months that targets the needs of businesses that churn out rapid application updates in DevOps environments.

In Windows Server version 1709, Nano Server is a container-based image. It has no servicing stack. To patch Nano Server, admins replace the runtime image with the latest build of the runtime image.

“In the Linux world with containers, you always rebuilt the image with the new packages. I’m not sure on the Windows side if that’s completely figured out,” Langston said.

As with any new technology, users and vendors will need time to develop those habits.

“It took some time on the Linux container side too,” Langston said. “To this day, we talk to people who struggle with their strategy about containerization.”

For more information about the remaining security bulletins for November Patch Tuesday, visit Microsoft’s Security Update Guide.

Dan Cagen is the associate site editor for SearchWindowsServer.com. Write to him at dcagen@techtarget.com.

Light workload awaits admins on November Patch Tuesday

Microsoft released updates to close 53 vulnerabilities on November Patch Tuesday. But, of the 14 vulnerabilities that affect Windows Server, none have a critical rating.

All the Windows Server-related vulnerabilities are listed as important, and, per Microsoft’s advice with patching, admins should address them as soon as possible.

CVE-2017-11847 uses an elevation of privilege vulnerability in the Windows kernel that affects Windows Server 2008 and up. An attacker who successfully uses this exploit can undertake a range of actions on the server, from deleting data to creating accounts with full user rights.

This vulnerability requires the attacker to first log on to the system, but Microsoft’s Exploitability Index Assessment gives it a rating of “Exploitation More Likely,” which should spur admins to take action without delay.

“You’d need to have someone who has access to the machines, but that’s how a lot of these guys operate these days,” said Gill Langston, director of product management at Qualys Inc., based in Redwood City, Calif. “They’re in the network for a while and they work their way from machine to machine. In that case, they could get on to that server, they could elevate and then get further access to get more information off the machines.”

Several vulnerabilities involve information disclosure in the Windows kernel: CVE-2017-11842, CVE-2017-11849, CVE-2017-11851 and CVE-2017-11853. An attacker can use these vulnerabilities together to compromise a server and attempt to stay undetected for a significant length of time to steal information from an organization.

“The more systems they have access to, the more privilege they have, the more opportunity they have to get into the network and get more information about the network,” Langston said. “This definitely wouldn’t be one of those crimes of opportunity where they enter remotely and grab some data. It would be a long game.”

Semi-Annual Channel release requires adjustments

Microsoft added Windows Server to a Semi-Annual Channel this fall, beginning with Windows Server version 1709. The company plans to release a new edition of Windows Server every six months that targets the needs of businesses that churn out rapid application updates in DevOps environments.

In Windows Server version 1709, Nano Server is a container-based image. It has no servicing stack. To patch Nano Server, admins replace the runtime image with the latest build of the runtime image.

“In the Linux world with containers, you always rebuilt the image with the new packages. I’m not sure on the Windows side if that’s completely figured out,” Langston said.

As with any new technology, users and vendors will need time to develop those habits.

“It took some time on the Linux container side too,” Langston said. “To this day, we talk to people who struggle with their strategy about containerization.”

For more information about the remaining security bulletins for November Patch Tuesday, visit Microsoft’s Security Update Guide.

Dan Cagen is the associate site editor for SearchWindowsServer.com. Write to him at dcagen@techtarget.com.

get.com.