Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Multiple OS Vendors Release Security Patches After Misinterpreting Intel Docs

bleepingcomputer.com

Post reply on HN
Print view View original

51–60 of 94 posts

Re: Multiple OS Vendors Release Security Patches After Misinterpreting Intel Docs

#51

Post by hedora »

darkerside wrote: post #2

I'm sure the initial reaction here is going to be lamentation about the state of documentation. People will correctly point out that, if multiple entities misread the documentation, it just have been unclear. And they are right. But that doesn't make this Intel's fault alone. Clear or unclear, the documentation described behavior that was understood at the Intel organization, and the shipped product worked as describ…

This mentality is why I like OpenBSD.

If they can’t sign off on the security/correctness of a pile of code, they delete it, even if it means losing functionality.

In this case, they simply didn’t invoke the incomprehensible instruction of doom.

Re: Multiple OS Vendors Release Security Patches After Misinterpreting Intel Docs

#52

Post by Tobba_ »

simion314 wrote: post #29
darkerside wrote: post #2

I'm sure the initial reaction here is going to be lamentation about the state of documentation. People will correctly point out that, if multiple entities misread the documentation, it just have been unclear. And they are right. But that doesn't make this Intel's fault alone. Clear or unclear, the documentation described behavior that was understood at the Intel organization, and the shipped product worked as describ…

If you can't trust the CPU documentation how can you test that addition works? even if you could test all possible combinations of terms to add and verify the results there may be a hidden flag somewhere that when flipped will change how addition works.

On that subject, I'm curious whether there is any CPU out there that sets the overflow flag incorrectly when computing (-1) - n when n is the most negative number (which negates to itself, so implementing subtraction by simply negating the RHS and adding will screw up the flags).

Re: Multiple OS Vendors Release Security Patches After Misinterpreting Intel Docs

#54

Post by hyperman1 »

I wonder what happens if you execute multiple POP SS instructions. In fact, you could set up a 64K v86 mode segment containing only copies of the POP SS instruction. jmp far into it. When IP reaches the last instruction it wraps around and starts again. Will it ever be interrupted by anything? If the stack usage bothers it, just do MOV SS,AX

Re: Multiple OS Vendors Release Security Patches After Misinterpreting Intel Docs

#55

Post by shawnz »

Someone wrote: post #36
codedokode wrote: post #30

Earlier quoted context omitted.

> To fix this, the CPU has a wild card: When you change SS, you get exactly 1 instruction that will not be interrupted. The idea is you use that instruction to change (e/r)SP and make the stack valid again. If there is a need for an interrupt, it will be delayed for 1 instruction. I wonder, why could not they make a single instruction to change both SS and SP?

They could, but attackers would still use the approach that works for them. And they can’t really remove the old instructions because of backwards compatibility. Whitelisting a limited set of instructions that can follow setting SS and making all others trap might be an option, though. It still would break backwards compatibility, but if the effective impact would be negligible, they could deem it acceptable.

They could only do the interrupt disabling behaviour if the next instruction is in the whitelist, but not otherwise.

EDIT: Although I guess it's almost certain to be an error anyway if it's not a whitelisted instruction.

Re: Multiple OS Vendors Release Security Patches After Misinterpreting Intel Docs

#56

Post by hannob »

erric wrote: post #3

Wow, the article shows that many vendors mis-read the docs: Apple, Microsoft, FreeBSD, Red Hat, Ubuntu, SUSE Linux, and other Linux distros...as well as VMware and Xen. This is going to be a busy day!

> Apple, Microsoft, FreeBSD, Red Hat, Ubuntu, SUSE Linux, and other Linux distros.

Just to clarify, this is kernel code. Listing 3 different (+ "other") Linux distros as affected is kinda bogus, it's not that they all made the same mistake, they just all use the same kernel.

Re: Multiple OS Vendors Release Security Patches After Misinterpreting Intel Docs

#57

Post by sxcurry »

hannob wrote: post #56
erric wrote: post #3

Wow, the article shows that many vendors mis-read the docs: Apple, Microsoft, FreeBSD, Red Hat, Ubuntu, SUSE Linux, and other Linux distros...as well as VMware and Xen. This is going to be a busy day!

> Apple, Microsoft, FreeBSD, Red Hat, Ubuntu, SUSE Linux, and other Linux distros. Just to clarify, this is kernel code. Listing 3 different (+ "other") Linux distros as affected is kinda bogus, it's not that they all made the same mistake, they just all use the same kernel.

Also, Apple and Microsoft are not an “OS”. This is a poorly written article unfortunately.

Re: Multiple OS Vendors Release Security Patches After Misinterpreting Intel Docs

#59

Post by Someone »

Sgt_Apone wrote: post #14
erric wrote: post #3

Wow, the article shows that many vendors mis-read the docs: Apple, Microsoft, FreeBSD, Red Hat, Ubuntu, SUSE Linux, and other Linux distros...as well as VMware and Xen. This is going to be a busy day!

Speaking as a technical writer, if that many vendors misinterpreted the documentation then it was the fault of the documentation.

It also could be innate complexity of the thing being documented. Looking at https://software.intel.com/en-us/articles/intel-sdm, the combined PDF has 4.844 pages.

Re: Multiple OS Vendors Release Security Patches After Misinterpreting Intel Docs

#60

Post by jey »

amluto wrote: post #43
dwighttk wrote: post #32

The vulnerability notes[1] say Apple patched this on May 8, but my last security update was May 3 and I don't currently show any available updates... I wonder if the May 3 patch fixed this, or if my computer might not be affected. [1] https://www.kb.cert.org/vuls/byvendor?searchview&Query=FIELD...

The May 3 patch fixed it. The nature of the fix was such that Linux and Mac OS were able to patch it early without revealing much. In fact, the Linux fix was a patch I wrote in 2015 (for unrelated reasons) and just never got around to upstreaming.

Link to referenced patch: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
Post reply on HN