4 ms·

Yet another vulnerability and exploit that just wouldn't be possible on a well-designed system, such as Genode[0] with seL4[1]. Monolithic UNIX clones are an a

by snvzz 4y ago

Yet another vulnerability and exploit that just wouldn't be possible on a well-designed system, such as Genode[0] with seL4[1]. Monolithic UNIX clones are an anachronism we are well past the time to get rid of. 0. https://genode.org/ https://genode.org/ 1. https://sel4.systems/ https://sel4.systems/

jacquesm 4y ago
Pity to see this downvoted because it is a valid point. We are stuck in the past with these macro kernels and this sort of thing is a direct consequence of using them. If anything having a macro kernel makes it quite hard to shut down a module like this to determine if it was well behaved with respect to memory and because it is in the kernel any kind of compromise immediately has far reaching consequences because it breaches all of the barriers in one fell swoop.
- yjftsjthsd-h 4y ago
  > If anything having a macro kernel makes it quite hard to shut down a module like this to determine if it was well behaved with respect to memory Unloading modules is generally possible, but I'm not quite following what shutting it down has to do with checking memory use?
  - jacquesm 4y ago
    Use-after-free bugs are pretty easy to figure out on shutdown because you can free the remainder of your working memory and if it turns out that you have a use-after-free there likely will be a double free in there somewhere. If not then the problem is more insidious but I've found plenty of use-after-free bugs that way.
    - Sirened 4y ago
      Most exploited UAFs don't happen in common execution paths. They're often caused by weird races and error conditions that nobody considered to even happen. It's why things like production ASan is a lot less valuable than people would imagine: most reasonably well tested software doesn't exhibit memory corruption when used normally. So, sure, your suggested technique could be a cool way to try and catch bugs that appear under normal execution but it won't put that much of a dent in the total number of bugs.
      - jacquesm 4y ago
        That may well be true, even so debugging a kernel module is quite a lot harder than a regular process so the fact that it is a kernel module by itself probably increases the chances of such bugs being present. Especially because you are not in control of the execution context.
- rwmj 4y ago
  Valgrind too - only applicable to userspace processes and it would have caught this UAF.
yjftsjthsd-h 4y ago
Okay, so we move to microkernels, which murders everybody's performance because we still don't know how to work around context switching being expensive, and force everyone to do the constant additional effort to define exactly what components should have permission to access what parts of their system (unless you want everybody to use one-size-fits-all defaults and lose functionality, or just give everything more permission and lose the security benefit). Now in this hypothetical world, an SMB server has a vulnerability. Technically, the situation is much improved; in this situation an attacker only has access to whatever that component had access to. So, just all the files you shared, and (hopefully read-only) user information. And probably network access. Is that really a good cost/benefit trade?
- xwolfi 4y ago
  No, micro kernel are only liked by people with limited imagination. They are perfect, yet unusable.
  - jacquesm 4y ago
    Every vehicle you've driven that was made in the last 25 years has one or more instances of micro kernels in them. They are perfectly usable, and the performance hit isn't nearly what people think it is. What you give up in throughput you more than get back in deterministic behavior, reliability and improved latency.
  - nix23 4y ago
    Blackberry(QNX), Nokia(Symbian), MarsRover (VxWorks), TrueUnix64, Windows and and and...but yeah they are unusable.
- jacquesm 4y ago
  > because we still don't know how to work around context switching being expensive Context switching can be as expensive as you want, or almost as cheap as you want depending on the limitations of the hardware. Back in 1992 on by todays' standards very anemic hardware you could do 200K slices per second, today likely orders of magnitude more than that. I suspect that lots of people - not necessarily you - that have very clear opinions on micro kernels and their capabilities have never actually used them.

by snvzz 4y ago

jacquesm 4y ago

Pity to see this downvoted because it is a valid point. We are stuck in the past with these macro kernels and this sort of thing is a direct consequence of using them. If anything having a macro kernel makes it quite hard to shut down a module like this to determine if it was well behaved with respect to memory and because it is in the kernel any kind of compromise immediately has far reaching consequences because it breaches all of the barriers in one fell swoop.

yjftsjthsd-h 4y ago
> If anything having a macro kernel makes it quite hard to shut down a module like this to determine if it was well behaved with respect to memory Unloading modules is generally possible, but I'm not quite following what shutting it down has to do with checking memory use?
- jacquesm 4y ago
  Use-after-free bugs are pretty easy to figure out on shutdown because you can free the remainder of your working memory and if it turns out that you have a use-after-free there likely will be a double free in there somewhere. If not then the problem is more insidious but I've found plenty of use-after-free bugs that way.
  - Sirened 4y ago
    Most exploited UAFs don't happen in common execution paths. They're often caused by weird races and error conditions that nobody considered to even happen. It's why things like production ASan is a lot less valuable than people would imagine: most reasonably well tested software doesn't exhibit memory corruption when used normally. So, sure, your suggested technique could be a cool way to try and catch bugs that appear under normal execution but it won't put that much of a dent in the total number of bugs.
    - jacquesm 4y ago
      That may well be true, even so debugging a kernel module is quite a lot harder than a regular process so the fact that it is a kernel module by itself probably increases the chances of such bugs being present. Especially because you are not in control of the execution context.
rwmj 4y ago
Valgrind too - only applicable to userspace processes and it would have caught this UAF.

yjftsjthsd-h 4y ago

Okay, so we move to microkernels, which murders everybody's performance because we still don't know how to work around context switching being expensive, and force everyone to do the constant additional effort to define exactly what components should have permission to access what parts of their system (unless you want everybody to use one-size-fits-all defaults and lose functionality, or just give everything more permission and lose the security benefit). Now in this hypothetical world, an SMB server has a vulnerability. Technically, the situation is much improved; in this situation an attacker only has access to whatever that component had access to. So, just all the files you shared, and (hopefully read-only) user information. And probably network access. Is that really a good cost/benefit trade?

xwolfi 4y ago
No, micro kernel are only liked by people with limited imagination. They are perfect, yet unusable.
- jacquesm 4y ago
  Every vehicle you've driven that was made in the last 25 years has one or more instances of micro kernels in them. They are perfectly usable, and the performance hit isn't nearly what people think it is. What you give up in throughput you more than get back in deterministic behavior, reliability and improved latency.
- nix23 4y ago
  Blackberry(QNX), Nokia(Symbian), MarsRover (VxWorks), TrueUnix64, Windows and and and...but yeah they are unusable.
jacquesm 4y ago
> because we still don't know how to work around context switching being expensive Context switching can be as expensive as you want, or almost as cheap as you want depending on the limitations of the hardware. Back in 1992 on by todays' standards very anemic hardware you could do 200K slices per second, today likely orders of magnitude more than that. I suspect that lots of people - not necessarily you - that have very clear opinions on micro kernels and their capabilities have never actually used them.