dencorso

XP (Intel Celeron M380)? That's a 90nm Dothan from 2005! It's *not* vulnerable to either Meltdown or Spectre (both variants) and it does have SSE2, so it crashes on some other point or actually due to the exploit failure. Relax, you have no reason at all for worrying. \m/

+1

Spectre.exe is a 64-bit executable. Now, spectre-meltdown-vulnerability-windows-test.exe does run on XP SP3 all right (provided the processor has SSE2, of course!). What part of... ...did you fail to understand?

And why not all the way to CP/M? Because you lose functionality. Things you need won't run, etc. Then again, nobody ever had a BSOD on a typewriter...

Using a fridge magnet is a way of satisfying that requirement.

You do underestimate MSFN's members diehardness, don't you? Search, and you'll find: <Link1> <Link2>

Yes. Supermegaüberultraparanoid are metastable (when they work) and may be too much of a good thing, perhaps?

This sure is a ginormous janfu! In any case, even if Intel gets its act together, I doubt they'll ever release BIOS updates for any processor older than the currenly supported ones (and maybe the latest to reach EoL, too, those being the 6th gen ones). Every user of any previous processors is on his/her own, no matter what Intel releases. Not very bright as a perspective, but thankfully most of this Meltdown/Spectre talk is FUD, anyway... And may be a heaven-sent (?) way to get people to upgrade hardware, provided they come up with something "safe," before eventually crashing & burning for the lack of it.

They do not. The issue in question only happens in Microsoft Update, which is a totally different beast than Windows Update.

Well, for those running XP SP2 with IE6, there are no more updates at all, so that using MU is moot.

I can see you haven't searched this forum... Read this <link>.

Yes. It is.

At present I think treating it as FUD is the best option. Two of the variants require direct access to the machine to compromise it. The other one is more serious: while Windows (any NT 5.x+ AFAIK) is immune to it, browsers and JavaScript inside them (and maybe Java, too) may not be. So: using safe browsers and up-to-date Java (or no Java), should keep common people safe enough. Big corporations are surely at risk, though, it's a question of cost/benefit ratio, obviously. BTW, I doubt there'll ever be a BIOS update for my IvyBridges... if I had to bet, I'd bet on Intel leting owners of older processors out in the rain. Their rep is tarnished already, you know... Give the attachment below careful consideration, and see whether you agree with me or not.

Yes. And no patches to any x86 Windows yet (or forevermore?).

Hopefully @blackwingcat will again create modified installers for Java 8. I hope the problem is just the installer, like in the past.

In any case, take such software from Steve Gibson with more than one grain of salt... he's been involved in too many controversies to be trusted blindly.

You will have to download the new 7z file when a new update gets released.

That's how I got the 1st error.

Nah. It's just way slower than usual... nothing to worry about, though. OTOH, here you go: KB969262.pdf

Yes. it's in the $NtUninstallKB4056615$ folder (which may be hidden). After you revert the 5.1.2600.7392 version to the 5.1.2600.5512 version by hand, then you can apply, if you want, KB969262 (here, too, the KB article is gone but the actual HotFix remains available by request from MS) to get to 5.1.2600.5782. But this last step is optional. N.B.: MDGx's MS Support HotFix Request Form remais the easiest and most strightforward way to request HotFixes.

Even having reversed ntfs.sys, myself, that's my take on it and the reason I kept the newst kernel files. If, and when, MS releases a newer version, then I'll update them again. But until I observe any issue with the kernel files, I'm keeping them.

Source: http://www.enisa.europa.eu/publications/info-notes/meltdown-and-spectre-critical-processor-vulnerabilities

@erwanl: Welcome to MSFN! It's great to have you around!

Curiouser and curioser!!! Those download addresses yield installers signed with SHA1. However, the default locations (below) yield instead installers signed with SHA256, which are seen as invalid by Win XP SP3. On stripping the signatures from both, the remaining installers are binarily identical. This means adobe is creating installers with both types of signatures, nowadays!!! By default locations I mean those: Internet Explorer ActiveX: http://fpdownload.adobe.com/pub/flashplayer/latest/help/install_flash_player_ax.exe Mozilla Firefox NPAPI (also for Opera Presto/Google Chrome 44 and earlier): http://fpdownload.adobe.com/pub/flashplayer/latest/help/install_flash_player.exe Google Chrome 45 through 49 PPAPI: http://fpdownload.adobe.com/pub/flashplayer/latest/help/install_flash_player_ppapi.exe I didn't, however, find any address yielding the "uninstall_flash_player.exe" signed with SHA1, instead of with SHA256...

I've just got the "This security identifier cannot be applied to the owner of the object", so I, too, can confirm that issue. Interesting it happened on an NTFS partition used by Win 7 Ult SP1 x64, but didn't on another NTFS partition used by Win 7 Ult SP1 x86, go figure! So I put back the just the ntfs.sys v. 5.1.2600.5512, while keeping the updated kernel files and the problem have been solved. It's crystal clear, by now, that the ntfs.sys v. 5.1.2600.7392 is flawed! The workaround, however, is simple and easy to perform (from outside windows, of course, like from another boot partition or a live-linux CD, for instance).