1:08 a.m.
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(a)redhat.com>
To: Kernel Fedora <kernel(a)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
7:11 a.m.
New subject: Fw: Stack clash and Fedora, new kernel vulnerability, from
kernel list
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
7:32 a.m.
New subject: Stack clash and Fedora, new kernel vulnerability, from kernel
list
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.
7:56 a.m.
New subject: Stack clash and Fedora, new kernel vulnerability, from kernel
list
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).
10:36 a.m.
New subject: Stack clash and Fedora, new kernel vulnerability, from kernel
list
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
10:42 a.m.
New subject: Stack clash and Fedora, new kernel vulnerability, from kernel
list
On Tue, 20 Jun 2017 13:11:24 +0100
Patrick O'Callaghan <pocallaghan(a)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
11:08 a.m.
New subject: Stack clash and Fedora, new kernel vulnerability, from kernel
list
On Tue, 2017-06-20 at 08:42 -0700, stan wrote:
On Tue, 20 Jun 2017 13:11:24 +0100
Patrick O'Callaghan <pocallaghan(a)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
12:14 p.m.
New subject: Stack clash and Fedora, new kernel vulnerability, from kernel
list
On Tue, 20 Jun 2017 17:08:09 +0100
Patrick O'Callaghan <pocallaghan(a)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.
11:20 a.m.
New subject: Stack clash and Fedora, new kernel vulnerability, from kernel
list
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?
11:39 a.m.
New subject: Stack clash and Fedora, new kernel vulnerability, from kernel
list
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
12:09 p.m.
New subject: Stack clash and Fedora, new kernel vulnerability, from kernel
list
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.
10:44 p.m.
New subject: Stack clash and Fedora, new kernel vulnerability, from kernel
list
On 17-06-20 13:09:50, stan wrote:
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.
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.
--
____________________________________________________________________
TonyN.:' <mailto:tonynelson@georgeanelson.com>
' <http://www.georgeanelson.com/>
11:45 p.m.
New subject: Stack clash and Fedora, new kernel vulnerability, from kernel
list
On Tue, 20 Jun 2017 23:44:24 -0400
Tony Nelson <tonynelson(a)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.
9:03 a.m.
New subject: Stack clash and Fedora, new kernel vulnerability, from kernel
list
On Tue, 20 Jun 2017 21:45:31 -0700
stan <stanl-fedorauser(a)vfemail.net> wrote:
On Tue, 20 Jun 2017 23:44:24 -0400
Tony Nelson <tonynelson(a)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.
2501
days inactive
2502
days old
13 comments
4 participants
participants (4)
-
Patrick O'Callaghan -
stan -
Tom Horsley -
Tony Nelson