The mess behind Microsoft’s yanked UEFI patch KB 4524244

Topic

New Reply

Yes, Microsoft signed the buggy Kaspersky bootloader/rootkit. But there’s a good reason why. And Kaspersky is quite justified in saying the problems w
[See the full post at: The mess behind Microsoft’s yanked UEFI patch KB 4524244]

1 user thanked author for this post.

abbodi86

Reply | Quote

Replies

Tripe is probably not the best word choice here. After all, some people eat tripe.

I’d like to propose … $#!+.

Byte me!

1 user thanked author for this post.

Norio

Reply | Quote

Ah, menudo. Breakfast of the gods.

1 user thanked author for this post.

Norio

Reply | Quote

Was there supposed to be an external link included with this post?

1 user thanked author for this post.

ryegrass

Reply | Quote

Yes, this one.

1 user thanked author for this post.

woody

Reply | Quote

I love Woody’s sense of humor… no actual information to help us understand… just like Microsoft.

Reply | Quote

Ooops. Need another cup of coffee….

1 user thanked author for this post.

Mark

Reply | Quote

Based on what I’ve been able to glean so far, the affected HP machines  have a feature called “Sure Start”, which appears to be an additional layer of security on top of the normal Secure Boot.  One of the features of Sure Start is apparently to detect unauthorized tampering with the secure boot keys.  It sounds like the revocation list doesn’t get updated very often, so I wonder if HP’s method for detecting tampering might be flawed in some way?

1 user thanked author for this post.

woody

Reply | Quote

woody wrote:

What did Kaspersky do wrong?
Nothing. Other than distributing a Kaspersky Rescue Disk program, prior to August 2019, that could be used for nefarious purposes.

Sure. Why should a security vendor follow the rules that would prevent its free image being downloaded to attack any Windows computer?

woody wrote:

, but this older version of the Kaspersky Rescue Disk didn’t follow the Secure Boot rules.

Reply | Quote

So why did Microsoft approve it in the first place?  Seems to me there’s plenty of here blame to be leveled at both parties.

1 user thanked author for this post.

woody

Reply | Quote

Yes. It was just the “What did Kaspersky do wrong? Nothing.” that seemed inappropriate to me.

Reply | Quote

Consider that my tongue may well have been firmly in cheek. Re-read the sentences with a more… skeptical… point of view.

1 user thanked author for this post.

b

Reply | Quote

As quoted by Woody

Let’s hope the “improved version” works better than the old one — and that it takes less than ten months to respond to the problem. Meanwhile, ValdikSS warns in a tweet:

At least 2 other vuln bootloaders exist, not revoked.

More to come.

Just because you don't know where you are going doesn't mean any road will get you there.

Reply | Quote

woody wrote:

Yes, Microsoft signed the buggy Kaspersky bootloader/rootkit. But there’s a good reason why

Let me understand :

Every single version (all 1000 ) of live Linux that can boot a PC, every version of backup software that creates a restore media to boot into a PC… and those are (rootkit) bootkit, all are signed by Microsoft as safe ?

Reply | Quote

Microsoft offers to sign third-party bootloaders, and I think a few Linux distros have taken them up on that offer.  MS has two private keys they use for signing bootloaders:  one for the Windows bootloader and one for third-party operating systems.  If your distro or OS of choice isn’t signed by MS, then you have to disable Secure Boot in order to boot it.  I think most x86/x64 based PCs allow you to disable secure boot, but ARM-based WinRT devices don’t.

Reply | Quote

VladikSS has a much more detailed description of Linux and UEFI busting in the referenced blog post.

Reply | Quote

Hewlett-Packard has just released a support article regarding the yanked KB4524244 update on affected HP machines:

https://support.hp.com/us-en/product/hp-elitebook-735-g5-notebook-pc/18804892/document/c06572866

1 user thanked author for this post.

woody

Reply | Quote

Interesting. They came out and said it plainly:

To prevent this issue from occurring, do not install KB4524244

Other than that, I wish they gave us more details!

Reply | Quote

The HP article is interesting… After saying that you can prevent the issue by not installing the update, they also provide recovery steps for those who already installed the update.  Their instructions are a bit confusing because there seem to be some details missing.  But from the sounds of things, the “Sure Start” feature has some sort of real-time protection that blocks the Windows update process from modifying the revocation list during the reboot.  They advise temporarily turning off the “Sure Start Secure Boot keys protection” feature to allow the update to install and then re-enable the protection feature afterwards.  That recovery procedure doesn’t contain any steps to uninstall KB4524244 afterwards, so I guess they’re implying it’s okay to leave it installed once you manage to get past the Sure Start protection feature?

Reply | Quote

Why this continuing comedy of errors from MS and are there actual humans in the loop when approving all that is related to Key Signing/Key Authority. And hopefully there will be some more humans upstream with the key vetting/certification process so the end user humans downstream experience less pain.

With that Key Signing Authority comes some very serous  Key Signing Responsibility and maybe MS needs to be required to act more like an actual authority and not skimp on the QA/QC is that part of the chain of trust.

Reply | Quote