Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A capability-safe language would have minimized the Log4j vulnerability

justinpombrio.net

Post reply on HN
Print view View original

71–80 of 158 posts

Re: A capability-safe language would have minimized the Log4j vulnerability

#71

Post by dccoolgai »

teitoklien wrote: post #69

What you need is not a capability safe language, but rather a tool to make application jails and similar systems more accessible. Your os exists for a reason, let it handle the sandboxing for you, and not the language. Otherwise you fall into troubles later with different sandboxing vulnerabilities in different compilers. Have a codebase that compiles using deprecated features which are removed on language version 2.…

Capabilities model is not about "features" which might be deprecated, but more about "access to standard resources". Capabilities e.g. doesn't care that you are running version 3.1.73 of a certain dependency, it cares that you want to open a network connection to 123.76.34 or that you want /usr/bin/secret file.txt.

Re: A capability-safe language would have minimized the Log4j vulnerability

#72

Post by lgrapenthin »

While tools can save us from stupid mistakes, some mistakes are so stupid that relying on tools to prevent them seems much more dangerous even. Log4j should not have been used by anyone, and certainly it should not have been extended and "improved" in an endless cascade of irresponsible additions, likely violating every principle of good practice, ever. I hope that this is what industry people take away from it, not that some magic language feature should have prevented it.

Re: A capability-safe language would have minimized the Log4j vulnerability

#73

Post by monocasa »

jerf wrote: post #68
monocasa wrote: post #25

Earlier quoted context omitted.

Practically (and like is being suggested here in other comments), JNDI would probably be a separate component (maybe a separate process) with network access, and log4j would just send those user provided strings over an IPC channel, and you'd be in exactly the same place at the end of the day.

Ideally, in a perfect world, the capabilities would themselves be something that could travel over an IPC channel, and in fact would have to travel over an IPC channel. The whole point of pervasive capabilities is that there aren't trivial escape hatches that every programmer uses at the drop of a hat. We don't need a new capabilities-based system for that, because we already have that. That's what we all use, every…

It's not that impractical, I've seen systems setup that way with unix domain sockets where you can pass an fd along with a message. I'm trying to remember where (android?), but there's a bluetooth stack setup like this, where your manifest is registered by a trusted entity, that then you talk to over an unix domain socket to get another unix domain socket to the actual bluetooth stack on an IPC endpoint that was setup with the bluetooth stack with only your permission set.

It's just not a panacea. Even if you fracture the permissions, they still exist in many places and exploit chains are used to having to act as the same sort of distributed application as what you're suggesting to exercise those distributed rights.

Re: A capability-safe language would have minimized the Log4j vulnerability

#74

Post by justinpombrio »

monocasa wrote: post #66
Ericson2314 wrote: post #64

Earlier quoted context omitted.

Excuse us true believers, but the idea is capabilities avoid the 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.

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 creat…

> Exploit chains these days are very used to having to jump through IPC channels to components with different privileges to get everything they need.

Thank you for bringing this up; it's an important point. Do you have a sense of what a practical solution might be?

One thing I can imagine is that there's a JNDI component, but to communicate with it over IPC, you need the JNDIComponent capability. This would allow a couple ways to prevent the log4j vulnerability:

1. You don't give the JNDIComponent to log4j.

2. You use capabilities inside JNDI to separate out the bits that use the network from those that don't, and only supply log4j with a JNDIComponentWithoutNetworkAccess.

This requires co-operation between capabilities in the OS and in the programming language, though, which is a big ask. Plus some foresight; much more than as described in my post.

Re: A capability-safe language would have minimized the Log4j vulnerability

#75

Post by jayd16 »

alerighi wrote: post #36
jayd16 wrote: post #9

Earlier quoted context omitted.

It might be useful that some code in a single process have access while other parts do not. How would you propose an OS handle those cases?

And how do you do that, without operating system support? I mean, you can't of course limit that based on the code, in the JVM there is only a single address space, thus every method or class can be instantiated from anywhere in the code (despite public/private/etc. that are only for programmer convenience, they are easily circumvented with reflection, they don't provide any security at all). You can imagine doing so…

If you're asking how th jvm might do it, I can assure you I do not know. If the question is "can this be a language feature" then I say, surely it can be.

A language that supports static analysis and can disallow dynamic dispatch would do the trick, no?

Re: A capability-safe language would have minimized the Log4j vulnerability

#76

Post by justinpombrio »

teitoklien wrote: post #69

What you need is not a capability safe language, but rather a tool to make application jails and similar systems more accessible. Your os exists for a reason, let it handle the sandboxing for you, and not the language. Otherwise you fall into troubles later with different sandboxing vulnerabilities in different compilers. Have a codebase that compiles using deprecated features which are removed on language version 2.…

This is a good point. I talked about capabilities at the language level, but they're just as important if not more-so at the operating system level.

If you have capabilities in the programming language, then you can make guarantees about what resources (like the network) your program's transitive dependencies can use (in process).

If you have capabilities in the OS, then you can make guarantees about what resources a process can use. EDIT: this is how you would use capabilities in the OS to obtain "application jails". But capabilities would be more flexible here, for example by allowing processes to share them.

As monocasa points out in a separate thread, log4j is actually a messy example---messier than I realized when I wrote this post---because the way it (is? might be?) set up is that your application runs in one process, and JNDI in another. Which brings up a lot of design questions around capabilities in the OS and in the language and in how they interact that I don't know much about.

But the primary point of capabilities is to limit how access control can flow from place to place, using standard data-flow mechanisms. In a programming language, this means tying access to whether you have a pointer to an object. In an OS, I think this looks more like OS-level permissions granted to a process, that processes can share with each other.

You don't have some big table somewhere saying who is allowed to do what. Instead, access is granted by a thing, that you can pass around. When you get used to the idea, it just feels very natural and powerful.

Re: A capability-safe language would have minimized the Log4j vulnerability

#77

Post by Spivak »

vsareto wrote: post #18
yjftsjthsd-h wrote: post #12

Earlier quoted context omitted.

Programming language can know more about the program's (intended) state at any given time. The OS can/should frequently be involved, but even then you're frequently doing something like pledge() from the program to let the OS know when/how to restrict you. Doing it totally externally, like SELinux does, is valuable but coarser-grained.

Can you not use network namespaces on Linux to give a process its own restricted network device and then filter that traffic?

Yes, and you can even have a single process with threads in multiple namespaces. But it still doesn’t solve the problem unless you magik passing all log messages to a dedicated pool of threads just for logging.

The process is simply the wrong layer for this boundary, it’s too coarse and trying to hack your way into telling the OS about the parts of your program. OS security treats processes are black boxes, just like hypervisor security treats vms like black boxes. Trying to force it will be extremely clunky.

Re: A capability-safe language would have minimized the Log4j vulnerability

#78

Post by nicoburns »

MattPalmer1086 wrote: post #38
Smaug123 wrote: post #24

Earlier quoted context omitted.

If your language is capable of expressing "this part of the code can't access the network", in a general way such that networking is not some special snowflake that's baked in, then you've created an effects system which is likely to be useful in many, many other contexts for other things you want to assert without having them supported in the OS. (For example, "is this code async", or "does this code print anything"…

That's an interesting idea. Although denying network to log4j wouldn't have stopped this I think, as it was the JNDI code that made the network calls, not log4j directly.

You might be able to be more specific and only allow network connections to whitelisted addresses or similar.

Re: A capability-safe language would have minimized the Log4j vulnerability

#79

Post by catern »

lgrapenthin wrote: post #72

While tools can save us from stupid mistakes, some mistakes are so stupid that relying on tools to prevent them seems much more dangerous even. Log4j should not have been used by anyone, and certainly it should not have been extended and "improved" in an endless cascade of irresponsible additions, likely violating every principle of good practice, ever. I hope that this is what industry people take away from it, not…

If log4j is such a fundamentally bad idea, surely we should expect our tools to stop such ideas from ever being implemented.

In the same way that modern languages are memory-safe (disallowing pointer arithmetic, because it's proven to be a terrible idea), a real modern language would disallow log4j by being capability-safe.

Re: A capability-safe language would have minimized the Log4j vulnerability

#80

Post by catern »

adfhadfignio wrote: post #14

Java has actually had this built in for a long time now. A SecurityManager allows you to restrict access to things like the filesystem and the network (and whatever else you want). I have never seen it used in a real codebase. https://docs.oracle.com/javase/tutorial/essential/environmen...

Java's SecurityManager is very different from capability-safety. It's much more like setuid: SecurityManager allows or disallows network accesses depending on what code is running. (Literally by inspecting the stack)
Post reply on HN