Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Open Source Oracle Linux BSD

'Stack Clash' Linux Flaw Enables Root Access. Patch Now (threatpost.com) 126

Posted by EditorDavid from the escalating-privileges dept.
msm1267 writes: 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 made patches available Monday, 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.
This discussion has been archived. No new comments can be posted.

'Stack Clash' Linux Flaw Enables Root Access. Patch Now More

'Stack Clash' Linux Flaw Enables Root Access. Patch Now

Comments Filter:

  • Interesting, makes me wonder (Score:2, Interesting)

    by Anonymous Coward
    Very interesting that the major flavors (Sys V, BSD, and Linux [which I consider a rewrite of Sys V]) are vulnerable. Sounds like a deep seated logic flaw there. Wonder if other vendor specific ones (IRIX, SunOS, Ultrix, AIX, etc) are vulnerable.

    • Re: Interesting, makes me wonder (Score:2, Interesting)

      by Anonymous Coward

      It's only on specific processor types, which indicates the flaw is in the chips' instruction set and the OS patch is a mitigation.

      • Re: (Score:2, Interesting)

        by Anonymous Coward

        It's an ABI flaw, not a instruction set flaw.

        The real fix would be in the compiler and recompiling all libraries and binaries.

        So yes, the kernel fix is "mitigation", because doing the real thing will take much longer.

        • Re: (Score:1)

          by Anonymous Coward

          The compiler already is fixed, use -fstack-check

          It's an option because it costs some performance and therefore you may want to use it only on applications subject to untrusted input.

    • Re: (Score:2, Informative)

      by Anonymous Coward

      Very interesting that the major flavors (Sys V, BSD, and Linux [which I consider a rewrite of Sys V]) are vulnerable. Sounds like a deep seated logic flaw there. Wonder if other vendor specific ones (IRIX, SunOS, Ultrix, AIX, etc) are vulnerable.

      I'm actually still wondering if any of the above except Linux actually are vulnerable.

      Only the "threatpost.com" article claims so, and of course the copy/pasted slashdot summary.

      But the security researchers quoted in that very article explicitly say they discovered this in Linux, and nothing else.
      The CVE issued explicitly says Linux kernels from 3.0 to 4.11.5 as well, no CVEs for other kernels or OSes.

      Also the vulnerability in Linux only applies to Intel x86 and amd64 architectures, and it has been proven n

      • Re: (Score:2)

        by Anonymous Coward

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

        https://blog.qualys.com/securi... [qualys.com]

      • Re:Interesting, makes me wonder (Score:5, Informative)

        by Anonymous Coward on Saturday June 24, 2017 @02:13PM (#54682833)

        Wonder no more, here's the actual technical description of the problem that includes attacks on non-Linux OSes: https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt [qualys.com].

        Slashdot editors: this link should have been in the summary. It's the relevant one to technical users interested in what the attack actually is.

        • That's a really great writeup. This comment should be modded up.
    • This is because those are the Operating Systems they tested. They indicate "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." in their blog on the subject." [qualys.com]. In other words, Microsoft products are likely just as vulnerable (unless you think all these developers for all these OSs didn't think properly mitigate this, but Microsoft did.) Also, note that

  • requires local access (Score:3)

    by humankind ( 704050 ) on Saturday June 24, 2017 @12:58PM (#54682461) Journal

    This exploit still requires local access to a machine, so it's not as bad as people claim. Unless you're giving random people shell access to your server.

    • Re:requires local access (Score:4, Informative)

      by Zocalo ( 252965 ) on Saturday June 24, 2017 @01:09PM (#54682517) Homepage
      Two words: "priviledge" and "escalation".

      You might not be giving random people shell access to your server, but if they've managed to acquire it through some other means (e.g. a compromised acccount or some other form of compromise) this means that they can pretty much be assured of being able to go from there to root until you install the patch. Not as bad as a remote root exploit, but still very nasty and worth the "Patch Now".
      • There are always privilege escalation exploits available, because setting up a good permissions system that considers all the subtle interactions between parts is hard. At this moment in time, you have a chance of stopping remote exploits, but you have no chance of stopping privilege escalations once someone's code is already running on your system.

        To me privilege separation seems like an area where formal verification could be useful, but so far no one cares enough to really work on it.

      • Two words: "priviledge" and "escalation".

        One word: "privilege". A comment: Glaring spelling mistakes make one look stupid and ignorant.

    • I think the important thing is that effectively as soon as it was reported, it was fixed and a patch rolled out.

      Linux certainly has flaws and vulnerabilities, just like any major OS.

      But by and large, they don't get "solved" by hoping no one exploits them. They actually get fixed, more often than not in a timely manner.

    • so it's not as bad as people claim

      Yes if your computer is your own and you don't do something like provide services for others.

  • It is called Stack Smashing and OpenBSD is NOT vulnerable to it!

    • It is called Stack Smashing and OpenBSD is NOT vulnerable to it!

      CVE-2017-1000372 and CVE-2017-1000373 are mentioned in the advisory? Broad statements without facts are not helpful. Try again.

      • All I could read seemed to imply this was for Intel and AMD architectures. Do you know if Sparc64 or ARM are susceptible?

        I thought stack and heap were mapped to different memory spaces and you could not hop from one to the other - the "same" address would map to different physical memory regions (randomised and non-contiguous in the case of OpenBSD). Logical addresses might appear contiguous, so, theoretically, you could increment (or decrement) a number which is a pointer to Heap and end up in Stack or V

        • Re: (Score:2)

          by thogard ( 43403 )

          All I could read seemed to imply this was for Intel and AMD architectures. Do you know if Sparc64 or ARM are susceptible?

          The attacks done by Qualys are near to the top of the stack. That is very hard to do on sparc64 as it has a hardware stack. I expect it can be done but it would be a real pain since you would have to attack a deeper level of the stack.

          The sparc (and a few other non-x86 cpus) have "Register Windows" for their stack. What happens is the real stack is in static L0 ram just about like the

    • If OpenBSD wasn't vulnerable, why did they issue a patch:
      https://ftp.openbsd.org/pub/Op... [openbsd.org]
      ?

  • This may be a very old bug (Score:1)

    by Anonymous Coward

    What's odd is that I think it got fixed a very long time ago, as in v7 or maybe 4.2BSD. How did it come back and end up in Linux?

    It's been a long time, maybe I am remembering incorrectly, but it seems awfully familiar.

    • What's odd is that I think it got fixed a very long time ago, as in v7 or maybe 4.2BSD. How did it come back and end up in Linux?

      Warning: Asking this question may re-ignite the SCO case.

  • Red Hat Linux... (Score:3)

    by __aaclcg7560 ( 824291 ) on Saturday June 24, 2017 @01:11PM (#54682535)

    Red Hat sent out a notification on Monday. Nice to see the Slashdot editors catching up on the news this weekend.

    https://access.redhat.com/security/cve/cve-2017-1000364 [redhat.com]

    • They were busy practicing with goop stones all week, just check the headlines. They even threw their backs out trying!

  • Requires poorly-designed software, basically (Score:5, Informative)

    by mrsam ( 12205 ) on Saturday June 24, 2017 @01:25PM (#54682613) Homepage

    Sifting through the CVE and the write-up:

    The kernel places an unmappable guard page just below the process's maximum-alloted stack space. Normally a process gets allocated only as much stack space as it needs. When the process's stack usage grows, the kernel maps additional pages to grow the process's stack space, but will not grow it beyond the maximum alloted stack size. If the process enters an infinite recursion loop, it'll hit the end of the alloted stack space, and the unmappable guard page segfaults the process out of its misery.

    The problem appears to be if the process's heap is right next to the stack, with only the guard page separating it from the stack, and a single function call creates a stack frame that exceeds the size of the guard page. This effectively places the stack pointer into the heap. The function call thinks it has allocated its usual, large stack frame, but the stack pointer is in the heap.

    At this point, usual code execution will typically make further use of the stack, so it ends up crapping all over the heap.

    That's not good, of course. But I would expect the process in question to attempt to access its alleged stack frame before much happens. At this point the process will try to access the guard page, and gets segfaulted. That, at least, is my understanding of the vulnerability.

    The overall design involving a guard page to limit the size of the process's stack is a traditional OS design, which is why the general approach affects both Linux and BSDs, here.

    For this to be remotely exploitable, the attacker has to arrange for a process to execute a function call that creates a large stack frame so that the stack pointer jumps over the guard page. I would expect common, battle-tested free software that powers the intertubes to be well designed and written by experienced greybeards who fully understand how an operating system works, and the fact that the stack is not an endless resource, that it is quite a limited resource actually; with the resulting code minimizing automatically-scoped object usage on the stack, which should eliminate the vulnerability completely.

    I find Red Hat's write-up [redhat.com] somewhat puzzling. They appeared to have taken the tack of addressing the exploit by increasing the size of the guard area to a megabyte, rather than a single page.

    That seems to be somewhat inadequate to me, in the brave-new 64-bit world of ours. It seems to me that the permanent fix would be to map the stack into virtual address space that's a terabyte, or two, away from the heap and everything else. Seems to be a no-brainer solution to me, dunno why they didn't do it.

    • I would expect common, battle-tested free software that powers the intertubes to be well designed and written by experienced greybeards who fully understand how an operating system works, and the fact that the stack is not an endless resource, that it is quite a limited resource actually; with the resulting code minimizing automatically-scoped object usage on the stack, which should eliminate the vulnerability completely.

      That's the most optimistic thing I've read today.

    • Re: (Score:1)

      by Anonymous Coward

      I understand this stack mechanism, but where is the privilege escalation?

    • From the original writeup (https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt [qualys.com]);

      Based on our research, we recommend that the affected operating systems:

      - Increase the size of the stack guard-page to at least 1MB, and allow system administrators to easily modify this value (for example, grsecurity/PaX introduced /proc/sys/vm/heap_stack_gap in 2010). This first, short-term solution is cheap, but it can be defeated by a very large stack-based buffer.

      - Recompile all userland code (ld.so, libraries, binaries) with GCC's "-fstack-check" option, which prevents the stack-pointer from moving into another memory region without accessing the stack guard-page (it writes one word to every 4KB page allocated on the stack). This second, long-term solution is expensive, but it cannot be defeated (even if the stack guard-page is only 4KB, one page) -- unless a vulnerability is discovered in the implementation of the stack guard-page or the "-fstack-check" option.

      That was one of the recommendations. Finding large stack allocations, in setuid binaries, that don't write to the allocated memory is hard.

  • You'd think that by 2017 this kind of linux vs. Microsoft childish discussion would be a thing of the past, but damn. Now, regarding TFA, it amazes me how long it took to reach /., i've read this on other portals days ago.
    • Some quick (very simplified) background for people who don't know how an OS works
      Most of the time user space programs will be running on a processor. Each user space program has its own memory space to work from. The processor switches back to the kernel when an interrupt occurs. An interrupt is a signal to the processor that causes it to save some information about the current running program and then jump to an instruction or function based on the interrupt. An interrupt could be an serial device dem

      • However the page-fault interrupt doesn't reliably go off in the way the kernel programmers would like. It is possible to access memory that you were not supposed to be able to access with out the interrupt occurring. This unfortunate difference in expectation is what leads to this vulnerability and why it affects multiple OS on i86..

        I was on the bus until I got to this paragraph. What do you mean, "page-fault interrupt doesn't reliably go off" in a way that "It is possible to access memory that you were not supposed to be able to access"?

        If this were really true, this would exploited every day and no computer would be even a little bit secure.

        As I understand it, the "problem", which the guard page tries to mitigate, is that the stack pointer can be made to point to heap space that the process absolutely is supposed to have access to.

        If

        • If that's the case, then IMO the stack component of the problem is a great big red herring. If causing a process to wreck its own heap space (by any means) can lead to privilege elevation, then THAT is a huge problem, and it's the problem we should really be talking about.

          That is the point I was trying to make earlier on, but put more elegantly.

  • this affects Linux Kernel versions 4.11.5 and earlier (the stackguard page was introduced in 2010).

    https://nvd.nist.gov/vuln/detail/CVE-2017-1000364/ [nist.gov]

    -- kjh

  • Wait... Build with selinux, and... (Score:3)

    by bferrell ( 253291 ) on Saturday June 24, 2017 @02:17PM (#54682861) Homepage Journal

    it becomes vulnerable?! WTF!

    The NSA made selinux. Automatic backdoor!

    Does anyone really think that was an accident?

  • Does it affect Android too?

    • It affects the Linux kernel, so that is a definite yes.

      • Re: (Score:1)

        by Anonymous Coward

        That's good news then, we can gain root on our Android devices and remove all those crappy apps bundled with our phones and tablets. Then install and ad-blocker.

  • Are Darwin-based OSes, such as macOS and iOS, affected by this?

    And if so, any information as to whether it is being, if has been, patched in those OSes?

Slashdot Top Deals

Our OS who art in CPU, UNIX be thy name. Thy programs run, thy syscalls done, In kernel as it is in user!

Close