The Stack Clash CVE-2017-1000364
-
See article: https://threatpost.com/stack-clash-vulnerability-in-linux-bsd-systems-enables-root-access/126355/
-
Not sure where this needs to go. I was wondering if there anything in the works to fix this asap?
I do believe this is the original article about it.
https://blog.qualys.com/securitylabs/2017/06/19/the-stack-clash
-
My laymen's understanding. It's not an inherent security flaw, it just means one of the anti-exploit defenses does not work as well as expected.
-
Once FreeBSD fixes it, we'll pull in the changes from there. We already have a patch release cooking for some other issues that need addressed, but depending on when they put out a fix it would be included.
I've heard they are working on it, but it affects primarily 32-bit platforms and exploiting it is unlikely, especially in the context of a firewall.
So it's worth fixing, but the sky isn't falling. At least for FreeBSD.
EDIT: Merging duplicate threads in here, so the posts may seem a bit disjointed.
-
It's not exploitable remotely on pfSense unless the admin has done something to allow an unprivileged user to login and run their exploit code on the system. In general you don't allow untrusted users to run their own code on your firewall.
-
From threatpost.com
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.
See article here:
https://threatpost.com/stack-clash-vulnerability-in-linux-bsd-systems-enables-root-access/126355/ -
It's being worked on.
https://forum.pfsense.org/index.php?topic=132534.msg728726#msg728726
-
@Jailer you linked the wrong thread. That's the OpenVPN vulnerability which is quite different.
FreeBSD just pushed a fix to head (12-CURRENT) and it should be MFC'ed to supported stable and releng branches pretty soon.
https://lists.freebsd.org/pipermail/freebsd-security/2017-June/009343.html
https://svnweb.freebsd.org/base?view=revision&revision=320317
-
Also the vulnerability is not a threat to a properly configured pfSense system that doesn't allow unprivileged/untrusted login/execute access to the system.
-
Fixed on FreeBSD head (12-CURRENT) and MFC expected to supported stable and releng brances within a week.
https://lists.freebsd.org/pipermail/freebsd-security/2017-June/009343.html
https://svnweb.freebsd.org/base?view=revision&revision=320317
@admins Please merge this thread here:
-
My laymen's understanding. It's not an inherent security flaw, it just means one of the anti-exploit defenses does not work as well as expected.
It is definitely an inherent security flaw. An unprivileged process should never be able to play games with the system's memory management and trick it into allocating more stack pages from an area of memory that the process already had access to. If the attacker can do that it opens up many opportunities for compromise because the stack contains the return addresses for function calls and if you manage to manipulate those anything is possible. The classic case is the (possibly the world's first such incident) Morris worm:
-
@kpa:
@Jailer you linked the wrong thread. That's the OpenVPN vulnerability which is quite different.
FreeBSD just pushed a fix to head (12-CURRENT) and it should be MFC'ed to supported stable and releng branches pretty soon.
https://lists.freebsd.org/pipermail/freebsd-security/2017-June/009343.html
https://svnweb.freebsd.org/base?view=revision&revision=320317
Yes but if you read what I linked to which was jimp responding to a question about the opnevpn vulnerability he mentions that they are holding off an update to 2.3.4 waiting for the stack clash fix from FreeBSD.
Edit: And here's a thread already discussing the issue.
https://forum.pfsense.org/index.php?topic=132413.msg728050#new
-
@kpa:
My laymen's understanding. It's not an inherent security flaw, it just means one of the anti-exploit defenses does not work as well as expected.
It is definitely an inherent security flaw. An unprivileged process should never be able to play games with the system's memory management and trick it into allocating more stack pages from an area of memory that the process already had access to. If the attacker can do that it opens up many opportunities for compromise because the stack contains the return addresses for function calls and if you manage to manipulate those anything is possible. The classic case is the (possibly the world's first such incident) Morris worm:
Yeah, turned out it was something more nefarious. It wasn't just about smashing stacks in an application's own virtual memory, but being able to access kernel memory, allowing for priv esc attack.
