3 ms·

It is possible to prevent libraries from patching functions in other libraries; make those VM regions unwritable, don't let anyone make them writable, and adopt

It is possible to prevent libraries from patching functions in other libraries; make those VM regions unwritable, don't let anyone make them writable, and adopt PAC or similar hardware protection so the kernel can't overwrite them either.

rwmj 3y ago
That's already done, but in this case the attack happened in a glibc ifunc and those run before the patching protection is enabled (since an ifunc has to patch the PLT).
- astrange 3y ago
  Sounds like libraries should only get to patch themselves. (Some difficulty with this one though. For instance you probably have to ban running arbitrary code at load time, but you should do this anyway because it will stop people from writing C++.)
  - rwmj 3y ago
    They're all in a single address space, there's nothing you can do to stop one part of a binary patching any other part.
    - astrange 3y ago
      I already said the way to do it in my previous comment. Don't let arbitrary code run before page permissions are locked down.
      - rwmj 3y ago
        If you're running in the binary you can call mprotect(2), and even if that is blocked you can cause all kinds of mischief. The original motivation for rings of protection on i286 was so that libraries could run in a different ring from the binary (usually library in ring 2 and program in ring 3), using a call gate (a very controlled type of call) to dispatch calls from the binary to the library, which stops the binary from modifying the library and IIRC libraries from touching each other. But x86-64 got rid of the middle rings.
        astrange 3y ago
        > If you're running in the binary you can call mprotect(2) Darwin doesn't let you make library regions writable after dyld is finished with them. (Especially iOS where codesigning also prevents almost all other ways to get around this.) Something like OpenBSD pledge() can also revoke access to it in general. > But x86-64 got rid of the middle rings. x86 is a particularly insecure architecture but there's no need for things to be that way. That's why I mentioned PAC, which prevents other processes (including the kernel) from forging pointers even if they can write to another process's memory.
dotancohen 3y ago
That does not sound like the type of machine that I want to work on. I still require a general purpose computer.
- astrange 3y ago
  Why does a general purpose computer need to overwrite crypto functions in sshd?
  - salawat 3y ago
    Because it's a general purpose computer. Duh. The aim is to be able to arbitrary computations. Which overwriting crypto functions in sshd is a valid computation to be considered.
    - astrange 3y ago
      I don't think you should connect your general purpose computer to the internet then. Or keep any valuable data on it. Otherwise other people are going to get to perform computations on it.

rwmj 3y ago

That's already done, but in this case the attack happened in a glibc ifunc and those run before the patching protection is enabled (since an ifunc has to patch the PLT).

astrange 3y ago
Sounds like libraries should only get to patch themselves. (Some difficulty with this one though. For instance you probably have to ban running arbitrary code at load time, but you should do this anyway because it will stop people from writing C++.)
- rwmj 3y ago
  They're all in a single address space, there's nothing you can do to stop one part of a binary patching any other part.
  - astrange 3y ago
    I already said the way to do it in my previous comment. Don't let arbitrary code run before page permissions are locked down.
    - rwmj 3y ago
      If you're running in the binary you can call mprotect(2), and even if that is blocked you can cause all kinds of mischief. The original motivation for rings of protection on i286 was so that libraries could run in a different ring from the binary (usually library in ring 2 and program in ring 3), using a call gate (a very controlled type of call) to dispatch calls from the binary to the library, which stops the binary from modifying the library and IIRC libraries from touching each other. But x86-64 got rid of the middle rings.
      - astrange 3y ago
        > If you're running in the binary you can call mprotect(2) Darwin doesn't let you make library regions writable after dyld is finished with them. (Especially iOS where codesigning also prevents almost all other ways to get around this.) Something like OpenBSD pledge() can also revoke access to it in general. > But x86-64 got rid of the middle rings. x86 is a particularly insecure architecture but there's no need for things to be that way. That's why I mentioned PAC, which prevents other processes (including the kernel) from forging pointers even if they can write to another process's memory.

dotancohen 3y ago

That does not sound like the type of machine that I want to work on. I still require a general purpose computer.

astrange 3y ago
Why does a general purpose computer need to overwrite crypto functions in sshd?
- salawat 3y ago
  Because it's a general purpose computer. Duh. The aim is to be able to arbitrary computations. Which overwriting crypto functions in sshd is a valid computation to be considered.
  - astrange 3y ago
    I don't think you should connect your general purpose computer to the internet then. Or keep any valuable data on it. Otherwise other people are going to get to perform computations on it.