Multiple OS Vendors Release Security Patches After Misinterpreting Intel Docs (bleepingcomputer.com) 81
Almost all major OS vendors released security patches yesterday after a researcher discovered that some OS makers have misinterpreted an Intel CPU debug feature and left their systems open to attacks. From a report: The vulnerability is in how the OS vendors implemented a hardware debug mechanism for Intel x86-64 architectures -- and more specifically the MOV SS and POP SS instructions. "In certain circumstances after the use of certain Intel x86-64 architecture instructions, a debug exception pointing to data in a lower ring (for most operating systems, the kernel Ring 0 level) is made available to operating system components running in Ring 3," the CERT/CC team explained in an advisory published yesterday. Explained in layman's terms, "this may allow an attacker to utilize operating system APIs to gain access to sensitive memory information or control low-level operating system functions." Operating systems that mishandle this debug exception and had their systems open to attacks include Apple, Microsoft, FreeBSD, Red Hat, Ubuntu, SUSE Linux, and other Linux distros based on the Linux Kernel -- which is also affected.
Linux distros based on the Linux Kernel (Score:1)
yes there used to be one based on a BSD kernel, but now-a-days ???
Re: (Score:2)
Windows Subsystem for Linux? SmartOS LX Branded Zones?
Re: (Score:2)
Re: Linux distros based on the Linux Kernel (Score:4, Informative)
This is still a thing. https://www.debian.org/ports/k... [debian.org]
Wow ... (Score:5, Insightful)
That must have been some seriously badly written documentation if that many things made the same mistake.
That inspires confidence.
Re:Wow ... (Score:4, Interesting)
The documentation can be found here on page 2876 of this PDF file
https://software.intel.com/sit... [intel.com]
"6-8 Vol. 3A
INTERRUPT AND EXCEPTION HANDLING
If an interrupt or exception occurs after the new SS segment descriptor has been loaded but before the ESP register
has been loaded, these two parts of the logical address into the stack space are inconsistent for the duration of the
interrupt or exception handler (assuming that delivery of the interrupt or exception does not itself load a new stack
pointer).
To account for this situation, the processor prevents certain events from being delivered after execution of a MOV
to SS instruction or a POP to SS instruction. The following items provide details:
Any instruction breakpoint on the next instruction is suppressed (as if EFLAGS.RF were 1).
Any data breakpoint on the MOV to SS instruction or POP to SS instruction is inhibited until the instruction
boundary following the next instruction.
Any single-step trap that would be delivered following the MOV to SS instruction or POP to SS instruction
(because EFLAGS.TF is 1) is suppressed.
The suppression and inhibition ends after delivery of an exception or the execution of the next instruction.
If a sequence of consecutive instructions each loads the SS register (using MOV or POP), only the first is
guaranteed to inhibit or suppress events in this way. Intel recommends that software use the LSS instruction to
load the SS register and ESP together. The problem identified earlier does not apply to LSS, and the LSS
instruction does not inhibit events as detailed above"
Why document the MOV SS and POP SS instructions first, when the safer option is the LSS instruction.
This seems to be the problem with technology these days. We are offered a dozen different ways of doing things in C++
or assembly language, but only one way is the fastest.
Sounds not like Intel's Poor Writing/ (Score:5, Insightful)
If several unrelated Companies made the exact same error it is more likely poorly written documentation.
Re: (Score:2)
(snark)
Well, maybe he was right. In this case, the engineers were the users who lacked the discipline to test the veracity of the documentation for the closed system for which they were writing their... pfeh... OS code. Real men design microcode dispatchers.
(/snark)
AMD (Score:2)
AMD is affected too...
So, my question is:
Why a developer, developing for AMD-64 on top of AMD Hardware (think Athlon, Buldozer, Ryzen/Epyc et al) would be using an "INTEL's" Docs?
Shouldn't said developer be using AMD's documentation? If so, then, how said developer was also afected?
Re: (Score:2)
AMD is affected too...
So, my question is:
Why a developer, developing for AMD-64 on top of AMD Hardware (think Athlon, Buldozer, Ryzen/Epyc et al) would be using an "INTEL's" Docs?
Shouldn't said developer be using AMD's documentation? If so, then, how said developer was also afected?
I don't know the answer. But I believe that the AMD design is, in part, based on the early reverse engineering of one of the early Intel CPUs. It's quite possible that this issue is present in both because the instruction design is the same for both.
Re: AMD (Score:1)
the standard is literally called amd64. and people still think amd is a intel copycat.
how can people be this dense?
Re: AMD (Score:1)
Re:AMD (Score:5, Informative)
No AMD isn't affected. Intel isn't either. The problem is in software, it's the software that is affected.
AMD implements the x86 ISA which was designed by Intel and second sourced by AMD for a while. AMD then started designing their own CPUs based on the same ISA as they had a license that let them do that (as decided by a court of law). They have reverse engineered and used documented sources to make their processors compatible with those of Intel.
So if the hardware works in some specific way (with a few exceptions) then Intel and AMD will work the same. This is ignoring some processor extensions not always implemented by both companies.
Re: (Score:2)
"Why a developer, developing for AMD-64 on top of AMD Hardware (think Athlon, Buldozer, Ryzen/Epyc et al) would be using an "INTEL's" Docs?"
You don't fucking belong here. AMD and Intel cross-license all kinds of shit to each other for the x86-64 uArch.
Nursing home time for you.
Re: (Score:2)
Re: (Score:2)
No, because even children have a better time remembering than old people. That's why it's called senility, for OLD people that now forget such basic shit.
Re: (Score:2)
Re:AMD (Score:5, Informative)
TL:DR; Cross Licensing
Intel cross licensed the x86 stuff (32-bit) to AMD.
AMD cross licensed the AMD64 stuff (64-bit) to Intel.
The longer version:
Intel and AMD got tired of suing each other over patents. They have a LONG history of cross licensing agreements. They renewed it in 2001 [edn.com] and again in 2009. [zdnet.com]; AMD clarifyied the deal in 2015 [kitguru.net]
It is only natural AMD would use Intel's docs as part of the verification process for the 32-bit stuff.
You can search intel amd cross license agreement [google.com] for more info. but the agreement are (usually?) confidential.
Re: (Score:1)
Why did every software developer (well Linux, Apple, and MS) get this wrong, yet AMD got it right?
That's interesting to me, it seems like Intel and AMD share more than just docs (which makes sense, but still interesting).
Re: (Score:2)
It goes back decades to 1997. Back then, all the big workstations companies were making their own 64-bit processors; Intel, DEC (the DEC Alpha chip), Sun (SPARC) and MIPS.
DEC and Intel got into a lawsuit, and settled for $700 million. DEC was eventually split in into bits, neither of which kept the original designers.
https://www.wired.com/1997/10/... [wired.com]
https://www.extremetech.com/co... [extremetech.com]
https://www.pcworld.idg.com.au... [idg.com.au]
DEC and ARM also cross-licensed each others patents, signed before the Intel lawsuit.
Plus many
Princess Bride moment (Score:5, Funny)
You keep using that instruction. I do not think it means what you think it means.
Re: (Score:3)
Re: (Score:1)
Hello, my name is PA-RISC and you killed my architecture. Prepare to die.
Re: (Score:2)
Ahh, if only mod points went higher than 5.
Understandable (Score:2)
Intel probably just had the same guy that drafted the spectre/meltdown response press release write the document and he was kind of on a roll with the whole misdirection thing.
Re: (Score:1)
What I don't get about spectre, meltdown, and now this- is why any *single user* computer cares about accessing the user's own data, regardless of what ring they are in.
Isn't this only a problem for servers and multiple user computers? Why patch user level OS for this?
Re:Understandable (Score:5, Informative)
Not at all. You may be the only human user on your system but every day you bring untrusted data and actually programs onto your computer in the form of web pages. With these vulnerabilities, a rogue JavaScript program running in a web site could grab your passwords sitting in memory for other processes. In fact one of the meltdown exploits first demonstrated was in JavaScript. So it's a bigger deal than you think and it does affect you even though you don't run a server and are the only user on your computer.
Re: (Score:2)
What I don't get about spectre, meltdown, and now this- is why any *single user* computer cares about accessing the user's own data, regardless of what ring they are in.
Isn't this only a problem for servers and multiple user computers? Why patch user level OS for this?
For a variety of reasons. For one thing, the same kernel may be used in both single and multi-user environments. For another, what’s the point of having a root account, with sudo, or UAC, or whatever your access restriction is if a malicious program can easily circumvent those protections and operate at ring -1 or whatever ring that exception is handled at? Just remember that even a single-user may not realize what instructions are being executed on their machine through javascript, or some piece o
Re: (Score:3)
What I don't get about spectre, meltdown, and now this- is why any *single user* computer cares about accessing the user's own data, regardless of what ring they are in.
Isn't this only a problem for servers and multiple user computers? Why patch user level OS for this?
Because while you may think your computer is "single user", if you are on the Internet (well the Web anyway), there are other "users" actually using your computer. These "users" are things like scripts running on web pages and any malware that you may have obtained. Sure the "user" isn't another person, but it is a process or may come from an actor that may not have good intentions. The same is actually true for any software that you install and didn't write yourself (which is most of it.) Because of this e
Re: (Score:1)
Isn't that why you browse with Lynx and turn off scripting?
Re: (Score:2)
The "users" of the computer are the various chunks of code running on it and, ultimately, whoever they phone home to.
Unless you audit and understand all code running on your system, you have to prevent programs from being naughty and reaching into some other program's cookie jar.
Operating systems that mishandle... (Score:2)
Operating systems that mishandle this debug exception and had their systems open to attacks include Apple, Microsoft, FreeBSD, Red Hat, Ubuntu, SUSE Linux, and other Linux distros based on the Linux Kernel -- which is also affected.
Apple, Microsoft, and Red Hat are not operation systems ;-)
Also, I think most Linux distros are based on the Linux Kernel.
Re: (Score:2)
NetBSD and OpenBSD "Not Affected" (Score:2)
Re:NetBSD and OpenBSD "Not Affected" (Score:5, Informative)
Yeah, looked for OpenBSD and wasn't all that surprised that they weren't affected. Theo is a bit of a douche to work with but he's usually right when it comes to security. OpenBSD also wasn't vulnerable to Meltdown and the OS level variants of Specter because he was already paranoid about cache flushing when thunking between rings due to an earlier Intel bug that he didn't believe was correctly addressed.
Re: (Score:2)
Oh yeah? And what about your cozy little problem with Linux compatibility you Mormons!
Mormons are fully Linux compatible. Some of them even use BSD.
To be fair (Score:5, Interesting)
If the custodians of every major OS misinterpreted the same document in the same way, shouldn't we consider that the document itself is suspect / at fault instead?
Re: (Score:1)
If the custodians of every major OS
Windows isn't on the list, but I don't know if that means it's definitely not affected.
Re: (Score:3)
I've heard that Windows is the name of Microsoft's Operating System.
Could be fake news, I guess? Maybe Russians al up in ur nets?
Re: (Score:2)
" Operating systems that mishandle this debug exception and had their systems open to attacks include Apple, Microsoft, FreeBSD, Red Hat, Ubuntu, SUSE Linux, and other Linux distros based on the Linux Kernel"
I'm pretty sure Windows falls under the 'Microsoft' category.
What about Windows? (Score:1)
Given that Windows - by far and away the most-used operating system - isn't on the list, are we supposed to assume it's safe?
A confirmation either way would be nice, given the seriousness of the problem.
Re: (Score:2)
There's nothing wrong with my reading comprehension. It's my reading itself that needs work...
Re: (Score:2)
"Operating systems that mishandle this debug exception and had their systems open to attacks include Apple, Microsoft, FreeBSD, Red Hat, Ubuntu, SUSE Linux, and other Linux distros based on the Linux Kernel"
It's safe to assume that Windows falls under the 'Microsoft' category.
fip (Score:2)
Oh, NOW I get it. (Score:1)
@msmash: I, for one, laud your biddable rectitude anent proffering pleonasm-eschewing elucidationary paraphrasing. Kudos!