CloudLinux - CloudLinux Blog - Major vulnerability: The Stack Clash security issue found that affects most Linux kernels
KernelCare Blog

By accepting you will be accessing a service provided by a third-party external to https://www.cloudlinux.com/

Major vulnerability: The Stack Clash security issue found that affects most Linux kernels

Major vulnerability: The Stack Clash security issue found that affects most Linux kernels

[Last updated Jun 22, 12:05PM PDT]

A new major local privilege escalation vulnerability in the Linux kernel was disclosed yesterday, June 19th, 2017 (CVE-2017-1000364). The vulnerability can be exploited to allows an unprivileged local user to gain root access to the server.

The Qualys' security advisory shows practical methods for circumventing an exploit protection mechanism known as the "stack guard page". A flaw was found in the way memory was being allocated on the stack for user-space binaries. If heap (or a different memory region) and stack memory regions were adjacent to each other, an attacker could use this flaw to jump over the stack guard page, causing controlled memory corruption on the process stack or the adjacent memory region, thus increasing their privileges on the system. To read more about the stack guard page vulnerability, visit this post.

This vulnerability affects most kernels. The KernelCare team, as always, is urgently working on releasing patches, with some distributions being promptly covered by the end of today (Tuesday, June 20th, 2017), and most soon after (we will be updating the release schedule below). Major Linux distributions have released kernel updates with a fix, which requires a reboot. However, if you run KernelCare, you can livepatch your servers and protect yourself from critical vulnerabilities, including this one, without any downtime.

When you install KernelCare, whether a paid or a trial version, it will bring your kernels up-to-date with all patches instantly. It installs with a single line of code in just minutes, without a reboot, and it will ensure you never miss another kernel security patch as they will be automatically installed to your live kernel going forward.

If you’d like to update your kernels as soon as the fix is released, you can get KernelCare for free for 30 days here. To learn more about KernelCare, visit this page.

Timeline for patch releases for KernelCare:

CloudLinux OS 7 - Jun 21, 2017
CloudLinux OS 6 Hybrid - Jun 21, 2017
CloudLinux OS 6 - Jun 22, 2017
RHEL 7 - Jun 21, 2017
RHEL 6 - Jun 22, 2017
CentOS 7 Plus - Jun 21, 2017
Proxmox VE 3.10 - Jun 21, 2017
Proxmox VE 2.6 - Jun 22, 2017
Proxmox VE 4.x - Jun 22, 2017
Ubuntu 3.13, 4.4 & 4.8 kernels - Jun 21, 2017
CentOS 7 - Jun 21, 2017 
CentOS 6 - Jun 22, 2017
Debian 8 - Jun 21, 2017
Debian 7 - Jun 22, 2017
CentOS 6 Plus - Jun 22, 2017
Virtuozzo/OpenVZ 2.6.32 - Jun 22, 2017
CentOS 6 Alt - to be released 
CentOS 7 Alt - to be released 

 
If you have KernelCare, it will bring your kernels up-to-date with these patches automatically, without a reboot.

KernelCare supports most popular Linux distributions. Click here to see the complete list.

Imunify360’s latest malware scanning engine outper...
Issues caused by the latest KernelCare update and ...
 

Комментарии 14

Hello,

Where we'll be advised when patch become available?
Thanks

Hello, Where we'll be advised when patch become available? Thanks

Yes, we will notify as it hits production.
We just pushed CL7/CL6Hybrid patches to test. If anyone can test by running:
kcarectl --update --test

It will help us release faster. It has been running our tests for 6 hours already, but we want to have few live boxes tested, as we are working on very tight schedule with this one.

Yes, we will notify as it hits production. We just pushed CL7/CL6Hybrid patches to test. If anyone can test by running: kcarectl --update --test It will help us release faster. It has been running our tests for 6 hours already, but we want to have few live boxes tested, as we are working on very tight schedule with this one.

So is there any timeline for older versions like CentOS 5 and RHEL 5 ??

So is there any timeline for older versions like CentOS 5 and RHEL 5 ??

CentOS5 is EOL and new patches will not be added.

CentOS5 is EOL and new patches will not be added.

# kcarectl --uname
2.6.32-673.26.1.lve1.4.27.el6
# kcarectl --update --test
Kernel is safe
# kcarectl --uname
2.6.32-673.26.1.lve1.4.27.el6

Still waiting for 2.6.32-673.26.1.lve1.4.29.el6

# kcarectl --uname 2.6.32-673.26.1.lve1.4.27.el6 # kcarectl --update --test Kernel is safe # kcarectl --uname 2.6.32-673.26.1.lve1.4.27.el6 Still waiting for 2.6.32-673.26.1.lve1.4.[b]29[/b].el6

Update seems to be out for CL7, but still nothing for CL6.
When is ETA for CL6?

Update seems to be out for CL7, but still nothing for CL6. When is ETA for CL6?

CL7 / CL6hybrid is out
CL6 should be added in 6-8 hours

CL7 / CL6hybrid is out CL6 should be added in 6-8 hours

Hi, any ETA on the Ubuntu/Debian versions?

Hi, any ETA on the Ubuntu/Debian versions?

Some Ubuntu versions have been updated. More to come.

Some Ubuntu versions have been updated. More to come.

Is CL6 KerncalCare patch is available now, if not please provide the ETA?

Is CL6 KerncalCare patch is available now, if not please provide the ETA?

It has been released for CL6:

server4 [~]# cat /etc/redhat-release && kcarectl --patch-info | grep CVE-2017-1000364
CloudLinux Server release 6.9 (Igor Volk)
kpatch-name: 2.6.32/CVE-2017-1000364.patch
kpatch-cve: CVE-2017-1000364

It has been released for CL6: server4 [~]# cat /etc/redhat-release && kcarectl --patch-info | grep CVE-2017-1000364 CloudLinux Server release 6.9 (Igor Volk) kpatch-name: 2.6.32/CVE-2017-1000364.patch kpatch-cve: CVE-2017-1000364

Running CL7

# kcarectl --uname
3.10.0-614.10.2.lve1.4.50.el7
# /usr/bin/kcarectl --update
Kernel is safe

Any idea why its not applied the latest patch 3.10.0-614.10.2.lve1.4.55.el7.x86_64

Running CL7 # kcarectl --uname 3.10.0-614.10.2.lve1.4.50.el7 # /usr/bin/kcarectl --update Kernel is safe Any idea why its not applied the latest patch 3.10.0-614.10.2.lve1.4.[b]55[/b].el7.x86_64

How does the kernelcare's patch work for running processes that already had their stack created? Does it recreate them so that the guard region is large enough?

How does the kernelcare's patch work for running processes that already had their stack created? Does it recreate them so that the guard region is large enough?

It doesn't re-create the running processes, so you might want to restart apache & such.

It doesn't re-create the running processes, so you might want to restart apache & such.
Уже зарегистрированны? Войти на сайт
Guest
10.08.2020

Изображение капчи