Xen Security Advisory: x86 – mishandling of debug exceptions | Hacker News Reader

Xen Security Advisory: x86 – mishandling of debug exceptions

xenbits.xen.org

26 pointsingve15 comments

This is an issue affecting many operating systems. Linux could be DoSed. Xen PV, Windows, Mac OS, and several BSD variants were vulnerable to privilege escalation.

http://www.openwall.com/lists/oss-security/2018/05/08/4

https://news.ycombinator.com/item?id=17023531

This reminds me of the bug in very early 8086/8088 which didn't disable interrupts when switching the stack segment:

https://trixter.oldskool.org/2007/03/17/post-something-dammi...

https://www.pcjs.org/pubs/pc/reference/intel/8086/

http://www.malinov.com/Home/sergeys-projects/sergey-s-xt/his...

Isn't this why MOVSS interrupt shadowing exists?

They didn't even do the LSS instruction until the 386.

Apparently this was already patched in the previous macOS security update, but Apple updated the documentation for it with additional references to this bug only just today. I've seen them do these documentation updates a few times now, is that a recent thing? Isn't it kind-of breaking embargoes if a binary security update goes out weeks before the vulnerability is documented in public? Not sure if it's a good or bad thing... happy to be already protected, but concerned about installing updates which aren't fully documented on release and which might let bad guys discover issues early?

> Isn't it kind-of breaking embargoes if a binary security update goes out weeks before the vulnerability is documented in public?

Sort of. But it's a balancing act -- if you delay the release of a fix until the day of disclosure, users are all vulnerable to a known exploit until they patch. If you release a patch before public disclosure, chances are much better that users will update before the vulnerability is disclosed, either officially or through reverse-engineering of the patch.

This is reminiscent of the #TF CVE from last year: https://bugzilla.redhat.com/show_bug.cgi?id=1464473

... Except not requiring a buggy instruction emulator.

Traps and MOVSS shadowing (and any other temporary state after an instruction pointer increment) are very complex/bug prone, and I kinda wish x86 weren't so willing to keep adding these in (recent additions that come to mind being MTF and PEBS).

It is funny how poorly designed AMD's SYSCALL seems to be compared to Intel's SYSENTER. As a side note, I have been thinking of the removal of segmentation from x86 for a while now.

SYSENTER is also awful.

IMHO the whole amd64 was poorly designed. A misguided attempt at "cleaning up" the architecture by removing features that actually turn out to be quite useful and in active use, so much that they had to put some of those features back in later revisions (with feature bits, creating further mess):

https://www.pagetable.com/?p=25

https://github.com/dynamorio/dynamorio/issues/181

Especially in the case of LAHF/SAHF, it's not like they reused the opcode for something else --- since amd64 processors must be able to execute 16 and 32-bit code, the circuitry required to execute those instructions is there and perfectly functional; they just inexplicably become invalid in 64-bit mode. AMD could've made it far more seamless and compatible; instead they seemingly ripped stuff out without much consideration of what could be depending on it, hence the strange invalidation of certain instructions and the absurd semi-presence of segmentation.

For example, they could've made segmentation disappear completely (and certainly break more applications...) in 64-bit mode, reassigning all the opcodes related to their usage, etc.; or they could've fit 64-bit segments into the existing segmentation model, but the current "segmentation half-working" state is just bizarre.

My favorite is features from IA-64 that had to be ported to AMD64 after the fact. For example, IA-64 had two stacks. Before SYSCALL was fixed for AMD64, it was so poorly designed that the only OS I know supporting it was XP pre-SP2.

> features from IA-64 that had to be ported to AMD64 after the fact

I'm not sure what you mean by this. IA-64 was Itanium. While it did have two stacks, that feature never existed on either vendor's implementation of x86-64.

Intel CET I believe.

Would anyone mind providing some context for those of us not familiar with running enterprise grade cloud services?

I don't think you need a ton of context, it looks like a straighforward exploit for breaking out of a VM on Xen, affects most (all?) operating systems.

Reply on news.ycombinator.com