The Stack Clash (Major Vulnerability found in Linux, Solaris, Free/Net/OpenBSD)

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.

What is the Stack Clash vulnerability, precisely?

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.

Why is it called the Stack Clash?

The first step in exploiting this vulnerability is to collide, or clash, the stack with another memory region. Hence the name: the Stack Clash.

Is it a new vulnerability?

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.

Is the Stack Clash one or several vulnerabilities?

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).

Am I affected by the Stack Clash?

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.

What are the risks posed by the Stack Clash?

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.

Is it exploitable remotely?

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.

How can I protect my system from the Stack Clash?

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.

What if I can’t (or don’t want to) update or reboot my system?

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.

Where can I find the Stack Clash exploits?

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.

Where can I get more information?

Refer to the vendor advisories, which we are listing here as they become available:

I want to write my own Stack Clash exploit, where do I start?

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.

Is the Sudo vulnerability Qualys published on May 30 related to Stack Clash?

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.

> 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 ...

No argument there; they often err on the over-cautious side about throwing patches out to their user base.

But I still say, I'll be surprised if OS X / macOS is affected. Being a certified, genuine UNIX doesn't mean the internals necessarily are identical to other UNIXes -- it means you meet the requirements, most of which are external (interfaces, APIs, system support, behavior). With all the other work Apple has done to secure the OS, they may have (albeit inadvertently) fixed this problem without knowing it.

"May". I, like you, will wait and see what appears...

> While a user could log in remotely with SSH, he still needs an local ID and password to connect.

That's assuming the local user has a decent password. But even if they do...

Suppose the local user takes his laptop on a trip. It has a private SSH key for login, and the key has a null or trivial passphrase for convenience (sadly, very common).

Thief lifts the laptop from the hotel room, transfers the hard drive to a USB enclosure, plugs it into their own laptop, and checks /home or C:\Users or C:\cygwin\home.

Half an hour max; they're in. Meanwhile the local user hasn't even come back from dinner. By the time they realize it's missing, reach somebody in IT on the phone, and disable the account, the thief is long since done.

2-factor authentication is a wonderful thing.

It very well could affect Android - and Macs since they are based on a Unix-like kernel under the covers.

This vulnerability is based on a well-known issue with Von Neumann architecture systems (aka most modern computers). You can think of memory for a process (aka your program - the word processor, web browser, picture viewer, etc.) as a multi-story building. The operating system occupies the basement (low memory). Your program is loaded into the first couple floors - this is the executable code or instructions that make up the program. On the top floor is the "stack" memory. This is used when the program calls a function and that function needs some temporary local storage to use as a scratch pad. It may use the top floor or two, moving down as functions are called, moving back up (releasing memory) as functions exit. In between is "heap" memory. This is memory the program can ask for chunks of and hold onto/use for the life of the program, or return when no longer needed.

A stack/heap collision occurs when a program asks for too much memory from the heap, allocating floors up and up until it runs into the stack. A renegade program could also repeatedly call functions, bringing the stack down until it collides with memory allocated to the heap.

The nature of the attack? One of the things functions typically store in the stack is the address of where to return to when the function is done. The same function can be called from many places, so they store the address of who called them on the stack. Well... If the stack, and that address have "collided" with memory allocated from the heap, your program can write to that heap memory any address it wants. Then exit the function, and viola, the computer jumps back to what it thinks is the caller of the function, but is in fact where-ever the attacker wants it to go.

Putting a "guard" page of memory between the stack and heap is a fine idea to protect against your average accidental collision. However, attackers can easily jump over that with large allocations. If your processor architecture supports it, you can use the huge virtual memory space to separate the two by unreasonably large values. However, this may not be an option on constrained mobile devices with more modest processor architectures.

Any system that co-locates instructions and data in the same memory space, (aka Von Neumann architecture) is subject to this kind of attack if they organize stack/heap memory this way. There is a so-called Harvard architecture that uses totally separate data and program memory, thus eliminating this attack as a possibility. Similarly, modern x86 processors (eg. later than 2004/2005) support the notion of executable space - memory pages marked as data or program. Kind of like overlaying Harvard architecture onto it. Linux, Windows, and IOS have all incorporated support for this as a means of hardening against this (and other) attacks. If you can only write to data memory, but only execute out of executable memory, then it is very difficult for an attacker to write-out malicious code.

It doesn't say in the article, but I wonder if they had disabled this feature? Also, requiring local access is like cheating. In terms of computer security, the rule of thumb is "physical access equals root access." That is, if an attacker can physically get at a machine they can probably get root access. Remotely gaining access is another matter.

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.

Note from dayglored: This article is about a flaw in the *IX systems -- Linux, FreeBSD, NetBSD, OpenBSD, Solaris. It does NOT apply to Windows, nor as far as I can tell, to OS X (even though OS X is based on FreeBSD).

What is the Stack Clash?