On Tue, 20 Jun 2017 12:20:57 -0400
Tom Horsley <horsley1953(a)gmail.com> wrote:
That seems like it might be impossible without architecture changes
in the chips to allow bounds checking the stack pointer in hardware
(which certainly wouldn't fix any existing systems :-).
I think the kernel fix was the first solution suggestion in the exploit
report - expand the guard page to 1 MB in size from 4 KB. I hope they
don't do this (at least permanently). My understanding of this is
flawed, but my research about this found that every process has its own
instance of the two pieces that go into this exploit. If every
vulnerable process that runs needs 1 MB of empty guard, that can get
pretty expensive in terms of memory if there are lots of processes
running. And more swapping in and out, etc. The report said that if
the stack-check was implemented, even a 4kB guard page was enough.
The original kernel fix had a bug, so there is a fix for the fix being
compiled now.
> Laura on the kernel list:
> > The stack-clash fix was found to have a bug so I revoked the
> > updates.
> > New builds with a fix for the fix will be filed in bodhi when
> > finished.
So maybe the proper solution is to static link all the setuid
binaries, and not drag everything else on the system down?
I think the trend is the other direction. I've seen discussions
about whether all static libraries could be removed from Fedora. I
suppose people will have to decide that based on what they are using
the system for. Which is better for their use case?
I'm wondering, in my ignorance, if a different way of organizing the
stack and heap could be introduced, so they aren't vulnerable to this.
I'm sure the experts have been considering this since the issue has been
around for over 10 years. Might even be computer science courses
taught about this, and speculation over wine and cheese. :-) They
must have looked at alternative approaches and come up empty. If they
have, then Windows and Mac will be vulnerable to this as well, since
they can't do things any differently.