4 ms·

Sure, it could be, but in a capability system if the application is starting that JNDI component, granting it network access, and granting the logger access to

Sure, it could be, but in a capability system if the application is starting that JNDI component, granting it network access, and granting the logger access to it: 1) It's pretty dang explicit to the programmer that they're granting the logger network access, because they're the ones writing that logic. 2) Even if you've granted the logger network access, you probably haven't granted it complete access to your filesystem. Network access isn't the only sensitive thing on your system, and a logging library needs very little authority to operate (specific files/directories and its own config?). Getting code execution in the logger shouldn't be game over security-wise, because it shouldn't have that much authority to begin with.

monocasa 5y ago
What it would probably look like was they were granting an IPC channel to the JNDI component, just like they would for DNS or what have you. And then separately "ok, yeah, JNDI needs network access, that makes sense". So you wouldn't see network access directly in the capability manifest for the logging component. None of this protects you from "fuck it, load class file from random ldap server" that was apparently coded up in JNDI.
- Ericson2314 5y ago
  Let's not conflate network access to get the thing from LDAP and network access for the thing itself. In fact, it's exactly programming with capabilities that would keep this stuff separate, as no one would design the JNDI interface to wantonly pass all the same capabilities to the class. Well-sandboxed arbitrary byte-code is remote code execution I am OK with!
  - cesarb 5y ago
    > Well-sandboxed arbitrary byte-code is remote code execution I am OK with! I used to be OK with that too, until Rowhammer showed that sandboxing is more fragile than one would expect. And then came Spectre...
    - Ericson2314 5y ago
      Yeah it is scary and depressing, but I suppose I just couldn't live in this industry of those are the fatalistic last word. Trying clean up all the accidental complexity that goes with the ambient authority, using capabilities, will free up "complexity budget" to ponder various timing attacks and whatnot. I think the problems are solvable if only we are willing to move the goal posts from our current obsession over back-compat uber alles that makes everything difficult. As I understand it, the m1 is similarly better not because any fundamental insight, but because not worrying about various x86 accidental complexity just makes it easier to do things like deeper instruction fetching pipelines etc. (Of course TSMC just killing it doesn't hurt either.)
  - monocasa 5y ago
    > Let's not conflate network access to get the thing from LDAP and network access for the thing itself. Why not? The attacker's goal was to run untrusted code on your server. They don't necessarily care if it's running in the JNDI process or the server component that's logging as the first step. It's a beachhead into a pretty trusted component, and exploits these days are long chains. I'm sure there are other components over those IPC channels that aren't expecting JNDI to be lying now which can be used to expand that beachhead. > as no one would design the JNDI interface to wantonly pass all the same capabilities to the class. Just as 'no one' would load random class files off of untrusted servers into a vm without the fine grained capabilities you're talking about? > Well-sandboxed arbitrary byte-code is remote code execution I am OK with! I agree with the spirit, but haven't found a sandbox that stayed "well-sandboxed" over time.
    - Ericson2314 5y ago
      Excuse us true believers, but the idea is capabilities avoid the https://xkcd.com/2044/ https://xkcd.com/2044/ trap by being just dynamic enough. I would certainly agree not to trust any other sort of sandboxing. E.g. I don't trust Linux namespaces (as the linux devs themselve say you shouldn't) because the syscall interface is far too complex and subtle). But something like CloudABI or Fuschia or seL4 is dramatically narrower in scope.
      - monocasa 5y ago
        I'm talking from experience here with capability systems on microkernels. Capability-based security is a tool, not a panacea. Exploit chains these days are very used to having to jump through IPC channels to components with different privileges to get everything they need. Edit: As an aside, rather than looking towards namespaces for an attempt at the same structure, seccomp BPF is the primitive I've found that creates the closest thing to the capability system you're talking about. That way you can leave a process with only recvmsg/sendmsg on unix domain sockets, and maybe mmap for memfds shared across processes.
        justinpombrio 5y ago

monocasa 5y ago

What it would probably look like was they were granting an IPC channel to the JNDI component, just like they would for DNS or what have you. And then separately "ok, yeah, JNDI needs network access, that makes sense". So you wouldn't see network access directly in the capability manifest for the logging component. None of this protects you from "fuck it, load class file from random ldap server" that was apparently coded up in JNDI.

Ericson2314 5y ago
Let's not conflate network access to get the thing from LDAP and network access for the thing itself. In fact, it's exactly programming with capabilities that would keep this stuff separate, as no one would design the JNDI interface to wantonly pass all the same capabilities to the class. Well-sandboxed arbitrary byte-code is remote code execution I am OK with!
- cesarb 5y ago
  > Well-sandboxed arbitrary byte-code is remote code execution I am OK with! I used to be OK with that too, until Rowhammer showed that sandboxing is more fragile than one would expect. And then came Spectre...
  - Ericson2314 5y ago
    Yeah it is scary and depressing, but I suppose I just couldn't live in this industry of those are the fatalistic last word. Trying clean up all the accidental complexity that goes with the ambient authority, using capabilities, will free up "complexity budget" to ponder various timing attacks and whatnot. I think the problems are solvable if only we are willing to move the goal posts from our current obsession over back-compat uber alles that makes everything difficult. As I understand it, the m1 is similarly better not because any fundamental insight, but because not worrying about various x86 accidental complexity just makes it easier to do things like deeper instruction fetching pipelines etc. (Of course TSMC just killing it doesn't hurt either.)
- monocasa 5y ago
  > Let's not conflate network access to get the thing from LDAP and network access for the thing itself. Why not? The attacker's goal was to run untrusted code on your server. They don't necessarily care if it's running in the JNDI process or the server component that's logging as the first step. It's a beachhead into a pretty trusted component, and exploits these days are long chains. I'm sure there are other components over those IPC channels that aren't expecting JNDI to be lying now which can be used to expand that beachhead. > as no one would design the JNDI interface to wantonly pass all the same capabilities to the class. Just as 'no one' would load random class files off of untrusted servers into a vm without the fine grained capabilities you're talking about? > Well-sandboxed arbitrary byte-code is remote code execution I am OK with! I agree with the spirit, but haven't found a sandbox that stayed "well-sandboxed" over time.
  - Ericson2314 5y ago
    Excuse us true believers, but the idea is capabilities avoid the https://xkcd.com/2044/ https://xkcd.com/2044/ trap by being just dynamic enough. I would certainly agree not to trust any other sort of sandboxing. E.g. I don't trust Linux namespaces (as the linux devs themselve say you shouldn't) because the syscall interface is far too complex and subtle). But something like CloudABI or Fuschia or seL4 is dramatically narrower in scope.
    - monocasa 5y ago
      I'm talking from experience here with capability systems on microkernels. Capability-based security is a tool, not a panacea. Exploit chains these days are very used to having to jump through IPC channels to components with different privileges to get everything they need. Edit: As an aside, rather than looking towards namespaces for an attempt at the same structure, seccomp BPF is the primitive I've found that creates the closest thing to the capability system you're talking about. That way you can leave a process with only recvmsg/sendmsg on unix domain sockets, and maybe mmap for memfds shared across processes.
      - justinpombrio 5y ago