41–50 of 94 posts
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!
And in Germany it's national holiday. Really great.
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 probably could, but it would have had a large silicon cost for 1980 without performance benefit. That and ISA incompatibility.
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...
In fact, the Linux fix was a patch I wrote in 2015 (for unrelated reasons) and just never got around to upstreaming.
Interesting that some of the BSDs (Dragonfly, FreeBSD) are listed as Affected and others (NetBSD and OpenBSD) are listed as Not Affected.
Dragonfly descends from FreeBSD so it makes sense that it's affected. The other BSD's have different kernels and vastly different development histories as well.
Is there a PoC exploit source?
Earlier quoted context omitted.
Why can't there be automated test suites that catch unauthorized access issues before ship (if not before merge commit)? Usually the search space is too large.
Isn't that what fuzzing is for?
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 probably could, but it would have had a large silicon cost for 1980 without performance benefit. That and ISA incompatibility.
Maybe they dindt think about it, and fixed it with a quick hack once they got aware of the problem? The whole segment register story was very hacky from the start.
Intel might have dumped the segment registers in i386 32 bit protected mode, as they cleaned up a lot of other troublesome corners around that time. But, well, they didn't, so we have to deal with it today.
Earlier quoted context omitted.
Why can't there be automated test suites that catch unauthorized access issues before ship (if not before merge commit)? Usually the search space is too large.
Isn't that what fuzzing is for?
Basic fuzzing probably wouldn’t catch this; as the other comments point out, the search space is probably too large, and the set of vulnerable executions is probably too small for an undirected random search.