CPU Vulnerabilities, Meltdown and Spectre, Kernel Page Table Isolation Patches, and more

Intel Discloses New Spectre Flaws, Pays Researchers $100K
A new set of Spectre speculative execution vulnerability variants have been publicly reported by researchers.
By: Sean Michael Kerner | July 11, 2018

"Intel disclosed a series of vulnerabilities on July 10, including new variants of the Spectre vulnerability the company has been dealing with since January.

Two new Spectre variants were discovered by security researchers Vladimir Kiriansky and Carl Waldspurger, who detailed their findings in a publicly released research paper tilted, "Speculative Buffer Overflows: Attacks and Defenses."

"We introduce Spectre1.1, a new Spectre-v1 variant that leverages speculative stores to create speculative buffer over-flows," the researchers wrote. "We also present Spectre 1.2 on CPUs that do not enforce read/write protections, speculative stores can overwrite read-only data and code pointers to breach sandboxes."

Intel publicly reported the initial round of Meltdown and Spectre CPU flaws on Jan. 3.

Multiple additional variants have been reported in the months since, including two flaws on May 21 and a Lazy Restore Speculative execution risk disclosed on June 13.

The Spectre flaws abuse the speculative execution feature in modern CPUs, which aims to accelerate performance by speculating what the next instruction will be.

The new Spectre 1.1 and Spectre 1.2 variants have been given the CVE-2018-3693 identifier and are rated as being high impact, with a Common Vulnerability Scoring System (CVSS) score of 7.1.

"Systems with microprocessors utilizing speculative execution and branch prediction may allow unauthorized disclosure of information to an attacker with local user access via a speculative buffer overflow and side-channel analysis," Intel warns in an advisory.

The new CVE-2018-3693 issues were reported to Intel via the company's bug bounty program, which is hosted by managed bug bounty provider HackerOne. While full details are not currently publicly available on HackerOne's platform, the Intel bug bounty page indicates that Kiriansky (vik) was paid $100,000 for a bug report.

Mitigations
Intel has already released mitigations for most of the Spectre and Meltdown variants and has publicly stated that it is working on hardware improvements to help prevent future issues as well.

"Along with other companies whose platforms are potentially impacted by these new methods, including AMD and ARM, Intel has worked with operating system vendors, equipment manufacturers, and other ecosystem partners to develop software updates or developer guidance that can help protect systems from these methods," Intel stated in its advisory. "End users and systems administrators should check with their operating system vendors and apply any available updates as soon as practical."

The importance of hardware-based innovation to help reduce the risk for Spectre attacks is something that Kiriansky and Waldspurger's report also highlights.

"If we must rely on software mitigations that require developers to manually reason about the necessity of mitigations, we may face decades of speculative-execution attacks," the paper states.

Although side-channel speculative attack vulnerabilities related to Meltdown and Spectre have been known since January, wide-scale attacks are not currently being reported. A recent report from SonicWall found that in the first half of 2018, there were no attacks that directly made use of Meltdown and Spectre vulnerabilities.

Sean Michael Kerner is a senior editor at eWEEK and InternetNews.com. Follow him on Twitter @TechJournalist."

Thanks for the heads up from this post by @Dr. AMK:
http://forum.notebookreview.com/thr...nts-and-incidents.816109/page-3#post-10761784

 

Intel's Spectre V4 Performance Explored, Speculative Store Bypass
Hardware Unboxed
Published on Jul 14, 2018

 

Not too bad, 1-3% performance loss for 8700K in games, but then again 8700K has masses of headroom available in contrast to 4C Intel CPUs so I would likely expect 4C/8T Intel CPUs like 7700K to be hit harder by this update, my speculation.

 

Intel's Spectre V4 fix is a 2%-8% performance hit when enabled ( it's not enabled by default) according to Microsoft as relayed by Hardware Unboxed - Listen starting @ 01:40 in the video, and starting @ 05:00 for the 1%-6% gaming hit cumulative for current mitigations.

 

I think you're incorrect in your 1-6% gaming hit for V4 Spectre. They say in the video that V4 Spectre is a 1-3% performance hit, and that Spectre V2 is also a 1-3% peformance hit - therefore total performance loss of ALL Spectre mitigations is 1-6%, but this latest V4 Spectre mitigation when taken in isolation is only a 1-3% performance hit on top of the previous Spectre mitigation. (We're talking gaming performance here)

 

If you had listened starting at 05:00 you would have heard it was for the cumulative performance hit. I added some words to try to clear up what I posted. Does it make sense now?

 

Forget it, I've already listened to the video twice, and I've posted what he said.

 

I accurately quoted what he said the cumulative effect of the mitigations on gaming are as 1%-6%, so far, starting at 05:00.

It's the cumulative effect that counts in the long run, especially as additional mitigations are added, as is happening slowly over time.

I wish Microsoft had also quoted a cumulative performance drop across all mitigations, not just the individual 2%-8% performance loss of the Intel Spectre v4 mitigation.

It's more useful to know the whole effect of all the mitigations installed than each one singly.

 

I said the same thing (with regards to gaming), so don't know why you keep quoting my posts - forget it.

 

MSI recently released the latest C6 Microcode for Skylake, which is the latest microcode from Intel covering off these latest Spectre holes that have been mentioned (like in the video of discussion just above): https://www.msi.com/Motherboard/support/Z170A-KRAIT-GAMING-3X.html#down-bios

I've tested it & I'm pleasantly surprised! Firestrike & Timespy scores (including Physics score) are identical with the previous Spectre microcode (C2); Dirt Rally benchmark identical fps, and CB15 score has actually increased & shown the highest numbers I've ever seen (1059 - previously it was 1025 with the older C2 Spectre microcode). Battlefield 1 plays the same and average & maximum CPU usage is the same over long gaming sessions as the previous microcode. The long & short of it is that gaming performance has not been hurt at all with this latest Spectre microcode in comparison to the previous Spectre microcode; not only this, the CB15 score increased, but I have to say that was on a clean install, so not quite like for like, but my installed software is the same. This is my experience with my desktop i7-6700K (in signature).

EDIT: I've just found out that my testing here is invalid. Spectre Variant 4 protection has to be enabled manually in the Windows operating system using registry keys - the variant 4 protection is disabled by default. That means that this testing I did is not valid - all my testing was showing was the performance of the latest microcode but with just the 'old' Spectre protections in place within the OS. It's quite likely that Microsoft will eventually enable Spectre 4 protection by default in the future, and I'll test again when they do enable it by default - I don't see it worthy of testing until it's enabled by default, but I'll report back with my findings when they do so. Apologies for the confusion!

 

Chrome now uses more RAM because of Spectre security fixes
A 10 percent increase in memory usage is bad news
By Tom Warren @tomwarren Jul 12, 2018, 9:38am EDT
https://www.theverge.com/2018/7/12/17564064/google-chrome-ram-usage-memory-increase-spectre-fixes

"Google has revealed this week that its fixes for the Spectre CPU vulnerabilities have caused its Chrome browser to use more memory. In a blog post, spotted by Thurrott, Google details its new Site Isolation feature for the latest Chrome 67 release. It’s a feature, now enabled by default, that’s used to protect against the Spectre side-channel attacks that use the speculative execution features of most processors to access parts of memory that should be restricted. Unfortunately, it has also increased Chrome RAM usage as a result.

“Site Isolation does cause Chrome to create more renderer processes, which comes with performance tradeoffs,” admits Google software engineer Charlie Reis. “There is about a 10-13 percent total memory overhead in real workloads due to the larger number of processes.” That won’t be welcome news to lots of Chrome users who often point out that the browser uses a lot of RAM. An increase of 10 percent is significant, especially on systems with 4GB of RAM or less.

Chrome memory usage will increase across Windows, Mac, and Chrome OS as a result of this change, but Google is working to reduce the impact. “Our team continues to work hard to optimize this behavior to keep Chrome both fast and secure,” explains Reis. Google has also been optimizing Chrome after Microsoft publicly called out Google’s browser for being bad for laptop battery life."

 

Why not use Firefox, instead (like jclausius) ?? "Be smart; be like jclausius" doesn't have quite the ring to it as when it is used by our friend, Phoenix.

[ Note, the above post was tongue in cheek, and not meant to re-hash some kind of religious browser war. ]

 

Hi folks, replying to my own post, because I need to update you. I've just found out that Spectre Variant 4 protection has to be enabled manually in the Windows operating system using registry keys - the variant 4 protection is disabled by default. That means that this testing I did is not valid - all my testing was showing was the performance of the latest microcode but with just the 'old' Spectre protections in place within the OS. It's quite likely that Microsoft will eventually enable Spectre 4 protection by default in the future, and I'll test again when they do enable it by default - I don't see it worthy of testing until it's enabled by default, but I'll report back with my findings when they do so. Apologies for the confusion!

 

New Spectre 1.1 and Spectre 1.2 CPU Flaws Disclosed
By Catalin Cimpanu, July 11, 2018
https://www.bleepingcomputer.com/news/security/new-spectre-11-and-spectre-12-cpu-flaws-disclosed/

"Two security researchers have revealed details about two new Spectre-class vulnerabilities, which they've named Spectre 1.1 and Spectre 1.2.

Just like all the previous Meltdown and Spectre CPU bugs variations, these two take advantage of the process of speculative execution— a feature found in all modern CPUs that has the role of improving performance by computing operations in advance and later discarding unneeded data.

Spectre 1.1 and Spectre 1.2 short description
According to researchers, a Spectre 1.1 attack uses speculative execution to deliver code that overflows CPU store cache buffers in order to write and run malicious code that retrieves data from previously-secured CPU memory sections.

Spectre 1.1 is very similar to the Spectre variant 1 and 4, but the two researchers who discovered the bug say that "currently, no effective static analysis or compiler instrumentation is available to generically detect or mitigate Spectre 1.1."

As for Spectre 1.2, researchers say this bug can be exploited to write to CPU memory sectors that are normally protected by read-only flags.

"As a result [of malicious Spectre 1.2 writes], sandboxing that depends on hardware enforcement of read-only memory is rendered ineffective," researchers say.

To exploit, similarly to most previous Meltdown and Spectre bugs, both vulnerabilities require the presence of malicious code on a user's PC, code responsible for running the attack. This somewhat limits the bug's severity, but doesn't excuse sysadmins who fail to apply patches when they'll become available.

Bug affects Intel and ARM, most likely AMD too
Intel and ARM have publicly acknowledged that some of their CPUs are vulnerable to Spectre 1.1. AMD has not published a statement, but AMD has been historically slow at reviewing security issues. Since all Spectre attacks affected AMD CPUs, it is safe to assume that these new ones also affect AMD's portfolio as well.

Researchers didn't release information on CPUs impacted by Spectre 1.2. No patches are available for either bugs at the moment, but the Intel guide on handling Meltdown and Spectre flaws contains information on how developers can inspect and modify their source code to mitigate the vulnerability at the app/software level.

Microsoft, Oracle, and Red Hat have said they are still investigating if Spectre 1.1 affects data handled by their products and are looking into ways to mitigate the risk at the software level.

In their research paper ( Speculative Buffer Overflows: Attacks and Defenses), the two academics who found the flaws suggested three hardware-based mitigations for preventing Spectre 1.1 attacks, and one for Spectre 1.2.

Intel has also paid the research team a bounty of $100,000 for discovering this bug part of the company's recently launched bug bounty program, which Intel set up following the disclosure of the original Meltdown and Spectre vulnerabilities. This is one of the highest bug bounty rewards known to date.

If you've lost track of all the recent Meltdown and Spectre-related CPU bugs, we've put together the following table to help you keep track of all the variations:

 

Researchers Detail New CPU Side-Channel Attack Named SpectreRSB
By Catalin Cimpanu , July 23, 2018
https://www.bleepingcomputer.com/ne...new-cpu-side-channel-attack-named-spectrersb/

"Academics from the University of California, Riverside (UCR) have published details last week about a new Spectre-class attack that they call SpectreRSB.

Just like all "Spectre-class" attacks, SpectreRSB takes advantage of the process of speculative execution— a feature found in all modern CPUs that has the role of improving performance by computing operations in advance and later discarding unneeded data.

New Spectre attack targets a CPU's RSB
The difference from previous Spectre-like attacks is that SpectreRSB recovers data from the speculative execution process by attacking a different CPU component involved in this "speculation" routine, namely the Return Stack Buffer (RSB). Previous Spectre attacks have targeted the branch predictor unit or parts of the CPU cache.

In the grand architecture of a CPU, the RSB is a component that is involved in the speculative execution routine and works by predicting the return address of an operation the CPU is trying to compute in advance, part of its "speculation."

In a research paper published last week, UCR researchers said the could pollute the RSB code to control the return address and poison a CPU's speculative execution routine,

Because the RSB is shared among hardware threads that execute on the same virtual processor, this pollution enables inter-process, and even inter-VM, pollution of the RSB.

SpectreRSB can be used to recover data from Intel SGXs
In their research paper, UCR researchers have described three attacks that can use a SpectreRSB attack to pollute the RSB and gain access to data they weren't supposed to view.

For example, in two attacks, they polluted the RSB to expose and recover data from other applications running on the same CPU, and in a third, they polluted the RSB "to cause a misspeculation that exposes data outside an SGX compartment."

This latter attack is a big deal because Intel SGX (Software Guard eXtensions) are hardware-separated secure enclaves for processing sensitive data, one of the highest forms of protection that Intel CPUs provide to app developers.

Researchers said they reported the issue to Intel, but also to AMD and ARM. Researchers say they only tested SpectreRSB on Intel CPUs, but because AMD and ARM processors also use RSBs to predict return addresses, they are, most likely, affected as well. Red Hat is also investigating the issue.

Attack bypasses previous Spectre patches
"Importantly, none of the known defenses including Retpoline and Intel's microcode patches stop all SpectreRSB attacks," UCR researchers say.

This means that a threat actor who wants to recover data from a victim's PC that received Spectre patches can update his original Spectre code to target the RSB to bypass any defensive measures applied by the device owner.

But researchers also point out that Intel has a patch that stops this attack on some CPUs, but which it has not rolled out to all of its processors.

"In particular, on Core-i7 Skylake and newer processors (but n`ot on Intel's Xeon processor line), a patch called RSB refilling is used to address a vulnerability when the RSB underfills," researchers say describing a fix for an unrelated bug.

"This defense interferes with SpectreRSB's ability to launch attacks that switch into the kernel. We recommend that this patch should be used on all machines to protect against SpectreRSB."

After Bleeping Computer reached out to Intel earlier today, the company provided a statement suggesting the opposite to what researchers have said —that SpectreRSB attacks could be prevented with existing mitigations.

SpectreRSB is related to Branch Target Injection (CVE-2017-5715), and we expect that the exploits described in this paper are mitigated in the same manner. We have already published guidance for developers in the whitepaper, Speculative Execution Side Channel Mitigations. We are thankful for the ongoing work of the research community as we collectively work to help protect customers.

The list of Spectre and Meltdown-like attacks is growing every month and it's getting harder to keep track of them. Below is a table with some information on all the recent research and vulnerabilities.

To this table, we must also add other attacks based on the ones described above, or smaller variations that aren't considered unique enough. This list includes a Spectre variation that recovers data from the SMM, SgxSpectre, BranchScope, MeltdownPrime and SpectrePrime, and Lazy FP."

 

Makes you wonder when all the different variants of Spectre attacks will be exhausted! You'd think that eventually the angles of attack will run out, but what kind of state the then fully patched CPU will be in...I do not know. Interesting that Intel disagree with the authors of the findings - ie Intel think that those mentioned exploits are already protected with their current patches, although it's unclear if Intel are still researching that new vulnerability to determine if anything further needs to be done.

 

Spectre rises from the dead to bite Intel in the return stack buffer
Panic not: Invincible ghost in the machine dispelled by latest mitigations, we're told
By Thomas Claburn in San Francisco 23 Jul 2018 at 20:30
https://www.theregister.co.uk/2018/07/23/spectre_return_stack_buffer/

" Updated Spectre, a class of vulnerabilities in the speculative execution mechanism employed in modern processor chips, is living up to its name by proving to be unkillable.

Amid a series of mitigations proposed by Intel, Google and others, recent claims by Dartmouth computer scientists to have solved Spectre variant 1, and a proposed chip design fix called SafeSpec, new variants and sub-variants keep appearing.

The findings also revive doubts about whether current and past chip designs can ever be truly fixed.

Spoiler: Details...

Only two weeks ago, researchers Vladimir Kiriansky and Carl Waldspurger disclosed new data-stealing exploits, dubbed Spectre 1.1 and 1.2 [ PDF].

Now there's another called SpectreRSB that exploits the return stack buffer ( RSB), a system in modern CPUs used to help predict return addresses, instead of the branch predictor unit.

In a paper titled Spectre Returns! Speculation Attacks using the Return Stack Buffer, distributed through pre-print server ArXiv, boffins Esmaeil Mohammadian Koruyeh, Khaled Khasawneh, Chengyu Song, and Nael Abu-Ghazaleh detail a new class of Spectre attack that accomplished the same thing as Spectre variant 1 – allowing malicious software to steal passwords, keys, and other sensitive information, from memory it shouldn't be allowed to touch.

These researchers, incidentally, are among those who developed the SafeSpec mitigation.

The latest data-theft technique involves forcing the processor to misspeculate using the RSB. Using a call instruction on x86, SpectreRSB allows an attacker to push a value to the RSB so that the return address for the call instruction no longer matches the contents of the RSB.

The paper, dated July 20, outlines the steps involved in the SpectreRSB attack, which itself has six variants:

"(1) after a context switch to the attacker, s/he flushes shared address entries (for flush reload). The attacker also pollutes the RSB with the target address of a payload gadget in the victim’s address space; (2) the attacker yields the CPU to the victim; (3) The victim eventually executes a return, causing speculative execution at the address on the RSB that was injected by the attacker. Steps 4 and 5 switch back to the attacker to measure the leakage."

The paper also provides some sample code:

1. Function gadget()
2. {
3. push %rbp
4. mov %rsp, %rbp
5. pop %rdi //remove frame/return address
6. pop %rdi //from stack stopping at
7. pop %rdi //next return address
8. nop
9. pop %rbp
10. clflush (%rsp) //flush the return address
11. cpuid
12. retq //triggers speculative return to 17
13. } //committed return goes to 23
14. Function speculative(char *secret_ptr)
15. {
16. gadget(); //modify the Software stack
17. secret = *secret_ptr; //Speculative return here
18. temp &= Array[secret * 256]; //Access Array
19. }
20. Function main()
21. {
22. speculative(secret_address);
23. for (i = 1 to 256) //Actual return to here
24. {
25. t1 = rdtscp();
26. junk = Array[i * 256]; //check cache hit
27. t2 = rdtscp();
28. }
29. }

The researchers have tested SpectreRSB on Intel Haswell and Skylake processors and the SGX2 secure enclave in a Core i7 Skylake chip. They did not test AMD nor Arm cores but note that both chipmakers use RSBs and so they reported their findings to them just in case, as well as to Chipzilla.

The eggheads claimed "none of the known defenses including [Google's] Retpoline and Intel’s microcode patches stop all SpectreRSB attacks."

However, a spokesperson for Intel told us the Xeon maker believes mitigations already available to programmers really do thwart SpectreRSB side-channel shenanigans:

SpectreRSB is related to Branch Target Injection (CVE-2017-5715), and we expect that the exploits described in this paper are mitigated in the same manner. We have already published guidance for developers in the whitepaper, Speculative Execution Side Channel Mitigations. We are thankful for the ongoing work of the research community as we collectively work to help protect customers.

You can find Intel's mitigation white paper, here [PDF]. Spokespeople for AMD and Arm were not available for immediate comment.

ELF'n'safety
Last week, researchers at Dartmouth suggested a defense against Spectre variant one, to which Intel previously proposed adding the LFENCE instruction to code as a defense against speculative execution.

The Dartmouth solution involves using something called ELFbac policy techniques. In an email to The Register, Dartmouth PhD student Prashant Anantharaman explained that ELFbac lets programmers set policies for memory permissions. Effectively, a program's ELF executable tells the operating system how to ring-fence particular areas of memoryto hopefully thwart Spectre side-channel attacks.

"The permissions set here for the page-tables are also respected by the speculative execution branches, and hence if the developer intends to protect certain secrets within the program, the attacker exploiting Spectre would still not be able to gain access to these secrets," he said. "These policies are defined at the ABI-level using the existing capabilities of the static linker and the build tool-chain."

Anantharaman said the technique, which is enforced through Linux kernel memory management mechanisms, can be generalized for use against a larger class of intra-process memory attacks.

Asked via email whether he's seen the Dartmouth research, Nael Abu-Ghazaleh, professor of computer science and engineering at UC Riverside and a coauthor of the SpectreRSB paper, told The Register that he had reviewed it briefly.

"From the information I can find it has a strong flavor of basically doing the KPTI solution but at the user level software (i.e., map regions of memory where the secrets are only when you need them)," he said. "This is likely to have a substantial performance overhead, especially if the secret data is accessed often. Moreover, the programmer has to be disciplined enough to isolate all the secret data."

Abu-Ghazaleh said there's value in software-based fixes, but it's not enough.

As computer science researcher Daniel Genkin told The Register in January, Abu-Ghazaleh believes that chip will have to be redesigned to eliminate speculative execution flaws.

"Although patching is important, we need to consider this class of vulnerability in the design of new processors to completely address the problem," he said.

Spoiler

Updated to add
AMD also says current side-channel mitigations kill SpectreRSB dead. A spokesperson told us:

AMD is aware of a new research paper on processor speculation and a proposed vulnerability in the return stack buffer. AMD believes its recommended Indirect Branch Prediction Barrier (IBPB) setting mitigates against the described vulnerability. As stated in this AMD Whitepaper, when IBPB is set in software for context switching, the processor enforces that older indirect branches cannot influence predictions of indirect branches in the future, we believe thereby effectively mitigating against the described vulnerability.

Meanwhile, a spokesperson for Arm said: "We are aware of this report and updated information is available on our security update page."

It is understood that while SpectreRSB is a true sub-variant of Spectre, it is mitigated by today's defense mechanisms in spite of the paper's conclusions, according to chip and software engineers. Not that any malware is exploiting these side-channels in real attacks right now anyway."

Comments

 

How to (slowly) steal secrets over the network from chip security holes: NetSpectre summoned
Billions of devices potentially at risk – but Intel isn't worried
By Thomas Claburn in San Francisco 26 Jul 2018 at 23:07
https://www.theregister.co.uk/2018/07/26/netspectre_network_leak/

"Computer security researchers have devised a way to exploit the speculative-execution design flaws in modern processor chips over a network connection – a possibility that sounds rather more serious but may be something less than that.

Spoiler: Details...

Until now, Spectre attacks have required malicious code to be running on a vulnerable machine to potentially extract passwords, keys, and other secrets, from the memory of other software on the computer.

Now, here comes NetSpectre: a technique for potentially extracting private information from another device on the network without requiring any exploit code on the target box, albeit exfiltrating it rather slowly. There are potentially billions of computers, gadgets, and gizmos at some degree of risk.

"Spectre? Psst. Who cares. You need local code execution."

*record skip* pic.twitter.com/BhKXfrpY7C
— The Register (@TheRegister) July 26, 2018

Establishing a network connection to a service running exploitable snippets of code should, in theory, be enough to very slowly discern the contents of application memory remotely. This requires precise timing and constant measurement, so noisy network environments, such as the internet, will hamper exploitation to some extent.

That's the first stage. The next step is to pull out interesting data rather than grab temporary variables and other inconsequential stuff lying around in a program's memory – a step that is non-trivial.

"We show that Spectre attacks do not require local code execution but can also be mounted remotely," said Michael Schwartz, one of the NetSpectre researchers, in an email to The Register. "Moreover, with the new covert channel, we show that Spectre does not necessarily require the cache to leak values."

The major catch, described in a paper titled NetSpectre: Read Arbitrary Memory over Network, is that this side-channel attack only leaks 15 bits per hour, or 60 bits an hour via an AVX-based covert channel, which means it could take days to find and gather privileged information such as an encryption key or authentication token.

High-value targets
Schwartz reckons this data leakage is something people should worry about, although, admitted that the speed at which it can be conducted is a limiting factor.

"Luckily, the speed is quite limited, which makes this attack mainly interesting for targeted attacks on high-value targets," he said. "If the system is fully patched against Spectre, including the new gadget variants we show in the paper, the attack should be prevented. However, we are still at the beginning of understanding how Spectre gadgets can look like, so this is not a problem that is trivial to solve."

Spectre attacks manipulate the branch prediction mechanisms used in modern CPUs' speculative execution engines to force the target process to access memory in a way that leaks privileged information. Today's processors rely on speculative execution to run software at high speed, predicting where the flow of the program will go ahead and priming themselves with code and data in anticipation. It is possible to discern the contents of memory that is otherwise out of sight by manipulating and observing the effects of this predictive execution.

For a remote Spectre attack, the targeted device must include code that performs an operation such as an reading through an array in a loop with a bounds check on each iteration. The exploit abuses design decisions within the processor microarchitecture to induce speculative execution, and discern the content of memory as a result. The paper, written by Michael Schwarz, Daniel Gruss, Martin Schwarzl, Moritz Lipp, and Stefan Mangard of Austria's Graz University of Technology, calls these code fragments "Spectre gadgets."

"Similar to a local Spectre attack, our remote attack requires the presence of a Spectre gadget in the code of the target," the paper explained. "We show that systems containing the required Spectre gadgets in an exposed network interface or API can be attacked with our generic remote Spectre attack, allowing to read arbitrary memory over the network. The attacker only sends a series of crafted requests to the victim and measures the response time to leak a secret value from the victim’s memory."

The attack involves sending multiple network packets at the target with a value that's always in bounds, thereby training the branch predictor to predict the comparison as true.

Don't cross the (bit) streams
For example, given this code running on a vulnerable device:

if (x < bitstream_length)
if(bitstream[x])
flag = true;

...a miscreant can attempt to use the bitstream[x] access to extract a bit from the software's private memory. "The attacker sends a packet where x is out of bounds, such that bitstream[x] is a secret bit in the target’s memory," the paper explained.

The branch predictor then assumes the bounds check is true and the memory access is speculatively executed.

Intel, informed by the researchers of their findings earlier this year, doesn't appear to be terribly alarmed. Essentially, if you've updated your code and applications to mitigate previous Spectre exploits, you should be safe from NetSpectre.

"NetSpectre is an application of Bounds Check Bypass (CVE-2017-5753), and is mitigated in the same manner – through code inspection and modification of software to ensure a speculation stopping barrier is in place where appropriate," a spokesperson told The Register in an emailed statement.

Intel said it has updated its white paper, Analyzing Potential Bounds Check Bypass Vulnerabilities, to incorporate information related to the findings and thanked the researchers for reporting their research.

Red Hat says it has been working with the researchers and plans to publish details about the impact on its products, if any, in a blog post on Friday. "We have not identified any viable userspace Spectre gadget attacks but are actively auditing all of the daemons that listen over the network and the rest of the stack," said Jon Masters, chief Arm architect and computer microarchitecture lead at Red Hat, via Twitter.

So far, as with the other Spectre and Meltdown variants and sub-variants, no malware is exploiting these flaws in the wild, that we know of."
Comments

 

More on NetSpectre - "With NetSpectre, an attacker can remotely read the memory of a victim system without running any code on that system." Source: https://arstechnica.com/gadgets/201...-enables-secrets-to-be-leaked-over-a-network/

 

Intel CPU has become attack vector just like adobe flash.

 

Except, we can uninstall Adobe Flash...

 

We can simply uninstall/physically remove intel mobo and replace it with Ryzen.

 

Question on Adobe Flash. Are you folks able to avoid it? I have many work related sites that I have to run Flash. Is there any alternative ?

Ofc I always "ask to run flash".

Thought I'd add this for those of you like me who still have to run it . A 'kinda' safeguard is a tweak in (64bit) C:\Windows\SysWOW64\Macromed\Flash. After any Flash update, go to the folder noted (see link below for 32bit, and Linux folders) and replace mms.cfg file with...
AVHardwareDisable=1
DisableDeviceFontEnumeration=1
DisableSockets=1
ThirdPartyStorage=0
LocalStorageLimit=1
AssetCacheSize=0
FileDownloadDisable=1
FileUploadDisable=1
LegacyDomainMatching=0

Source (JonDonym): https://anonymous-proxy-servers.net/en/help/flash-applets.html

Better than nothing. Sorry if off topic.

 

Microsoft's Meltdown / Spectre Summary Guidance page doesn't have the Spectre Variant 3a / 4 listed, just a heads up to watch for future updates for:

Variant 3a: Rogue System Register Read – CVE-2018-3640
Variant 4: Speculative Store Bypass – CVE-2018-3639

" Security TechCenter
ADV180002 | Guidance to mitigate speculative execution side-channel vulnerabilities
Security Advisory
Published: 01/03/2018 | Last Updated : 08/01/2018
https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV180002

Update 23.0 08/01/2018 Added FAQ #18 to address a high CPU utilization issue some customers with an AMD-based device are experiencing after installing the June or July Windows security updates or after installing a BIOS update.

18. I have an AMD-based device and I am experiencing high CPU utilization after installing the June or July Windows security updates or after installing a BIOS update for my device. Is this expected?

There have been reports of high CPU utilization resulting in performance degradation on some systems with Family 15h & 16h AMD processors after installing June 2018 or July 2018 Windows updates from Microsoft and updated AMD microcode that addresses Spectre Variant 2 (CVE-2017-5715 - Branch Target Injection). AMD and Microsoft have investigated this issue, and Microsoft is working to provide a solution in the near-term. This advisory will be updated when a solution is released.

Customers who wish to remediate the performance impact caused by this issue may wish to consider temporarily disabling Spectre Variant 2 mitigations via registry settings for Windows until a solution for this issue is released. When a solution is released for this issue, customers will need to re-enable the registry settings.

We do not recommend that customers uninstall the June or July security updates for Windows because the June and July updates provide numerous other critical security fixes.

Changing Registry Settings

Important This section, method, or task contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how to back up and restore the registry, see [Microsoft Knowledge Base article 322756[( https://support.microsoft.com/en-us/help/322756).

Note Disabling and enabling the Spectre Variant 2 mitigation through registry setting changes requires administrative rights and a restart.

To disable Spectre Variant 2 mitigations:

reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v FeatureSettingsOverride /t REG_DWORD /d 1 /f
reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v FeatureSettingsOverrideMask /t REG_DWORD /d 3 /f

Restart the computer for the changes to take effect.

When the solution is available, the registry keys will need to be re-enabled.

To enable Spectre Variant 2 mitigations:

reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v FeatureSettingsOverride /t REG_DWORD /d 0 /f
reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v FeatureSettingsOverrideMask /t REG_DWORD /d 3 /f

Restart the computer for the changes to take effect."

This page is very long now and the formatting doesn't translate well to posting here, but if you find a particular section of interest, please do post it here for discussion.

 

Latest Intel microcode revision guidance.PDF (August 8. 2018)

 

Uploaded the latest ucode patch via VMware fling method.
@judal57 @VICKYGAMEBOY @Papusan @hmscott @Mr. Fox @THEBOSS619
Intel/AMD uCode fix for Spectre, HT bug fix and Meltdown.

 

Researchers Disclose New Foreshadow (L1TF) Vulnerabilities Affecting Intel CPUs
By Catalin Cimpanu, August 14, 2018
https://www.bleepingcomputer.com/ne...ow-l1tf-vulnerabilities-affecting-intel-cpus/

"Academics and private sector researchers have revealed details today about three new vulnerabilities affecting Intel CPUs.

All three are Spectre-class attacks that take advantage of a CPU design feature named speculative execution —a feature found in all modern CPUs that has the role of improving performance by computing operations in advance and later discarding unneeded data.

These flaws target data processed during speculative execution that is stored inside a processor's L1 cache —the fastest memory in a computer and closest to the processor, also shared by CPU cores.

Vulnerabilities referred to as L1TF or Foreshadow
The three issues are referred to as L1 Terminal Fault (or L1TF) by the general tech industry, but they were initially named "Foreshadow" and "Foreshadow-NG" by the researchers who discovered them.

They are as follows:

Foreshadow - the original attack [CVE-2018-3615] designed to extract Intel SGX data residing in the L1 cache, detailed in this research paper here.
Foreshadow-NG - two variations of the original Foreshadow attack that can extract data residing in the CPU's L1 cache, including information belonging to the System Management Mode (SMM) or operating system kernel [CVE-2018-3620], or data belonging virtual machines running on a host OS' Virtual Machine Monitor (VMM) [CVE-2018-3646]. Both Foreshadow-NG variations are detailed in this research paper here.

Alternative names include:
L1 Terminal Fault – SGX >>> aka CVE-2018-3615, aka Foreshadow
L1 Terminal Fault – OS/SMM >>> aka CVE-2018-3620, aka Foreshadow-NG
L1 Terminal Fault – VMM >>> aka CVE-2018-3646, aka Foreshadow-NG

Only Intel CPUs are affected
According to the research team behind the L1TF/Foreshadow flaws, only Intel CPUs are affected. Researchers contacted Intel earlier this year and worked with the company, OS makers, and cloud hosting providers to prepare mitigations and updates.

"L1 Terminal Fault is addressed by microcode updates released earlier this year, coupled with corresponding updates to operating system and hypervisor software that are available starting today," an Intel spokesperson told Bleeping Computer via email today.

"We’ve provided more information on our website and continue to encourage everyone to keep their systems up to date, as its one of the best ways to stay protected," the spokesperson added. "We’d like to extend our thanks to the researchers at imec-DistriNet, KU Leuven, Technion- Israel Institute of Technology, University of Michigan, University of Adelaide and Data61 and our industry partners for their collaboration in helping us identify and address this issue."

Both the research team, Intel, and Red Hat have published YouTube videos explaining how the L1TF/Foreshadow vulnerabilities work under the hood."

Patches available. No performance hit.

Spoiler

According to Intel, applying Intel microcode updates and OS patches for CVE-2018-3615, CVE-2018-3620, and CVE-2018-3646 should mitigate L1TF/Foreshadow attacks in full.

Intel also said that unlike the case of Spectre where updates took a big bite out of the performance of Intel CPUs "there has been no meaningful performance impact observed as a result of [L1TF] mitigations applied."

Intel has published a blog post about L1TF/Foreshadow, an FAQ page, and a security guidance page. The list of affected CPUs is available on Intel's official security advisory.

Microsoft, Oracle, and Red Hat have also published blog posts about the L1TF/Foreshadow flaws, along with information about patches. Fixes have also arrived in Cisco products, the Linux kernel and via the Microsoft August 2018 Patch Tuesday. Security guidance pages have also been published by the three main cloud computing providers — Amazon Web Services, Google Cloud, and Microsoft Azure.

The team behind the research have also created a dedicated website explaining to explain the impact of the L1TF/Foreshadow vulnerabilities.

Foreshadow Attack
Tee Aaas
Published on Aug 14, 2018
For more information, see http://foreshadowattack.com

Understanding L1 Terminal Fault (L1TF)
Intel Newsroom
Published on Aug 14, 2018
Learn more about the speculative execution side-channel method called L1 Terminal Fault (L1TF).

Spoiler

There are three applications of L1TF speculative execution side-channel cache timing vulnerabilities. They are similar to previously reported variants. These particular methods target access to the L1 data cache, a small pool of memory within each processor core designed to store information about what the processor core is most likely to do next.
Microcode updates released by Intel are an important component of the mitigation strategy for all three applications of L1TF. When coupled with corresponding updates to operating system and hypervisor software from industry partners and the open source community, these updates help ensure that consumers, IT professionals and cloud service providers have access to the protections they need.
Learn more about L1TF at https://newsroom.intel.com/editorials...

L1TF Explained in 3 Minutes from Red Hat
Red Hat Videos
Published on Aug 14, 2018

Spoiler

L1 Terminal Fault (L1TF) is a security vulnerability that allows unauthorized users to access information from Intel processor based servers including deployments in cloud environments.

This vulnerability takes advantage of the way Intel processors handle page tables (the maps that translate between physical and virtual memory resources). Like Spectre and Meltdown in early 2018, L1TF allows unauthorized users to access data from speculative operations.

What makes L1TF even more dangerous is that malicious users can steal secrets across multi-tenant cloud environments.

This 3-minute video provides a high-level primer on what L1TF is and how it works. For more technical information about the vulnerability and what your company should do about it, please visit: https://red.ht/2MpetWt

Understanding L1 Terminal Fault from Red Hat
Red Hat Videos
Published on Aug 14, 2018

Spoiler: Details...

L1 Terminal Fault (L1TF) is a security vulnerability that allows unauthorized users to access information from Intel processor based servers and cloud environments. In this video, Red Hat computer architect Jon Masters provides a technical overview on how the flaw works and what companies can do about it.
To read Jon’s full blog post on L1TF, visit: https://red.ht/2MpetWt

Foreshadow Attack - Technical Demo
Tee Aaas
Published on Aug 14, 2018

 

Wonderful! More reasons to stay away from Intel CPU. If L1 cache(s) are compromised and someone stealthily keep a tab on every instruction executed so far, all apps can be modified on the fly if apps weren't checking the hash signature( when it was built/exported as executable).
More likely, developers using Intel compilers for best performance must switch to generic compilers from Linux and MSFT for better security.
I feel Intel CPus might be blacklisted by HWBOT/3dmark if they're aren't having correct uCodes and OS fixes to begin with.
I want to hear Linus Torvalds and Red hat's take on future Intel exploits. OS can't be updated every damn time just to fix the CPU bugs.

 

There was a Windows 10 patch for this yesterday:
https://support.microsoft.com/en-gb/help/4343909/windows-10-update-kb4343909

I can confirm no performance hit using latest microcode C6 for Skylake combined with the patch above. This is in Cinebench R15 / 3DMark / Timespy / Battlefield 1 testing. (I'm assuming that the protection is turned on automatically if you're running the latest microcode & this Windows patch.)

 

The patch links for Microsoft and more are also in my post, under the "Spoiler" - it's always good to click "Spoilers" open before replying.

"...and via the Microsoft August 2018 Patch Tuesday."

Here is what is under the "Spoiler", again in the open:

Patches available. No performance hit.
According to Intel, applying Intel microcode updates and OS patches for CVE-2018-3615, CVE-2018-3620, and CVE-2018-3646 should mitigate L1TF/Foreshadow attacks in full.

Intel also said that unlike the case of Spectre where updates took a big bite out of the performance of Intel CPUs "there has been no meaningful performance impact observed as a result of [L1TF] mitigations applied."

Intel has published a blog post about L1TF/Foreshadow, an FAQ page, and a security guidance page. The list of affected CPUs is available on Intel's official security advisory.

Microsoft, Oracle, and Red Hat have also published blog posts about the L1TF/Foreshadow flaws, along with information about patches. Fixes have also arrived in Cisco products, the Linux kernel and via the Microsoft August 2018 Patch Tuesday. Security guidance pages have also been published by the three main cloud computing providers — Amazon Web Services, Google Cloud, and Microsoft Azure.

The team behind the research have also created a dedicated website explaining to explain the impact of the L1TF/Foreshadow vulnerabilities.

 

Linus Torvalds declares Intel fix for Meltdown/Spectre ‘COMPLETE AND UTTER GARBAGE’
Devin Coldewey @techcrunch / Jan 22, 2018
https://techcrunch.com/2018/01/22/l...-meltdown-spectre-complete-and-utter-garbage/

My post had 2 video's by Redhat, and they have additional links in the "Spoiler" in that post, as well as Twitter responses.

Intel's really getting to be a mess...

@Robbo99999

Guys I use "Spoiler"'s to reduce the "wall of text" effect, to try to make the posts / thread easier to quickly scroll through, while providing needed details and information, please do click into the "Spoilers" to see the goodies hidden inside.

 

Yep, I didn't get a performance hit.

 

Even on m17x?

 

Not tried that one yet. It'll get updated & I'll post here how that one does, only got Cinebench R15 as a reference for that one, or maybe wPrime, will have to check any notes I've made.

 

Cinebench stock settings won't see any drops. Try TS bench and cinebench at 16 threads.

 

Ok, I'll bare it in mind.

 

Hangover Tuesday: Every version of Windows 10 gets yet another Intel microcode patch
Posted on August 21st, 2018 at 14:28 woody Comment on the AskWoody Lounge
There are 13 new August patches in the Microsoft Update Catalog, all dated August 20, all released in the past hour or two.

They’re Intel microcode updates, e.g., KB 4346084 is for Win10 version 1803. Download link Microsoft Update Catalog

Intel recently announced that they have completed their validations and started to release microcode for recent CPU platforms related to Spectre Variant 3a (CVE-2018-3640: “Rogue System Register Read (RSRE)”), Spectre Variant 4 (CVE-2018-3639: “Speculative Store Bypass (SSB)”), L1TF (CVE-2018-3615, CVE-2018-3620, CVE-2018-3646: “L1 Terminal Fault”). In addition to microcode updates previously released in KB4100347 to address Spectre Variant 2 (CVE 2017-5715: “Branch Target Injection”), this update also includes microcode updates from Intel for the following CPUs.

They’re being distributed through Windows Update. (Susan Bradley notes that they have to be applied manually.) Of course, we’re at MS-DEFCON 2, so I’d suggest you give them a pass. Nope, there still aren’t any Meltdown or Spectre (Variant n, n=1 to 4) exploits in the wild that you need to be concerned about.

UncategorizedKB 4346084

 

Hey, that's not too bad when it comes to Skylake CPUs (my i7-6700K). I already have that CPU microcode through from my BIOS motherboard manufacturer. C6 microcode performing fine here, no loss of performance compared to previous C2 microcode.

 

And by coincidence - I just had the older KB4100347 pushed to my notebook. It used to be that you had to manually download it, and I avoided it as I don't think Spectre is worth the performance hit. Now I had no choice but to install it. KB4346084 may be "opt in" at the moment, and it hasn't been pushed to my notebook. But I am guessing they will do the same thing at some point and make it mandatory just like the previous one.

Why did they change the previous microcode update from opt in to mandatory? I am assuming this means that this new microcode will at some point also be mandatory?

 

You shouldn’t getting them through Windows Update (stand-alone updates like this one + all the rest of their ****y shouldnt be forced on people). But as we all know... The Redmond Morons Retards screw up everything they touch and nothing works as intended anymore. Either on purpose or pure devilness. Probably both.

Another report of an unwelcome 1803 upgrade over a metered connection
Posted on August 20th, 2018 at 07:19 woody Comment on the AskWoody Lounge
Just got this from ig:

Warning! Windows is now forcing 1803 on those applications that are currently using build 1709. I did my 1709 cumulative updates today on my metered connection. 1803 was hidden using the wushowhide as usual. Windows update utility showed my PC was current as of today, after I installed the updates. However, a few hours later, with out warning, Windows started installing feature update 1803! My settings have always been on manual not automatic. Nor did I chose any time settings. I’m using Home, but I wouldn’t be surprised if this occurs with Pro, since they did pulled a similar stunt with the previous Fall Creators build.​

Any other reports of 1803 being pushed over a metered connection?

Windows News Win10 1803 forced update

 

Lol

https://www.theregister.co.uk/2018/08/21/intel_cpu_patch_licence/

 

Intel Publishes Microcode Security Patches With No Benchmarks Or Profiling Allowed - (theregister.co.uk)

"There is a new license term applied to the new microcode: "You will not, and will not allow any third party to (i) use, copy, distribute, sell or offer to sell the Software or associated documentation; (ii) modify, adapt, enhance, disassemble, decompile, reverse engineer, change or create derivative works from the Software except and only to the extent as specifically required by mandatory applicable laws or any applicable third party license terms accompanying the Software; (iii) use or make the Software available for the use or benefit of third parties; or (iv) use the Software on Your products other than those that include the Intel hardware product(s), platform(s), or software identified in the Software; or (v) publish or provide any Software benchmark or comparison test results."

The security fixes are known to significantly slow down Intel processors, which won't just disappoint customers and reduce the public regard of Intel, it will probably lead to lawsuits (if it hasn't already).

Suddenly having processors that are perhaps 5% to 10% slower, if they are to be secure, is a significant damage to many companies that run server farms or provide cloud services.

I'm not blaming Intel for this, I don't know if Intel could have foreseen the problem. Since some similar exploits have been discovered for AMD and ARM CPUs, the answer could be "no." But certainly customers are upset.

Another issue is whether the customer should install the fix at all. Many computer users don't allow outside or unprivileged users to run on their CPUs the way a cloud or hosting company does. For them, these side-channel and timing attacks are mostly irrelevant, and the slowdown incurred by installing the fix is unnecessary.

So, lots of people are interested in the speed penalty incurred in the microcode fixes, and Intel has now attempted to gag anyone who would collect information for reporting about those penalties, through a restriction in their license. Bad move.

The correct way to handle security problems is to own up to the damage, publish mitigations, and make it possible for your customers to get along. Hiding how they are damaged is unacceptable.

Silencing free speech by those who would merely publish benchmarks? Bad business.

Customers can't trust your components when you do that."

https://www.theregister.co.uk/2018/...l_attacks_on_branch_prediction_units_and_sgx/

Fix for July's Spectre-like bug is breaking some supers
RDMA-Lustre combo swatted, HPC admins scramble
By Richard Chirgwin 21 Aug 2018 at 00:35
https://www.theregister.co.uk/2018/08/21/fix_for_julys_spectrelike_bug_is_breaking_some_supers/

 

So what about Intel benchmark result sheets?

 

The Intel license forbids publishing benchmarks or comparison results.

"... or (v) publish or provide any Materials benchmark or comparison test results."

To distribute the microcode, the distributor has to agree and accept the license, and the Debian Maintainers have refused it.

 

Even I refuse to accept the T&C.

 

I think once people see Zen 2 7nm, plus all these security headaches, Intel holding AMD to 20% next year is a joke. It will likely exceed that, especially when trying to prevent people from having transparent performance numbers from the patches, which can cost billions.

Also, @Papusan - Just because consumers are not being told about these exploits being used in the wild means nothing. When first announced, a grad student replicated it within a day. Granted, there are permissions and access that are needed, but we are 8 months from disclosure, 4 variants deep on Spectre with subdivisions on many of those variants, netspectre and NG, and this is ignoring meltdown which primarily was just Intel.

Sure, ARM and AMD were effected to a degree, but way less than Intel. With the time and ease a person with knowledge and understanding can implement it, the reason they are forcing such things is because they know they cannot identify everything, but that it still is probably out there. It is like how that malware brought TSMC to its knees. You don't foresee it. So why is Microsoft forcing it? likely because they either know something that you don't on it actually being out there OR fear for client computers connected to networks because of things like TSMC went through. Hell, they made my system download that update and I'm running a 1950X! LOL. Obviously that makes little sense from the kb on the topic.

But, the real thing is that if they designed their hardware properly, you never would have a choice on the mitigation because the mitigation would not exist. Just security would exist. Performance hits is your way, as a consumer, to understand that the producer of the product you bought screwed up the design. You find out that you did not get what you thought you did. Intel used to scream how secure they were from the rooftops, advertised for use in cloud computing to regular consumers.

Now, you can complain, and have some reason to complain, about Microsoft forcing the updates, generally. But, using that to obfuscate the anger you should have at Intel about them screwing up so badly is almost as bad as Apple owners refusing to hold Apple accountable for their problems and crappy designs. It doesn't fully make sense.

Hopefully all companies, with this much time, have hardware changes to address some of these issues in their new chips (meaning Cascade-SP\X, hopefully the mainstream 9 series, Epyc 2 and all Zen 2 chips, and ARM Cortex-A76 and beyond). Also, AMD isn't effected by L1TF and is less or not effected by some of the Spectres and fixes. They need held accountable for what they missed, or as some have mentioned, lets not hold ARM, AMD, or Intel accountable for the common bugs that effect all of them (I disagree with that because ALL of them need to feel the heat over their actions, but in proportion to their screw up, and Intel has proven to be the biggest screw up in this security bungle). But, if doing that, it leaves Intel with plenty to answer for AFTER removing common denominators.

 

Update: 10:44 AM, 23 August 2018: Intel’s full updated license and statement
Intel: We have simplified the Intel license to make it easier to distribute CPU microcode updates and posted the new version http://bit.ly/2w9RjtM . As an active member of the open source community, we continue to welcome all feedback and thank the community.

Intel did respond fairly quickly to my email and it looks like they will be rolling back the offending clauses in the license soon enough (we’ll let you know either way). It does look like this was an honest mistake because I doubt any executive with know-how of the market would be dumb enough to think an order like this would actually work. Unless their aim was to make sure everyone benches the hell out of the new updates – in which case they were spectacularly successful.

Micro$haft patch upgrade history ain't nice. Hence none should be forced on updates. Neither patches, drivers, microcode, software or firmware should come into my OWN property before I my self want it! I won't accept it. Maybe others will and even like it, but not me.

Spoiler: Not nice. Only from the last couple of days

• Problem with Visual Studio 2015 update KB 4456688
  Posted on August 23rd, 2018 at 08:15 woody Comment on the AskWoody Lounge
  This from poster @deuxbits:
  
  2018 August 18 Microsoft released a security update to Visual Studio 2015 Update 3 to deal with CVE-2018-0952 and CVE-2018-8273. The update can be found in their update catalog under KB4456688.
  
  We’ve applied this update on some canary machines to find out if there is any impact before a general rollout… Unfortunately this security update renders VS2015 virtually unusable – if you try to run your code in debug mode it is super super slow. Don’t know if anyone else has seen this problem. Wanted to let you guys know that MS seems to have botched yet another patch.
  
  Anybody else seeing this problem?
  
  
  Windows Patches/SecurityKB 4456688
  
  
• Bloomberg Businessweek: Microsoft Bug Testers Unionized. Then They Were Dismissed
  Posted on August 23rd, 2018 at 07:14 woody Comment on the AskWoody Lounge
  A truly damning indictment of the tech contract labor scene.
  
  Definitely a must-read.
  
  Josh Eidelson and Hassan Kanu at Bloomberg Businessweek.
  
  Four years ago, Boucher says, he hoped to force Microsoft to improve working conditions for the Lionbridge temps, who were testing apps at a Microsoft office in Washington state. In 2015, after the union was formed, Microsoft began requiring Lionbridge and other contractors to provide workers with at least three weeks of annual paid time off. But the union’s negotiations with Lionbridge broke down, and in 2016 the contractor told Boucher and his colleagues it planned to lay off some of them in response to reduced demand from Microsoft.
  
  Counterpoint: The bug testers may have been involved exclusively with Windows Store apps:
  
  Throughout the proceedings, Microsoft maintained it had no involvement in the decision, and that it could be explained innocently enough. The number of apps in its Windows Store had dwindled to 13 percent of the 1.1 million offered in 2014, the company said, and it needed less bug testing from Lionbridge
  
  Guess we’ll find out soon enough.
  
  Thx @SimonZerafa
  
  
  Windows Patches/SecurityWindows patching
  
  
• Patch Lady – Microcode confusion
  Posted on August 22nd, 2018 at 22:16 Susan Bradley Comment on the AskWoody Lounge
  Patch Lady here on the Microcode updates.
  
  So here’s my take on all of this:
  
  Unless you are a nation state, have a key asset in a cloud server, or are running for a government office, I think we are spending way way more time worrying about this than we should. I still think that attackers will nail me with malware, attack me with phishing, ransomware, etc etc, way more than someone will use these side channel attacks to gain information from me. Remember that the attacker has to get on your system first and I still think they will use the umpteen other ways to attack me easier than this attack. Also keep in mind that we won’t really have a full fix for this issue for several years. Intel and AMD will need to redesign the chips to ultimately get fixed.
  
  That said… if you are as confused as I am about all these updates, join the club. There are a few facts to keep in mind:
  
  You need two updates to ultimately be patched. An operating system update (of which the August patches have the latest updates that include L1 Terminal Fault (L1TF) that affects Intel® Core® processors and Intel® Xeon® processors (CVE-2018-3620 and CVE-2018-3646) aka the latest ones.
  
  You then need EITHER a firmware patch from your OEM vendor or one of these Microcode updates that Microsoft have been offering up.
  
  You don’t need both a firmware and a Microcode. It’s probably wiser to get a firmware update as I’ve found in patching windows 10 and getting all the feature updates on, that machines really need a firmware update to patch well in general.
  
  In my office where we have standardized on HP, I am making sure that all machines have the HP support assistant to monitor firmware updates. On my Lenovo laptops I’ve made sure they have the solution center installed.
  
  If you have a relatively recent Windows 10 OEM build computer, look to the vendor for a firmware update.
  
  If you want a Microcode update keep in mind that Microsoft released in August to the MU channel *just* for 1803. Per this page: https://support.microsoft.com/en-us/help/4093836/summary-of-intel-microcode-updates 1803 is getting them from Windows Update, Windows Server Update Service, and Microsoft Update Catalog. The other versions are only getting them from the catalog.
  
  For those folks that run WSUS servers, you saw a bunch of Microcode updates out yesterday. Those are JULY versions of the Microcode update, not the same as the AUGUST ones out yesterday. Notice the 2018-07 dates on the updates that came out on WSUS, not the 2018-08.
  
  
  
  Took me a while to figure out that these AREN’T the same updates even though they came out on the same day.
  
  They did come out on the C week. They are not replacing the cumulative update of August 14th.
  
  Unfortunately, I’m rating these Microcode updates as not simple.
  
  
  Windows Patches/SecurityMicrocode, Patch Lady Posts
  
  
• Patch Lady – report on the August updates
  Posted on August 22nd, 2018 at 21:46 Susan Bradley Comment on the AskWoody Lounge
  Patch Lady here and so far (with a few exceptions like the SQL update) I’m not seeing any major trending issues with the August updates.
  
  Mind you that there are still the normal issues with updates that I consider “normal”. Yes some people will have problems installing. But it’s the “normal” failure level not an abnormal level. With updating there’s always a small percentage of issues that can occur but it doesn’t mean that you or I will necessarily hit issues. That said I always say that the best way to prepare yourself for updating is having a full backup, and having another device (even if it’s an ipad or a phone) that you can google up error codes and post on askwoody.com for advice.
  
  The known issues (Edge having issues with app guard) isn’t something I’m tracking nor seeing in my personal use.
  
  For those that are Windows 7 users, if you are security only patchers, remember you will need to install both the Julyand the August updates as well as KB4345459.
  
  If anyone can find information to the contrary, that the fix is included in the August patches, please holler and let me know.
  
  I don’t see that the KB4345459 is included in the August fix. The BSOD side effect that is fixed in KB4345459 primarily was triggered by networking monitoring software that I saw more folks in enterprise reporting this side effect than I did on consumer machines.
  
  For Windows 8.1 you’ll need July, August and KB4345424
  
  I’ll let Woody give the final vote up or down, but on the business patching side, I’m flipping the main security updates for August to go ahead and install.
  
  
  Windows Patches/SecurityPatch Lady Posts

Microsoft fixes the bad cumulative update for SQL Server 2016 SP2
Posted on August 21st, 2018 at 11:36 woody Comment on the AskWoody Lounge
Overnight, Microsoft released KB 4458621, the patch that’s supposed to fix the errors in Patch Tuesday’s KB 4293807.

Per the KB article:

This update is a replacement for the update KB4293807 that was released on August 14, 2018. If you have previously applied the original update KB4293807, we recommend that you install the update KB4458621 as soon as possible.

That was fast – but if you were updating quickly (or automatically), you may have been unable to use SQL Server for a week.

Thx @abbodi86


Uncategorized KB 4293807, KB 4458621

 

Good thing I never update VS2015.

 

Pssshhht. 105 pages worth of silly and still going strong, eh?

 

Yep and all of my VPS are about to be rebooted. Just cause you bury your head in the sand doesn't mean this isn't real.