3 ms·

Hey, author, thanks for commenting. AFAIR, you also are the guy who criticizes Ubuntu's policy regarding derivative works. Anyway, I have a question for you. I

by xkxx 10y ago

Hey, author, thanks for commenting. AFAIR, you also are the guy who criticizes Ubuntu's policy regarding derivative works. Anyway, I have a question for you. If I understand rkt's architecture correctly, the hypervisor runs multiple Linux kernel instances, every kernel runs several processes. If somebody exploits one of those processes and creates a root-owned process, then rkt detects such an attempt and restarts the kernel. But what if the exploit doesn't create any root-owned processes? You can get rights equal to those of the superuser without getting uid=0.

mjg59 10y ago
It also detects any bump in capabilities. Getting superuser level abilities without modifying either your uid or your capabilities would require modification of kernel code.
- xkxx 10y ago
  > would require modification of kernel code And it's impossible for an exploit to do because?.. EDIT: "?.." in this case means "please continue my sentence".
  - mjg59 10y ago
    Kernel code is mapped read only
    - xkxx 10y ago
      Thanks for taking time to answer my questions. > Kernel code is mapped read only What part of the system makes sure that read-only kernel code stays read-only? Is it hardware or the hypervisor? Another question. Is there any chance that you missed something and there's a way to get privilleged access without actually modifying your uid, bumping your capabilities or modifying kernel code?
      - mjg59 10y ago
        The hardware - it's an attribute on the page table. You could certainly monitor that from the hypervisor as well, although there'd be some performance overhead. You can avoid all of these protections if you can inject new code into an existing privileged process or SUID executable, which is how DirtyCOW worked. The blog points out that this class of vulnerability isn't covered.
        xkxx 10y ago
        > The hardware - it's an attribute on the page table. And the only way to make the page writable again is to clear the page first. Am I correct? > You can avoid all of these protections if you can inject new code into an existing privileged process or SUID executable, which is how DirtyCOW worked. It can happen if either one of these is true: 1) the existing privileged process or SUID executable is vulnerable; 2) the kernel is vulnerable. DirtyCOW is interesting because it's the case #2. The case #1 is not that interesting, because targeting vulnerable privileged executables is a known attack vector.

by xkxx 10y ago

mjg59 10y ago

It also detects any bump in capabilities. Getting superuser level abilities without modifying either your uid or your capabilities would require modification of kernel code.

xkxx 10y ago
> would require modification of kernel code And it's impossible for an exploit to do because?.. EDIT: "?.." in this case means "please continue my sentence".
- mjg59 10y ago
  Kernel code is mapped read only
  - xkxx 10y ago
    Thanks for taking time to answer my questions. > Kernel code is mapped read only What part of the system makes sure that read-only kernel code stays read-only? Is it hardware or the hypervisor? Another question. Is there any chance that you missed something and there's a way to get privilleged access without actually modifying your uid, bumping your capabilities or modifying kernel code?
    - mjg59 10y ago
      The hardware - it's an attribute on the page table. You could certainly monitor that from the hypervisor as well, although there'd be some performance overhead. You can avoid all of these protections if you can inject new code into an existing privileged process or SUID executable, which is how DirtyCOW worked. The blog points out that this class of vulnerability isn't covered.
      - xkxx 10y ago
        > The hardware - it's an attribute on the page table. And the only way to make the page writable again is to clear the page first. Am I correct? > You can avoid all of these protections if you can inject new code into an existing privileged process or SUID executable, which is how DirtyCOW worked. It can happen if either one of these is true: 1) the existing privileged process or SUID executable is vulnerable; 2) the kernel is vulnerable. DirtyCOW is interesting because it's the case #2. The case #1 is not that interesting, because targeting vulnerable privileged executables is a known attack vector.