I haven't seen anyone else post about this, so this message is forwarded from the kernel list, about a new kernel vulnerability. The vulnerability is severe as it leads to root authority, but so far only local logins have been demonstrated to have the ability to exploit it. So, for most Fedora users, it means they aren't at risk. I'm running the kernel with the fix, and it is working fine so far. The link explains the risk, it has to do with the interaction between user stacks and kernel stacks, and one gaining access to the other with bad things happening thereafter.
Begin forwarded message:
Date: Mon, 19 Jun 2017 16:30:28 -0700 From: Laura Abbott labbott@redhat.com To: Kernel Fedora kernel@lists.fedoraproject.org Subject: Stack clash and Fedora
Hi,
If you haven't seen it, a new kernel vulnerability was announced https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt Updates have been filed in bodhi with the fix
https://bodhi.fedoraproject.org/updates/FEDORA-2017-1225995344 https://bodhi.fedoraproject.org/updates/FEDORA-2017-b93e6de389 https://bodhi.fedoraproject.org/updates/FEDORA-2017-79f099cbba
Please test and leave karma if this update works for you. This is especially important for F24 which has seen a falloff in karma recently.
Thanks, Laura
On Mon, 2017-06-19 at 23:08 -0700, stan wrote:
I'm running the kernel with the fix, and it is working fine so far.
As I understand it (and as the bug report appears to confirm) the fix is to ld.so, not the kernel, though changing ld.so does of course mean a reboot.
How do you know it's working? Have you run an exploit test?
poc
On Tue, 20 Jun 2017 13:11:24 +0100 Patrick O'Callaghan wrote:
As I understand it (and as the bug report appears to confirm) the fix is to ld.so, not the kernel, though changing ld.so does of course mean a reboot.
That doesn't make any sense. If the exploit happens in ld.so, fixing it doesn't do anything. All you need to do is point an executable at an old copy of ld.so and you have access to the same exploit.
On Tue, 20 Jun 2017 08:32:23 -0400 Tom Horsley wrote:
That doesn't make any sense. If the exploit happens in ld.so, fixing it doesn't do anything. All you need to do is point an executable at an old copy of ld.so and you have access to the same exploit.
OK, I see it now. The exploit only happens in setuid programs, so if they are linked with a repaired ld.so, then I can't change them to use the broken ld.so (unless I have root access, in which case who needs the exploit).
On Tue, 2017-06-20 at 08:56 -0400, Tom Horsley wrote:
On Tue, 20 Jun 2017 08:32:23 -0400 Tom Horsley wrote:
That doesn't make any sense. If the exploit happens in ld.so, fixing it doesn't do anything. All you need to do is point an executable at an old copy of ld.so and you have access to the same exploit.
OK, I see it now. The exploit only happens in setuid programs, so if they are linked with a repaired ld.so, then I can't change them to use the broken ld.so (unless I have root access, in which case who needs the exploit).
Exactly.
poc
On Tue, 20 Jun 2017 13:11:24 +0100 Patrick O'Callaghan pocallaghan@gmail.com wrote:
On Mon, 2017-06-19 at 23:08 -0700, stan wrote:
I'm running the kernel with the fix, and it is working fine so far.
As I understand it (and as the bug report appears to confirm) the fix is to ld.so, not the kernel, though changing ld.so does of course mean a reboot.
Yes, I also saw that. However, I assumed Laura Abbot, one of the kernel maintainers for Fedora, would know what she is talking about. My assumption was that this was adding the strong stack protection to the kernel side of things. I checked in koji, and the fix is also in the latest glibc (where ld.so comes from), but it hadn't been pushed at that time, so I didn't install the patched version of glibc. As the exploit report said, enabling strong stack protection in the compiler for affected libraries would stop this exploit, but would be expensive. I assume that means it slows execution.
How do you know it's working? Have you run an exploit test?
My statement wasn't clear. I don't have the exploit, and so can't test that. What I meant was that the kernel with the fix was behaving as a normal kernel would, as far as I could tell. i.e. was running fine
On Tue, 2017-06-20 at 08:42 -0700, stan wrote:
On Tue, 20 Jun 2017 13:11:24 +0100 Patrick O'Callaghan pocallaghan@gmail.com wrote:
On Mon, 2017-06-19 at 23:08 -0700, stan wrote:
I'm running the kernel with the fix, and it is working fine so far.
As I understand it (and as the bug report appears to confirm) the fix is to ld.so, not the kernel, though changing ld.so does of course mean a reboot.
Yes, I also saw that. However, I assumed Laura Abbot, one of the kernel maintainers for Fedora, would know what she is talking about. My assumption was that this was adding the strong stack protection to the kernel side of things. I checked in koji, and the fix is also in the latest glibc (where ld.so comes from), but it hadn't been pushed at that time, so I didn't install the patched version of glibc. As the exploit report said, enabling strong stack protection in the compiler for affected libraries would stop this exploit, but would be expensive. I assume that means it slows execution.
Full details are in the report already cited, but briefly the fix causes each page of the new stack frame to be probed to make sure it doesn't overlap with the guard page (a write-protected page created to prevent stack and heap from running into each other). The exploit consisted in jumping over the guard page so as not to trigger a trap, and the patch cuts off that line of attack at the expense of some extra instruction cycles.
poc
On Tue, 20 Jun 2017 17:08:09 +0100 Patrick O'Callaghan pocallaghan@gmail.com wrote:
Full details are in the report already cited, but briefly the fix causes each page of the new stack frame to be probed to make sure it doesn't overlap with the guard page (a write-protected page created to prevent stack and heap from running into each other). The exploit consisted in jumping over the guard page so as not to trigger a trap, and the patch cuts off that line of attack at the expense of some extra instruction cycles.
I bit the bullet, went here
https://koji.fedoraproject.org/koji/buildinfo?buildID=909756
to get the appropriate patched glibc packages for my F25 system, installed them using dnf -C, and rebooted. I haven't noticed any performance differences, but I haven't been stressing my system.
On Tue, 20 Jun 2017 08:42:39 -0700 stan wrote:
My assumption was that this was adding the strong stack protection to the kernel side of things.
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 :-).
As the exploit report said, enabling strong stack protection in the compiler for affected libraries would stop this exploit, but would be expensive. I assume that means it slows execution.
So maybe the proper solution is to static link all the setuid binaries, and not drag everything else on the system down?
On Tue, 2017-06-20 at 12:20 -0400, Tom Horsley wrote:
On Tue, 20 Jun 2017 08:42:39 -0700 stan wrote:
My assumption was that this was adding the strong stack protection to the kernel side of things.
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 :-).
As the exploit report said, enabling strong stack protection in the compiler for affected libraries would stop this exploit, but would be expensive. I assume that means it slows execution.
So maybe the proper solution is to static link all the setuid binaries, and not drag everything else on the system down
That would mean having a separate library for setuid programs, which would have to be maintained. Better would be to test for setuid-ness when the library is called, but I admit I'm just guessing here.
poc
On Tue, 20 Jun 2017 12:20:57 -0400 Tom Horsley horsley1953@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.
On 17-06-20 13:09:50, stan wrote:
On Tue, 20 Jun 2017 12:20:57 -0400 Tom Horsley horsley1953@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.
It's not allocated memory. It's a Page Table Entry in the Kernel that ensures that no actual memory is mapped there and that the region is thus unreadable and unwritable. This is not unlike a swapped-out page, except the Kernel Page Table Entry for such a page says that it can be swapped back in and from what (memory-mapped) file. So all it uses is address space and Page Table Entries.
On Tue, 20 Jun 2017 23:44:24 -0400 Tony Nelson tonynelson@georgeanelson.com wrote:
It's not allocated memory. It's a Page Table Entry in the Kernel that ensures that no actual memory is mapped there and that the region is thus unreadable and unwritable. This is not unlike a swapped-out page, except the Kernel Page Table Entry for such a page says that it can be swapped back in and from what (memory-mapped) file. So all it uses is address space and Page Table Entries.
Thanks. I had wondered if they did that.
On Tue, 20 Jun 2017 21:45:31 -0700 stan stanl-fedorauser@vfemail.net wrote:
On Tue, 20 Jun 2017 23:44:24 -0400 Tony Nelson tonynelson@georgeanelson.com wrote:
It's not allocated memory. It's a Page Table Entry in the Kernel that ensures that no actual memory is mapped there and that the region is thus unreadable and unwritable. This is not unlike a swapped-out page, except the Kernel Page Table Entry for such a page says that it can be swapped back in and from what (memory-mapped) file. So all it uses is address space and Page Table Entries.
Thanks. I had wondered if they did that.
But, given that, why restrict the guard buffer to 4kB? Since it is virtual, why not make it 100 MB, or on 64 bit systems, 100 GB? All for the same price, a little pointer indirection, and pushes the likelihood of the stack clash problem to nil or close. I think it would be cheaper than the stack-check solution, as well.
-
Patrick O'Callaghan -
stan -
Tom Horsley -
Tony Nelson