Deja-wooo-oooh! Intel chips running Windows potentially vulnerable to scary Spectre variant Spectre – a family of data-leaking side-channel vulnerabilities arising from speculative execution that was disclosed last year and affects various vendors' chips – has a new sibling that bypasses previous mitigations. Designated CVE-2019-1125 and rated moderate in terms of severity, the issue – limited primarily to Intel x86- …
I was reminded of the classic photograph that Bruce Schneier used to indicate the nature of security. Taken in winter with everything shrouded in snow, it clearly shows a country road with a stout gate built across it, blocking all traffic.
Except that the road has no hedges, fences or ditches and the picture clearly shows the tracks of scores of vehicles that have driven up to the closed gate, swerved into the neighbouring field and simply gone around it.
I know exactly which one you mean :).
One of my favourites too (just surprisingly hard to dig up on DuckDuckGo).
Now that is interesting.
On my 6-month old laptop and 3-or-4-year old desktop, there were 2 MS patches installed on my Windows 10 1903, on 10 July, one for .NET, one for security issues in the kernel. On both systems, one of them immediately started triggering MEMORY MANAGEMENT blue screens, several times a day, usually on startup when getting to the login screen on the 8GB laptop, a bit more rarely on the 16GB desktop.
They can't be uninstalled. Trying to revert to an older system snapshot borked the laptop.
Reverting to Windows 10 1809 will all patches applied, the BSOD disappeared. But it didn't look like 1809 had received the same update yet.
"Only affect windows" is a bit vague when describing a bug that isn't within the OS code itself.
So, with a bit of Googling, found this:
https://arstechnica.com/information-technology/2019/08/silent-windows-update-patched-side-channel-that-leaked-data-from-intel-cpus/ : 'Botezatu said that, while the vulnerability technically exists when affected chips run on other operating systems, it was "unfeasible" to exploit chips running Linux, Unix, FreeBSD, or macOS.'
So, I guess the jury is still out on openbsd, netbsd, chromeos, beos, reactos, os/2..... :-)
As the article states, this vulnerability is primarily a shared cloud issue. When the speculative execution engines were designed (circa early 90s), there was no thought or vision that someday we would have the large cloud shared execution hosts that we have today. Once one vulnerability was found, it was pretty clear that there would be others.
To fix this requires a serious redesign of the core CPU engines, which will take years to fully test, then propagate out and replace the existing flawed CPUs.
There was no intentional plan to create this issue, it is mainly a case of changing environments and requirements.
No, this has NOTHING to do with "the cloud".
It has EVERYTHING to do with speed at any cost, poor design and/or poor coding (values not checked).
Other machines have had similar system data segment (base) exchange routines, for example the HP3000 with the EXCHANGEDB routine, which swapped the user's data segment base with a system data segment base in order to facilitate calls to Privileged system internal routines like DIRECTFIND (or if you're in a RISCy mood, ATTACHIO). Fortunately the system had checks in hardware to see that upon return, DB was where it should be (i.e. where it was originally).
Of course, if the parameters, calling sequence, or stack are gorbled, then all hell will break loose.
But, on the HP3K (and other machines) you would be rewarded with a system failure, or a system abort, BECAUSE you needed to be in Privileged Mode (aka ring zero) and "SETCRITICAL", which means "don't abort me, and if I crash, so does the system".
No RISC, no fun, eh?
Sometimes speed kills, if you've taken off all the safeties.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
