Patch Lady – Microcode updates

Topic

New Reply

Patch Lady here — Did you happen to catch this gem in this blog about the Microsoft microcode updates? “There is also a small but subtle difference b
[See the full post at: Patch Lady – Microcode updates]

Susan Bradley Patch Lady/Prudent patcher

13 users thanked author for this post.

StruldBrug, Cascadian, JDeC, AlphaCharlie, AJNorth, Elly, jburk07, Microfix, lizzytish, WildBill, abbodi86, woody

Reply | Quote

Replies

So far I have noticed on PC forums plenty of discussion on these firmware updates. Even with the one’s that have recently been released. I am staying on the sidelines for now myself with some of this until this stuff get’s really worked out.

2 users thanked author for this post.

OscarCP, Cybertooth

Reply | Quote

If there are going to be more patches like this one to come, it is not inconceivable that Microsoft will eventually deliver them via windows update so that all the non-savvy users get them as well.

From my perch I see no problem with this as long as they remain standalone KBs and not packaged inside a monthly cumulative update or for that matter a security-only update.

These updates have to be reversible. The microcode update may work like a charm, but its impact may prove problematic. As an example, only the manufacturers and OEMs know the real performance impact of spectre fixes across all the different CPU types with their associated OS/architecture.

4 users thanked author for this post.

JDeC, OscarCP, SueW, Cybertooth

Reply | Quote

Given the reliability, integrity and quality assurance of patches and device drivers over the last couple of years via WU, I’d be more than confident of updating microcode/ firmware on our systems.

And back in the real world…

 

If debian is good enough for NASA...

3 users thanked author for this post.

Seff, OscarCP, Karlston

Reply | Quote

HP rolled out a BIOS update for my Zbook workstation which addresses the vulnerabilities. In no rush to install unless and until the smoke clears and impacts evaluated. The bulletin was updated on 2/25/2018 to include the SoftPaqs and some may find the info in the bulletin of interest.

1 user thanked author for this post.

JDeC

Reply | Quote

Oddly the link didn’t attach… https://support.hp.com/us-en/document/c05869091

Reply | Quote

I do not find pushing the microcode updates out through WU all that surprising as it has become fairly clear that OEMs, particularly motherboard vendors, seem unlikely to put out BIOS/UEFI updates for hardware older than three years. On the other hand, there have been more than thirty class action lawsuits filed against Intel because of the Meltdown/Spectre CPU vulnerabilities. Intel is no doubt has incentive to appear to be addressing these vulnerabilities to neutralize potential litigation costs. Many of these lawsuits may hay contain value in setting legal precedent as the cause at action is breach of implied warranty. The ambiguous legal area comes as to whether there is an implicit warranty that covers security per se. If a court were to rule that the advertised CPU performance specifications for Intel processors had to be delivered in a secure architecture, the performance degradation caused by the Meltdown/Spectre mitigations could be considered a compensable breach of implied warranty and merchantability. I am not trying to present the merits of the argument; the point is simply Intel probably has more skin in this game than OEMs building systems with Intel hardware.

Reply | Quote

I’ve been having boot problems on my 3 Windows7 computers for the last several days.  On another site, I read that “preview” updates are the latest source of problems.  My computers would boot to the sign-in window, but get hung for several minutes and then go to black screen with fans running.  Had to do a hard restart to try again.  After a few tries, they would boot up all the way.

I located all the preview updates, KB407—-, and uninstalled them.  Restart worked on all.  Will see if get consistent starts in the future.

I have AMD processors on 2 of the computers and Intel on the other.  No more “preview” updates on my computers!

1 user thanked author for this post.

Cascadian

Reply | Quote

Welcome to the AskWoody Lounge, @bhound56 , glad you found your way here after such a disappointment. Postponing all updates until tested on other people’s hardware is the basis of Woody Leonhard’s MSDefcon rating system.

Please, if you haven’t already, stretch your legs with a walk around the AskWoody KnowledgeBase using Kristy’s handy index. In there are articles that will help you decide your personal comfort level in following a GroupB or GroupA updating method. This will help you better understand and follow Da Boss’s next article on how to apply updates. After the MSDefcon level rises.

Hope you find what you are looking for easily.

Reply | Quote

Patch Lady wrote:  “It’s never wise with firmware to be the first one to install. There is no easy way to uninstall a firmware update.”

You can argue it’s never wise to be first to install any update, but the idea that there’s no easy way to uninstall this Spectre patch for Skylake processors is not correct and seems to, again, as in the earlier thread on this, confuse a Windows hardware/microcode update with a BIOS firmware update. The Skylake Windows patch does not change BIOS. I doubt very much that it can brick a PC the way a BIOS update can, at least not if you install it in the correct OS and have the affected CPU. The patch resides and works in Windows. After installation it is listed in the Windows Update History screen and seems as reversible/uninstallable as any other Windows update there.

Hold off on this patch if you prefer, but I’ve installed this patch on my Win 10 1709 PC with an affected CPU, and it is not slowing bootup or performance or causing any other problems for me.

3 users thanked author for this post.

Cascadian, MrBrian, woody

Reply | Quote

“The patch resides and works in Windows.”

That is correct. I used CBS Package Inspector to look at the internals of KB4090007.

2 users thanked author for this post.

Cascadian, OscarCP

Reply | Quote

Anonymous, the quote in your post clearly indicates that Ms. Bradley was talking about firmware updates.  The microcode updates delivered by the OS are not firmware.   Microcode updates can be delivered by software or firmware; the ones that are packaged as OS updates are software.  “Firmware” means the BIOS or UEFI that requires flashing, and she’s right to advise people not to be the first to try one out, given the difficulties we’ve had recently.

Microcode updates are not stored by the CPU once power is cut off.  They have to be loaded into the CPU each time the system is powered on.  When the system starts from a cold boot, the appropriate microcode stored in the firmware will be loaded into the CPU.  During the boot process, control is passed from the BIOS or UEFI to the operating system, and if that operating system has a microcode update installed, it will check the loaded microcode against the one in the OS update.  If the one in the OS update is newer, the OS will unload the one in the CPU and replace it with the one on the update.  This will only last until the next time the unit is powered down, and like all things stored in volatile memory, the microcode will be “forgotten” immediately.  When the system is restarted, this entire process will happen again, each and every time.

As such, Ms. Bradley had it right as far as the advice goes, IMO.

I would add, though, that it is not universally true that firmware updates cannot easily be uninstalled.  Sometimes it is easy to uninstall a firmware update (by replacing it with an older one), while other times it’s difficult or impossible; it all depends on what arbitrary rules the OEM has put in place.  Some systems assume that newer always equals better, so they won’t let you overwrite a newer firmware with an older one, so if the firmware update proves to be a bad one, you have to wait for the OEM to release an even newer one to fix it. If the firmware update messes it up so bad that you can’t even flash it, then you’re in even more trouble.

Some systems, on the other hand, have no issue with overwriting a newer firmware image with an older one. If the firmware update messes things up, but not so badly that you can’t even flash anymore, just reflash the one you started with and get on with things.  The problem is in knowing whether you have a forgiving motherboard/computer or an unforgiving one.

Unless you have some reason to believe that your particular PC is in the more forgiving category, it’s safer to assume that the firmware update can’t be reverted, and to let other people do the beta testing of the update.  Once some time has passed and the reports of breakage and doom don’t come, then you may wish to update the firmware… until then, doing the microcode update in software is a lot safer.  If it goes wrong, all you have to do is uninstall the update (which you can do from the command line in WinRE [Windows Recovery Environment] if Windows won’t start).

Dell XPS 13/9310, i5-1135G7/16GB, KDE Neon 6.2
XPG Xenia 15, i7-9750H/32GB & GTX1660ti, Kubuntu 24.04
Acer Swift Go 14, i5-1335U/16GB, Kubuntu 24.04 (and Win 11)

4 users thanked author for this post.

StruldBrug, GoneToPlaid, Cascadian, Elly

Reply | Quote

Thank you Patch Lady for the information on how to run Chrome more securely.

I have followed the instructions with the link you posted and now I am writing this entry while using Chrome. So far, nothing remarkable, one way or another, is happening, that I can tell. In Chrome I have my ad blocker off, so I am seeing some ads. If there was something to worry about, one such thing would be something malicious lurking in ads. We’ll see.

On a separate matter, about not seeing Meltdown or Specter in the wild yet:

My real concern about them and other potential such attack malware, is not so much amateur Black Hats out there trying their hand at new evil exploits, but organized and well funded groups of professional ones run by nation states or criminal syndicates. Those are most likely not going to be aimed at yours truly, why should they waste their time with me?  To make me an involuntary botnet member, maybe? But then, at least against that, there is safety in numbers, so my odds of not being pressed into some nefarious service may not be that bad.

No, the most likely scenario is one where the key infrastructure of another country: power supply, water disposal systems, traffic control, electricity production and distribution (including from nuclear power stations), etc., etc., etc., gets targeted with cyberweapons that exploit things like the Intel chips’ flaws (and don’t even get me started on those of the embedded ARM ones!) That, of course, would create a bit more of a general problem and keep us somewhat occupied and with not that much free time to worry about similar issues affecting our own PCs.

Even without a cyberarmaggedon, there is the next step after the cyberweapons are created, tested and their existence gets whispered in the right quarters: the weaponized malware, somehow, as it tends to happen, gets leaked into the wild from their government-run cyberattack units, so now competent individual criminals and criminal organizations employing groups of Black Hats, can have a go at anyone they fancy with them.

Summing up: patch or patch not, the future blindingly bright looks not.

Ex-Windows user (Win. 98, XP, 7); since mid-2017 using also macOS. Presently on Monterey 12.15 & sometimes running also Linux (Mint).

MacBook Pro circa mid-2015, 15" display, with 16GB 1600 GHz DDR3 RAM, 1 TB SSD, a Haswell architecture Intel CPU with 4 Cores and 8 Threads model i7-4870HQ @ 2.50GHz.
Intel Iris Pro GPU with Built-in Bus, VRAM 1.5 GB, Display 2880 x 1800 Retina, 24-Bit color.
macOS Monterey; browsers: Waterfox "Current", Vivaldi and (now and then) Chrome; security apps. Intego AV

Reply | Quote

Oscar, the Meltdown and Spectre vulnerabilities do not present the threat of a given PC being made into part of a botnet.  To do that, a given threat or exploit would have to include the possibility of execution of arbitrary code, which is a term you’ll see a lot in descriptions of malware.  “Arbitrary code” is just a  shorthand way of saying “anything the attacker wants to run on your system.”

Spectre and Meltdown do not include this threat.  They merely pose the threat that privileged memory can be read by unprivileged processes (ordinary user-level programs running on the PC), which is not supposed to happen.  This is a less severe threat than one that can allow execution of arbitrary code, but they have other aggravating factors that make them potentially dangerous in a different way.  They can be exploited via javascript, so just visiting a web page that has an evil script on it can expose you to the threat, and if the bad script managed to grab some important data it should not have been able to, there would be no sign that it ever happened.  You’d never know.

Because of this, browser developers are working on means to thwart the exploits from being able to steal data via javascript.  From what I have read, the javascript that uses these exploits should be fairly easy to recognize heuristically (in other words, if one knows what to look for, the attempts to use the exploits look very suspicious and are easily seen as such).  I think the “fix” for this is going to end up being solved that way (one of the Spectre variants has no known fix at this time, on any system).

Dell XPS 13/9310, i5-1135G7/16GB, KDE Neon 6.2
XPG Xenia 15, i7-9750H/32GB & GTX1660ti, Kubuntu 24.04
Acer Swift Go 14, i5-1335U/16GB, Kubuntu 24.04 (and Win 11)

1 user thanked author for this post.

Elly

Reply | Quote

Meltdown/Specter could indirectly lead to malware execution because they could expose information that makes the difference between successful and unsuccessful exploitation.

Reply | Quote

From Meltdown and Spectre: Where the Real Risks Lie:

“Meltdown and Spector are information leakage vulnerabilities as opposed to code execution vulnerabilities. But does the threat really stop at information leakage?

Despite the narrow focus of current media reports, the real risk behind the vulnerabilities in CPUs is not primarily data theft.  Although stealing passwords and other sensitive data from memory is a serious hazard, the bigger problem is that the flaws expose memory structures that can easily be used by cybercriminals for massive, successful exploitations and breaches. In other words, information Meltdown and Spectre harvest could later be used as a pre-stage to remote code execution. Most frequently, memory leakage vulnerabilities are leveraged by cybercriminals as a way to bypass ASLR in an exploitation chain.

Cybersecurity is a perpetual battle to keep attackers from exploiting systems that provide an entry point for their malicious activity. Various defense mechanisms prevent them from understanding the memory structure of their target. This knowledge is crucial for attacks to inject malicious code into the right places seamlessly. The Meltdown and Spectre vulnerabilities potentially expose the internal memory structure for cybercriminals to utilize at will. We expect to see many more exploits in the near future.”

5 users thanked author for this post.

GoneToPlaid, AJNorth, OscarCP, woody, Cascadian

Reply | Quote

I think that they’re getting way ahead of themselves here.  We haven’t even seen what a Spectre or Meltdown attack would look like in the real world, and that blog is already extrapolating to the next level of speculation of what it could mean– and claiming how their own paid service is already protecting people against these threats that haven’t even happened yet.  It’s a sales pitch.

If anyone, whether their intent is good or ill, wants to understand how ASLR works in Linux, all he needs to do is go get the source code and read it.  The blog post makes it seem that ASLR is such a huge mystery that the baddies are just itching to crack, and that these new exploits may just give them the info they need to defeat it once and for all.  What more can they learn than by looking at the source code itself?

Even in Windows, there are better ways to reverse engineer ASLR than using a vulnerability on someone else’s system, which is what the post seems to be saying the bad guys will do.  Researchers run malware tests in specialized virtual machines that have control over each bit of memory, and they can analyze every move the malware process tries to make.  There’s no special distinction between malware code and Windows code; the same analysis techniques work equally well on both.  I think it’s safe to say that the schema of ASLR in Windows is well-understood by people who wish to defeat it, even if MS keeps their source code tightly controlled (which, of course, they do). If knowing how it worked was in effect getting the keys to the castle, it would already be quite useless.

Even if ASLR is compromised on a specific individual machine (rather than the broader “I know how it works so it isn’t effective anymore” way that the blogger suggested) by leaking the locations of specific DLLs or executables in memory, the processes with kernel privileges are still in protected memory.  Knowing where they are in protected memory doesn’t grant write privileges; a second, distinct exploit (such as a buffer overflow) would also be needed to inject arbitrary code into the protected memory space of a privileged process or library.  That exploit would be the one I’d be more worried about.

If the hoopla over the Meltdown and Spectre vulnerabilities was overblown, and I think it was, at least we can say that there have been working proofs of concept.  Until we get to the point where someone develops a proof of concept that allows one of those proven but as yet not extant vulnerabilities to get to the point of remote code execution, it’s not yet a concern.  Maybe someday it will be, but it’s just as likely to be some other, completely unrelated thing that scares the heck out of everyone next time.  Once we get to the point of this or any other thing being a real threat, if ever, mitigation strategies and patches will appear, and then we can evaluate the threat to ourselves and to others.  For now, there’s no threat of Spectre or Meltdown doing anything beyond read privilege escalation.

Dell XPS 13/9310, i5-1135G7/16GB, KDE Neon 6.2
XPG Xenia 15, i7-9750H/32GB & GTX1660ti, Kubuntu 24.04
Acer Swift Go 14, i5-1335U/16GB, Kubuntu 24.04 (and Win 11)

Reply | Quote

@Ascaris: Your post seems to be address Meltdown. Let’s consider Spectre variant 1. From https://www.renditioninfosec.com/files/Rendition_Infosec_Meltdown_and_Spectre_20180108.pdf:

“A large number of browser vulnerabilities are not practically exploitable because of user space ASLR

–ASLR and DEP have substantially limited browser exploitation

Spectre can be used to determine the address of a module in memory and bypass ASLR (ushering in the new age of practical browser exploitation)”

Reply | Quote

OscarCP describes a possible distant goal, for one narrow set of bad actors.
Ascaris properly restricts the discussion to the small scale vulnerability exposed by each individual speculative attack.
MrBrian demonstrates with references the possible scenario that may lead from Ascaris’s proper description to larger exploits that could include those described by OscarCP.

This is much where we were in the 2nd week of January, I think. But with better references.

2 users thanked author for this post.

Cybertooth, OscarCP

Reply | Quote

Thank you all for your thoughtful and informed comments.

I was using Meltdown and Specter to make a wider point about the possible exploitation of inevitable flaws in computing hardware and software by well organized and competent criminals. For example, flaws that may begin as intended desirable features, as in the case of speculative computing in CPUs, but make machines vulnerable to clever malicious attacks because of the way they are implemented.

And on the software side, it bothers me that JavaScript can be used to infect computers with malware, as JavaScript, unlike Java, is not something one can do without, just like that, by disabling it in one’s machine. So tools to prevent attacks exploiting it have to be developed, installed and used, which means spending time and effort on this that could be used for better things, and worries one could do without.

Ex-Windows user (Win. 98, XP, 7); since mid-2017 using also macOS. Presently on Monterey 12.15 & sometimes running also Linux (Mint).

MacBook Pro circa mid-2015, 15" display, with 16GB 1600 GHz DDR3 RAM, 1 TB SSD, a Haswell architecture Intel CPU with 4 Cores and 8 Threads model i7-4870HQ @ 2.50GHz.
Intel Iris Pro GPU with Built-in Bus, VRAM 1.5 GB, Display 2880 x 1800 Retina, 24-Bit color.
macOS Monterey; browsers: Waterfox "Current", Vivaldi and (now and then) Chrome; security apps. Intego AV

Reply | Quote

Malwarebytes’ Anti-Exploit Beta (the free version for consumers) was just updated to version 1.12.1.37 Beta; it is configurable, and can mitigate both DEP and ASLR exploits in browsers. (The Softpedia listing is at  http://www.softpedia.com/get/Security/Security-Related/ExploitShield-Browser-Edition.shtml.)

Utilizing such browsers that are also running at least NoScript and uBlock Origin together ought to be able to protect the OS (and therefore data and other applications) from infection or manipulation.

Adding complete isolation from the OS to such hardened browsers by operating them strictly in a sandbox (such as Sandboxie) should provide an effective (and synergistic) level of protection greater than either individual part. (The Softpedia listing is at http://www.softpedia.com/get/Tweak/Browser-Tweak/Sandboxie.shtml.)

For those Windows boxes with sufficient resources, this approach should have slight, if any, negative discernible effects.

Question: would this be an effective strategy against Meltdown & Spectre for the current generation of machines not specifically patched against them?

2 users thanked author for this post.

StruldBrug, OscarCP

Reply | Quote

This sounds like it would be effective, so long as you are also running web browsers which have been updated to no longer allow javascript memory pooling and which also provide less accurate javascript timing resolution.

3 users thanked author for this post.

StruldBrug, OscarCP, AJNorth

Reply | Quote

Patch Lady, if you still get to see this, now that the action has moved on to post-February patching:

As I mentioned earlier in this thread, have installed the feature you recommended in Chrome, to make it safer accessing Web sites with it, and everything is still looking good, having noticed no problems.

Follow-up question: Is there some thing like this, very easy to implement, also in, or as an add-on for, E11, Waterfox or Firefox?

 

Ex-Windows user (Win. 98, XP, 7); since mid-2017 using also macOS. Presently on Monterey 12.15 & sometimes running also Linux (Mint).

MacBook Pro circa mid-2015, 15" display, with 16GB 1600 GHz DDR3 RAM, 1 TB SSD, a Haswell architecture Intel CPU with 4 Cores and 8 Threads model i7-4870HQ @ 2.50GHz.
Intel Iris Pro GPU with Built-in Bus, VRAM 1.5 GB, Display 2880 x 1800 Retina, 24-Bit color.
macOS Monterey; browsers: Waterfox "Current", Vivaldi and (now and then) Chrome; security apps. Intego AV

Reply | Quote

Toggling the ‘javascript.options.shared_memory’ entry to ‘false’ with the built in ‘about:config’ interface with Waterfox & Firefox may also help. This Reddit post does contain a link to Mozilla’s Bugzilla entry which requests the implementation of site isolation. However it has been placed into the the backlog of work yet to be done. Mozilla does appear to be moving towards working on adding Site Isolation code.

Site Isolation addition by using an add-on does not exist right now, it really requires reworking, rewriting and adding code.

1 user thanked author for this post.

MrBrian

Reply | Quote

The possible performance hit resulting from the combination of W10 OS updates in conjunction with microcode updates is something I want to avoid for the most demanding tasks (DAW & Database applications). I am thinking about the following strategy and wonder how others feel about it:
> Manually disable Spectre Variant 2 “Branch Target Injection” mitigation via registry settings (scripts or e.g. InSpectre tool from Steve Gibson) and reboot whenever a performance session is desired (i.e. similar to choosing high performance mode). During these sessions no use of internet browser. Re-enable the mitigation at end of session.

What is your opinion about such a strategy and would there be any difference between permanently upgrading the microcode via BIOS vs dynamically loading it via Windows (I am leaning towards the latter as it may allow to use the older microcode by uninstalling the corresponding Windows KB in case Microsoft ever decides to eliminate the registry switches). Thanks you for your insights / opinions.

Reply | Quote

I think this is a workable strategy.

Regarding “any difference”: I believe that the answer is no. I think updating the microcode via Windows is also a good strategy.

Reply | Quote

Thank you @MrBrian. I am on Broadwell E and the preliminary performance results after microcode update & Win10 look pretty bad for certain tasks. There is a microcode update available for  my motherboard but I will stay put and wait if Microsoft will come up with a dynamic microcode update at boot. At this point it is only available for Skylake and newer but I anticipate they will also include older CPU architectures (I guess Intel will push heavily for this distribution channel as 90% of users won’t update microcode manually via BIOS). If it is not released any time soon (say May) I may bite the bullet and update via BIOS.

My biggest concern is that Microsoft will at some point in the future deprecate the ability to disable the Spectre V2 mitigation, i.e. having the kernel always use the new BTI commands and thus force us to live with slow machines rather than allowing the user to take control manually. Changing the registry settings via a little script and rebooting is something I feel is acceptable when running performance critical applications. Obviously you could still have prior installed malware lurking for those times when you disable protection but then it really depends on what you are doing when protection is off. As long as your high performance applications do not comprise really critical data like your bank account login etc this would be an acceptable risk. It would also boil down to the question how likely attacks would be that install “sleeper” malware constantly trying to fetch protected data and then finally hitting you when protection is off. In my opinion the more likely scenario are browser sessions with Java script – and for those you would anyway keep protection on.

Reply | Quote

Grp B ASUS Sandy Bridge i3 W7 x64 Home
I just pulled down Steve Gibson’s newest InSpectre release #8 which does a microcode availability check. Intel Has reported the i3 in production for several weeks, but nothing from ASUS, yet. At least Steve tells me something is out there now.
https://www.grc.com/inspectre.htm

1 user thanked author for this post.

MrBrian

Reply | Quote

when it comes to AMD and new Microcode Updates, read these pages from AMD’s web site:
https://www.amd.com/en/corporate/security-updates#paragraph-290416
https://developer.amd.com/wp-content/resources/Architecture_Guidelines_Update_Indirect_Branch_Control.pdf

looks like AMD is also doing the same thing as Intel – releasing new microcode updates to manufacturers using AMD processors dating back to 2011. at least the Bulldozer series of AMD CPUs will be getting new microcode updates.

1 user thanked author for this post.

MrBrian

Reply | Quote

See also https://www.askwoody.com/forums/topic/meltdown-and-spectre-from-a-windows-users-point-of-view/#post-184121.

Reply | Quote