Stack Clash Vulnerability in Linux, BSD Systems Enables Root Access | Threatpost
Linux, BSD, Solaris and other open source systems are vulnerable to a local privilege escalation vulnerability known as Stack Clash that allows an attacker to execute code at root.
Major Linux and open source distributors have made patches available today, and systems running Linux, OpenBSD, NetBSD, FreeBSD or Solaris on i386 or amd64 hardware should be updated soon.
The risk presented by this flaw, CVE-2017-1000364, becomes elevated especially if attackers are already present on a vulnerable system. They would now be able to chain this vulnerability with other critical issues, including the recently addressed Sudo vulnerability, and then run arbitrary code with the highest privileges, said researchers at Qualys who discovered the vulnerability.
The vulnerability was found in the stack, a memory management region on these systems. The attack bypasses the stack guard-page mitigation introduced in Linux in 2010 after attacks in 2005 and 2010 targeted the stack.
“Our [proof-of-concept] exploit grows the stack out, jumping past protections and getting into areas of memory where we should not be able to get code to execute,” said Jimmy Graham, a director at Qualys.
As designed, the stack memory region includes a mechanism that expands when a program needs more stack memory; this expansion, however, is a security threat.
“If the stack pointer of a process can move from the attack into another memory region (which ends exactly where the attack starts) without raising a page fault, then the process uses this other memory region as if it were an extension of the stack,” Qualys wrote in an advisory. An attacker could write to this stack extension and smash the adjacent memory region, or write to the other memory region and smash the stack extension.
The guard-page mitigation was supposed to protect against this by including unmappable pages below the start of the stack that raise exceptions if accessed or terminate the process with a SIGSEGV error signal.
“Unfortunately, a stack guard-page of a few kilobytes is insufficient: if the stack-pointer ‘jumps’ over the guard-page—if it moves from the stack into another memory region without accessing the guard-page—then no page-fault exception is raised and the stack extends into the other memory region,” Qualys said.
Graham said that Qualys hasn’t ruled out completely the possibility that this vulnerability is also remotely exploitable, calling that aspect of it application-specific.
“We dug into one application (the Exim mail server) that we believed might have been, but it turned out it was not,” Graham said. “There are remote applications that could have this vulnerability, but we focused on the local privilege escalation aspect.”
Qualys said in its advisory that its proof of concept exploits (researchers said they built seven of them) follow four sequential steps that allocate memory that must not be freed before all are complete. These four steps include: clashing the stack with another memory region, running the stack pointer to the start of the stack, jumping over the stack guard-page, and smashing the stack or other memory region.
Qualys recommends in its advisory increasing the size of the stack guard-page to 1MB at a minimum as a short-term solution until an update can be applied. It also recommends recompiling all userland code with the –fstack-check option which would prevent the stack pointer from moving into other memory regions. Qualys concedes, however, this is an expensive solution, but one that cannot be defeated unless there is an unknown vulnerability in the –fstack-check option.
“I would definitely categorize this is a high-risk vulnerability,” Graham said. “Chained with other vulnerabilities, you can go from remote to root very quickly.”