5 ms·

Will it be possible to override / disable the `mseal' syscall with the LD_PRELOAD trick?

the8472 2y ago
https://lwn.net/Articles/978010/ https://lwn.net/Articles/978010/ says there'll be a glibc tunable
eska 2y ago
mseal digresses from prior memory protection schemes on Linux because it is a syscall tailored specifically for exploit mitigation against remote attackers seeking code execution rather than potentially local ones looking to exfiltrate sensitive secrets in-memory. If a remote attacker can change the local environment then they must have already broken into your system.
- deleted 2y ago
  [deleted]
- gcr 2y ago
  Not necessarily. By posting this comment, I have caused "THIS STRING IS HARMFUL" to enter your computer's memory! If you see my comment on your screen, it's too late -- as a remote attacker, I have already changed the local environment! I've even slightly changed the rendering of the webpage you're looking at! Muahahah! The point is that "The local environment" could refer to what's inside the sandbox. Your browser isn't going to treat my comment as x86 machine code and execute it, for example. Javascript is heavily sandboxed, and mseal() and friends are ways to add another layer of sandboxing.
  - rowanG077 2y ago
    The poster obviously meant environment variables as in the LD_PRELOAD variable mentioned previously...
chucky_z 2y ago
You can override the mseal call wrapper but not the syscall itself. This is an interesting thought so I looked it up and this is how (all?) preload syscall overrides work. You override the wrapper but not the syscalls itself so if you’re doing direct syscalls I don’t think that can be overridden. Technically you could override the syscall function itself maybe?
- jmmv 2y ago
  > Technically you could override the syscall function itself maybe? But then you can just write assembly code to issue the system call.
Dwedit 2y ago
Probably not LD_PRELOAD. It would need to be an imported function in order for LD_PRELOAD to have any effect. A raw syscall would not be interceptable that way. Discussion about intercepting linux syscalls: https://stackoverflow.com/questions/69859/how-could-i-intercept-linux-sys-calls https://stackoverflow.com/questions/69859/how-could-i-interc... But building your own patched kernel that pretends that mseal works would be the simplest way to "disable" that feature. Programs that use mseal could still do sanity checks to see if mseal actually works or not. Then a compromised kernel would need secret ways to disable mseal after it has been applied, to stop the apps from checking for a non-functional mseal.
- jandrese 2y ago
  I'm not sure what protection you could expect on any system where the kernel has been replaced by the attacker. Sure they can bypass mseal, but they are also bypassing all other security on the box.
  - Dwedit 2y ago
    Two different considerations for when you'd want to deny memory to other processes: Protecting against outside attackers Digital Rights Management Faking "mseal" is something you might intentionally do if you are trying to break DRM, and something you would not want to do if you are trying to defend against outside attackers.
    - adrian_b 2y ago
      The kernel can bypass any memory protection, it does not need to fake mseal. Controlling the memory protection is one of the most important functions of any OS kernel and one of the few that could not be implemented in any other place. Some CPUs have special hardware means for protecting some memory region against the kernel ("secure enclaves", e.g. Intel SGX), and that is the feature that the supporters of DRM want. "Mseal" is only against attackers who do not control the kernel.
cataphract 2y ago
Depends whether the program calls into libc or inlines the syscalls, I imagine. Though you could use other mechanisms like secccomp.
monocasa 2y ago
There's a bunch of ways to override it if you have early control over the process. Another example: ptrace the executable, watch the system calls, and skip over any mseal(2)s. This system call is meant for a different threat model than "attacker has early access to your process before it started initializing".

https://lwn.net/Articles/978010/ https://lwn.net/Articles/978010/ says there'll be a glibc tunable

eska 2y ago

mseal digresses from prior memory protection schemes on Linux because it is a syscall tailored specifically for exploit mitigation against remote attackers seeking code execution rather than potentially local ones looking to exfiltrate sensitive secrets in-memory. If a remote attacker can change the local environment then they must have already broken into your system.

deleted 2y ago
[deleted]
gcr 2y ago
Not necessarily. By posting this comment, I have caused "THIS STRING IS HARMFUL" to enter your computer's memory! If you see my comment on your screen, it's too late -- as a remote attacker, I have already changed the local environment! I've even slightly changed the rendering of the webpage you're looking at! Muahahah! The point is that "The local environment" could refer to what's inside the sandbox. Your browser isn't going to treat my comment as x86 machine code and execute it, for example. Javascript is heavily sandboxed, and mseal() and friends are ways to add another layer of sandboxing.
- rowanG077 2y ago
  The poster obviously meant environment variables as in the LD_PRELOAD variable mentioned previously...

chucky_z 2y ago

You can override the mseal call wrapper but not the syscall itself. This is an interesting thought so I looked it up and this is how (all?) preload syscall overrides work. You override the wrapper but not the syscalls itself so if you’re doing direct syscalls I don’t think that can be overridden. Technically you could override the syscall function itself maybe?

jmmv 2y ago
> Technically you could override the syscall function itself maybe? But then you can just write assembly code to issue the system call.

Dwedit 2y ago

Probably not LD_PRELOAD. It would need to be an imported function in order for LD_PRELOAD to have any effect. A raw syscall would not be interceptable that way. Discussion about intercepting linux syscalls: https://stackoverflow.com/questions/69859/how-could-i-intercept-linux-sys-calls https://stackoverflow.com/questions/69859/how-could-i-interc... But building your own patched kernel that pretends that mseal works would be the simplest way to "disable" that feature. Programs that use mseal could still do sanity checks to see if mseal actually works or not. Then a compromised kernel would need secret ways to disable mseal after it has been applied, to stop the apps from checking for a non-functional mseal.

jandrese 2y ago
I'm not sure what protection you could expect on any system where the kernel has been replaced by the attacker. Sure they can bypass mseal, but they are also bypassing all other security on the box.
- Dwedit 2y ago
  Two different considerations for when you'd want to deny memory to other processes: Protecting against outside attackers Digital Rights Management Faking "mseal" is something you might intentionally do if you are trying to break DRM, and something you would not want to do if you are trying to defend against outside attackers.
  - adrian_b 2y ago
    The kernel can bypass any memory protection, it does not need to fake mseal. Controlling the memory protection is one of the most important functions of any OS kernel and one of the few that could not be implemented in any other place. Some CPUs have special hardware means for protecting some memory region against the kernel ("secure enclaves", e.g. Intel SGX), and that is the feature that the supporters of DRM want. "Mseal" is only against attackers who do not control the kernel.

cataphract 2y ago

Depends whether the program calls into libc or inlines the syscalls, I imagine. Though you could use other mechanisms like secccomp.

monocasa 2y ago

There's a bunch of ways to override it if you have early control over the process. Another example: ptrace the executable, watch the system calls, and skip over any mseal(2)s. This system call is meant for a different threat model than "attacker has early access to your process before it started initializing".