For once, Windows users (and OS X users) can breathe easy -- this one is not for them.
Posted on 06/20/2017 2:52:48 PM PDT by dayglored
The Stack Clash is a vulnerability in the memory management of several operating systems. It affects Linux, OpenBSD, NetBSD, FreeBSD and Solaris, on i386 and amd64. It can be exploited by attackers to corrupt memory and execute arbitrary code.
Qualys researchers discovered this vulnerability and developed seven exploits and seven proofs of concept for this weakness, then worked closely with vendors to develop patches. As a result we are releasing this advisory today as a coordinated effort, and patches for all distributions are available June 19, 2017. We strongly recommend that users place a high priority on patching these vulnerabilities immediately.
Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around.
The first step in exploiting this vulnerability is to collide, or clash, the stack with another memory region. Hence the name: the Stack Clash.
The idea of clashing the stack with another memory region is not new: it was exploited a first time in 2005 and a second time in 2010. After the 2010 exploit, Linux introduced a protection against such exploits: the so-called stack guard-page. Today, we show that stack clashes are widespread and exploitable despite the stack guard-page protection.
Our primary Stack Clash vulnerability is CVE-2017-1000364 and demonstrates that a stack guard-page of a few kilobytes is insufficient. But during our research we discovered more vulnerabilities: some are secondary and directly related to the primary Stack Clash vulnerability (for example, CVE-2017-1000365), and some are exploitable independently (for example, CVE-2017-1000367).
If you are using Linux, OpenBSD, NetBSD, FreeBSD, or Solaris, on i386 or amd64, you are affected. Other operating systems and architectures may be vulnerable too, but we have not researched any of them yet: please refer to your vendor’s official statement about the Stack Clash for more information.
The exploits and proofs of concept that we developed in the course of our research are all Local Privilege Escalations: an attacker who has any kind of access to an affected system can exploit the Stack Clash vulnerability and obtain full root privileges.
Our research has mainly focused on local exploitation: as of this writing on June 19, 2017, we do not know of any remotely exploitable application. However, remote exploitation of the Stack Clash is not excluded; although local exploitation will always be easier, and remote exploitation will be very application-specific. The one remote application that we did investigate (the Exim mail server) turned out to be unexploitable by sheer luck.
The easiest and safest way to protect your system is to update it: we have been working with the affected vendors since the beginning of May, and by the time you read this, their patches and updates will be available.
As a temporary workaround, you may set the hard RLIMIT_STACK and RLIMIT_AS of your local users and remote services to some reasonably low values. Use this workaround at your own risk, however: most likely your limits will not be low enough to resist all attacks (for example, in some cases our Sudo stack-clash exploit allocates merely 137MB of heap memory, and almost no stack memory); or your limits will be too low and will break legitimate applications.
We will eventually publish our exploits and proofs of concept, but not immediately: we will only do so after users had enough time to patch their systems.
Please refer to the Stack Clash security advisory for the full technical details.
OR:
Refer to the vendor advisories, which we are listing here as they become available:
SUSE
https://www.novell.com/support/kb/doc.php?id=7020973
Red Hat
https://access.redhat.com/security/vulnerabilities/stackguard
Debian
https://www.debian.org/security/2017/dsa-3886
https://www.debian.org/security/2017/dsa-3887
https://www.debian.org/security/2017/dsa-3888
https://www.debian.org/security/2017/dsa-3889
Ubuntu
https://www.ubuntu.com/usn/
OpenBSD
https://ftp.openbsd.org/pub/OpenBSD/patches/6.1/common/008_exec_subr.patch.sig
Oracle Solaris
http://www.oracle.com/technetwork/security-advisory/alert-cve-2017-3629-3757403.html
You should try to implement the local-root exploit against Exim on i386 Debian: it is by far the easiest and most representative Stack Clash exploit.
https://www.qualys.com/2017/06/14/cve-2017-1000367/cve-2017-1000367.txt https://www.qualys.com/2017/06/14/cve-2017-1000367/linux_sudo_cve-2017-1000367.c
If CVE-2017-1000367 is combined with the Stack Clash, any local user (not just Sudoers) can exploit Sudo to obtain full root privileges on any vulnerable Linux system (not just SELinux systems). Because CVE-2017-1000367 was exploitable independently of the Stack Clash, we (and the affected vendors) decided to not wait for the June 19 Coordinated Release Date and published it on May 30.
For once, Windows users (and OS X users) can breathe easy -- this one is not for them.
You might want to do your own verification about the apparent non-susceptibility of OS X / macOS to this one. I can't tell from this article (since it doesn't say specifically), but it does not appear to apply to Mac and Windows.
Somebody HAD to do that. :-)
How many folks are still running 386 processors? AMD 64 I can see.
We have a Linux mainframe...not connected to the internet.
i386 refers to the chip architecture of 386, 486 and Pentium - in other words, virtually all Intel chips for the past 20 years.
This is a local privilege escalation vulnerability. The attacker has to have an account on the *nix machine and be able to log on as an ordinary user, in order to try to become root.
This is very different from attacks over the internet. While a user could log in remotely with SSH, he still needs an local ID and password to connect.
I’ve usually seen x86 used to refer to the family, 386 to refer to a specific version.
Does this affect Android, which is also based on Linux?
I still have an AMD Athlon XP 1200 running XP. I use it for usenet and some old games. FF won’t update, and the last K-lite wouldn’t install because of the lack of hw features.
Good question. Thundersleeps?
That's (almost certainly) a big negative there good buddy.
MacOS IS an officially branded UNIX which is based on darwin, a BSD variant.
I can't see how this would not effect MacOS, expect to hear about a patch very soon.
Ironically this is the 1 in a 1000 security vulnerability which does NOT involve Windows .... P.S. Here is an in depth linky about it for your inner geek (https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt )
I would think that if OS X / macOS was affected The articles offers would have mentioned it. It is certainly widely known that they are based on FreeBSD. I pinged swordmaker above to please double check.
Yes, but this is what they say in Linux-land, when they offer distros for download.
The author's of the article said there very well could be more OS's effected by this these are the only ones they have checked so far.
Believe me, I am not gleeful about this at all, I am a big MacOS user, but to be honest, I have seen Apple drag its proverbial feet on security fixes from time to time ...
So are they saying only local access as root can make this happen?
I’m gonna pass this on to my peeps on the job. But there are tons of ways of killing your linux server as root. Doesn’t require and exploit; just bad command line statements.
Ok, thanks. I probably need to download a new Puppy. That’s the only distro I regularly used.
No, local access as a non-root account, seeking to gain root access. Historically, there have been many ways to do this, but these holes have gradually been plugged.
Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.