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

61–70 of 158 posts

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

#61

Post by DarkmSparks »

fiddlerwoaroof wrote: post #41
DarkmSparks wrote: post #21

Personally I wonder whether anyone actually used log4j willingly or just because its generally used by all the apache projects and they wont start without it. With a healthy dose of "use the latest versions" mentality. I checked back and all my java code was still running log4j 1.1, and removing it has been on the todo list ever since it needed linking. You should be checking all your 3rd party source code, "capabili…

I think you’re misunderstanding capabilities: they can apply also at the class/method/module level. If you’re language doesn’t have “ambient authority”, nothing can create a network connection unless it’s explicitly granted permission to do so and, typically, this permission is granted by passing some sort of non-forgeable token around.

Java used to have exactly this with security manager https://docs.oracle.com/javase/tutorial/essential/environmen...

Its been removed from the language because "it wasnt needed or used".

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

#62

Post by DarkmSparks »

lmilcin wrote: post #32
DarkmSparks wrote: post #21

Personally I wonder whether anyone actually used log4j willingly or just because its generally used by all the apache projects and they wont start without it. With a healthy dose of "use the latest versions" mentality. I checked back and all my java code was still running log4j 1.1, and removing it has been on the todo list ever since it needed linking. You should be checking all your 3rd party source code, "capabili…

> Personally I wonder whether anyone actually used log4j willingly Any project written in Java that has ANY dependencies will also use Log4j. Not even your choice anymore unless you are willing to write your entire stack from scratch. The moment you start thinking about how to solve logging you will land at a log4j-like framework anyway. > You should be checking all your 3rd party source code How is that a usable adv…

> How is that a usable advice?

Its not really advice, its an essential requirement if not getting pwnd is important to you. Expect to get pwnd eventually otherwise.

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

#63

Post by fiddlerwoaroof »

DarkmSparks wrote: post #61
fiddlerwoaroof wrote: post #41

Earlier quoted context omitted.

I think you’re misunderstanding capabilities: they can apply also at the class/method/module level. If you’re language doesn’t have “ambient authority”, nothing can create a network connection unless it’s explicitly granted permission to do so and, typically, this permission is granted by passing some sort of non-forgeable token around.

Java used to have exactly this with security manager https://docs.oracle.com/javase/tutorial/essential/environmen... Its been removed from the language because "it wasnt needed or used".

This is more like ACLs, which are a completely different paradigm from capability-based security. An ACL system is based around specifying permissions for actions and such, whereas capability systems are based around reifying authority in an unforgeable way and passing the resulting tokens around.

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

#64

Post by Ericson2314 »

monocasa wrote: post #59
Ericson2314 wrote: post #56

Earlier quoted context omitted.

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!

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

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.

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

#65

Post by Ericson2314 »

cesarb wrote: post #58
Ericson2314 wrote: post #56

Earlier quoted context omitted.

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!

> 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...

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.)

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

#66

Post by monocasa »

Ericson2314 wrote: post #64
monocasa wrote: post #59

Earlier quoted context omitted.

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

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 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.

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

#67

Post by loeg »

Ericson2314 wrote: post #50
pjmlp wrote: post #45

Earlier quoted context omitted.

> As of October 2020, CloudABI has been deprecated in favor of WebAssembly System Interface for lack of interest On its Wikipedia entry, so most likely it won't go anywhere.

I know, but support is still in FreeBSD. My big long term plan is: 1. Work on FreeBSD cross in Nixpkgs, because I need a way to pin forks and run nice VM tests without going insane. (We already have NetBSD cross.) 2. Rig up a booting image that uses https://github.com/InitWare/InitWare , the fork of systemd. 3. Add support to CloudABI in initware. 4. Bang on drum for other OSes and upstream systemd to implement this…

I believe FreeBSD has removed support in CURRENT.

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

#68

Post by jerf »

monocasa wrote: post #25
armchairhacker wrote: post #11

Earlier quoted context omitted.

It still passes. Because JNDI would require network access, so log4j would also have to require network access or "disable" the network capability.

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 day.

On the one hand, I acknowledge the general impracticality of such an approach, but on the other I'm increasingly less convinced every year that anything less will ever be secure. And I also accept the corresponding implication that if programmers never do come to accept this sort of thing, we will never have secure code.

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

#69

Post by teitoklien »

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.1 ?

“Tough luck, security patches only exists in 3.1 and above, guess you’ll have to stay unsafe”

Not to mention the pain it would bring on languages to backport safety features to older LTS releases of the compiler.

Just why?, let the os handle these things for you. It is called an operating system for a reason.

Log4j vulnerability was minimised in any organisation that restricts its applications network capability to whitelisted machines only, with the help of its OS features.

(Yes your application might need network access, so run it through a reverse proxy and filter the traffic based on strict set of rules)

Post reply on HN