6 ms·

OK, if I understand correctly, there is no privilege escalation. Eg., running this exploit in user code doesn't get you root. When they described it as a "kerne

OK, if I understand correctly, there is no privilege escalation. Eg., running this exploit in user code doesn't get you root. When they described it as a "kernel hole" I assumed it was much worse. So the word "kernel" is there because the design flaw is in the kernel, not because it allows a complete system takeover (unless it's against a privileged program).

qb45 9y ago
Yes, it's a kernel deficiency which only allows taking over userspace processes and only if you are able to cause them to allocate the right memory and write the right data to it.
clarry 9y ago
> So the word "kernel" is there because the design flaw is in the kernel The vulnerability is in the userland process. However, the kernel can utilize a stop-gap measure that makes exploitation difficult in most scenarios (but this is arbitrary).
- kronos29296 9y ago
  Then why is nobody trying to fix the vulnerability at the source ie. userland process?
  - cyphar 9y ago
    To butcher an LWN quote, "there are potentially millions of buggy programs, but only one kernel". It's a measure to prevent a class of exploit, rather than depending on people writing safe C code (which I believe decades of software engineering have proven we are collectively incapable of doing).
    - clarry 9y ago
      This has nothing to do with the (un)safety of C code. The programs do not have to be buggy at the source level. The compiler is the bug.
  - clarry 9y ago
    To do that, you need to have a compiler that has the right features, and then you need to recompile all your software.
  - PeterisP 9y ago
    There exists a fix for the vulnerability at the source, namely, a compiler feature that will add extra code that will "touch" every 4k page of the stack if large amount is allocated. However, for that fix to be useful, every single distribution needs to recompile every single userland package and distribute it to every single user - i.e., instead of downloading a security patch, you need to download a new version of every executable on your hdd.
    - loeg 9y ago
      It could be limited to only programs that are setuid.
      - stouset 9y ago
        This applies generally to any program running as root (or a user with other privileges than yourself) if you can find a way to allocate a large enough segment of memory.
        loeg 9y ago
        So setuid programs and network servers, for example.
    - kronos29296 9y ago
      Can't the changes be gradually introduced? We change distros every year or reinstall the OS every time a new version of the distro is released. That's a newly compiled set of executables that are being installed every year. If the distro guys just did for the next version (Atleast the guys like Debian, Fedora etc from whom most other distros are derived) wouldn't most systems be protected? It would take a while but it wouldn't take 10 years atleast. Mass adoption is impossible but incremental changes are. If critical executables are patched then we have atleast a partially protected system right? (I am not an expert but this sounds a bit more plausible than breaking the entire userland)
- qb45 9y ago
  Not really. This time it's CPU and kernel failing to provide expected behavior in some corner cases which makes otherwise correct userland programs vulnerable to attacks for no fault of their own.
  - clarry 9y ago
    It is impossible for the CPU (without architectural changes, e.g. stack segment) and kernel to provide expected behavior in the general case. They do not know whether the userland process is trying to use the stack or just access some other mapped region. Indeed, as long as these accesses do not land upon unmapped space (or space mapped with permissions that conflict with the access), the kernel doesn't have any idea what's going on.
PeterisP 9y ago
No, this does mean privilege escalation (pretty much all recent proof of concepts for this problem are local user-to-root escalation) because it allows you to engineer a stack/heap overwrite in many non-buggy binaries that run as root.
21 9y ago
The other article says that this is a privilege escalation: > 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. https://blog.qualys.com/securitylabs/2017/06/19/the-stack-clash https://blog.qualys.com/securitylabs/2017/06/19/the-stack-cl...
- loeg 9y ago
  Only if you find an exploitable setuid program.

qb45 9y ago

Yes, it's a kernel deficiency which only allows taking over userspace processes and only if you are able to cause them to allocate the right memory and write the right data to it.

clarry 9y ago

> So the word "kernel" is there because the design flaw is in the kernel The vulnerability is in the userland process. However, the kernel can utilize a stop-gap measure that makes exploitation difficult in most scenarios (but this is arbitrary).

kronos29296 9y ago
Then why is nobody trying to fix the vulnerability at the source ie. userland process?
- cyphar 9y ago
  To butcher an LWN quote, "there are potentially millions of buggy programs, but only one kernel". It's a measure to prevent a class of exploit, rather than depending on people writing safe C code (which I believe decades of software engineering have proven we are collectively incapable of doing).
  - clarry 9y ago
    This has nothing to do with the (un)safety of C code. The programs do not have to be buggy at the source level. The compiler is the bug.
- clarry 9y ago
  To do that, you need to have a compiler that has the right features, and then you need to recompile all your software.
- PeterisP 9y ago
  There exists a fix for the vulnerability at the source, namely, a compiler feature that will add extra code that will "touch" every 4k page of the stack if large amount is allocated. However, for that fix to be useful, every single distribution needs to recompile every single userland package and distribute it to every single user - i.e., instead of downloading a security patch, you need to download a new version of every executable on your hdd.
  - loeg 9y ago
    It could be limited to only programs that are setuid.
    - stouset 9y ago
      This applies generally to any program running as root (or a user with other privileges than yourself) if you can find a way to allocate a large enough segment of memory.
      - loeg 9y ago
        So setuid programs and network servers, for example.
  - kronos29296 9y ago
    Can't the changes be gradually introduced? We change distros every year or reinstall the OS every time a new version of the distro is released. That's a newly compiled set of executables that are being installed every year. If the distro guys just did for the next version (Atleast the guys like Debian, Fedora etc from whom most other distros are derived) wouldn't most systems be protected? It would take a while but it wouldn't take 10 years atleast. Mass adoption is impossible but incremental changes are. If critical executables are patched then we have atleast a partially protected system right? (I am not an expert but this sounds a bit more plausible than breaking the entire userland)
qb45 9y ago
Not really. This time it's CPU and kernel failing to provide expected behavior in some corner cases which makes otherwise correct userland programs vulnerable to attacks for no fault of their own.
- clarry 9y ago
  It is impossible for the CPU (without architectural changes, e.g. stack segment) and kernel to provide expected behavior in the general case. They do not know whether the userland process is trying to use the stack or just access some other mapped region. Indeed, as long as these accesses do not land upon unmapped space (or space mapped with permissions that conflict with the access), the kernel doesn't have any idea what's going on.

PeterisP 9y ago

No, this does mean privilege escalation (pretty much all recent proof of concepts for this problem are local user-to-root escalation) because it allows you to engineer a stack/heap overwrite in many non-buggy binaries that run as root.

21 9y ago

The other article says that this is a privilege escalation: > 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. https://blog.qualys.com/securitylabs/2017/06/19/the-stack-clash https://blog.qualys.com/securitylabs/2017/06/19/the-stack-cl...

loeg 9y ago
Only if you find an exploitable setuid program.