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

51–60 of 158 posts

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

#51

Post by carey »

fiddlerwoaroof wrote: post #37
lmilcin wrote: post #32

Earlier quoted context omitted.

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

I’ve always used the various log4j adapters and then excluded log4j from the transitive dependencies.

Same. Gradle even lets you configure replacement dependencies, so if anything depends on Log4J it automatically gets the adapter instead.

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

#52

Post by creatonez »

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.

Depends how capabilities work in the system. A restriction could prevent something from occurring at all in a bit of code, even in outside calls.

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

#54

Post by Ericson2314 »

pjmlp wrote: post #45
Ericson2314 wrote: post #40

Capabilities are underrated as a generally way to purge bad archictures, make it clearer what code is doing, and generally cut accidental complexity & improve programmer productivity. This is a big deal, because many security practices are neutral or bad for programmer productivity. We need a big project to get CloudABI implemented in all the major kernels to make the theory reality. Whereas before it was unclear wha…

> 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 also rewoke this LKML thread https://lore.kernel.org/kernel-hardening/01e72780-e328-23b5-... a few months back, because my one quibble with CloudABI is its all-singing-all-dancing fork+exec abi.

Making an embryonic process, mutating it's state as desired, and then submitting to the scheduler is a much nicer workflow, and more in the spirit of capabilities anyways where "fork = duplicate the whole keyring and then destroy some caps" as foolhardy.

FreeBSD already had process/PID FDs, but I think CloudABI avoided them because it wanted to be easier to port. But now that Linux has them too, I don't think this should be a such a portability concern.

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

#55

Post by jiggawatts »

the_arun wrote: post #10

Ideally all egress network connections should go via NAT Gateway & filters at NAT Gateway should have policies to say which request can go out. Failures do happen in programming, we need to have better guardrails ensuring security.

In the field this causes more issues that in solves.

For example, overzealous secops admins block "port 80 outbound", because everyone knows that HTTP is "insecure" and HTTPS is "secure". Except that the SSL certificate on that HTTPS website needs OCSP on port 80 to be fully secured. If you block it, you get random 30 second timeouts and less security.

In general, totally blocking the Internet and then punching holes is like playing whack-a-mole. At first, you'll block Windows Update because you should be "managing that" through something like WSUS or SCCM, right, right? No, the SCCM guys never did figure out how to manage the DMZ servers, so the most Internet exposed servers are not getting patched now. Congratulations!

So you'll open up Windows Update. Except that you didn't, because you forgot that it also includes half a dozen vaguely related, infrequently used and undocumented additional URLs. Which are all CDNs. So they're a CNAME to a CNAME to a pool of A records approximately half the size of all of Azure.

And there's the Linux machines. The BSD-based network appliances and their various call-home support features. And on, and on, and on.

How exactly are you going to configure this in your "NAT"? You discover that you can't. You're going to have to use a HTTP web proxy.

Congratulations, you've now blocked IPv6, HTTP/3, nerfed web performance for everyone everywhere, and introduced a terrifying single-point-of-failure that will even break basic authentication (Azure AD, Okta, SAML, etc...).

You can lock out an entire network completely by accidentally powering off the web proxies, to the point that noone can log back on to turn them on.

This is just the tip of the iceberg. I could rant for hours about how NAT and forced outbound proxies break more things than they solve. Famously, TLS v1.3 uses v1.2 in the protocol header because the morons that write web proxies don't understand how protocol versions work.

Oh, okay, one more: Windows 11 and 2022 introduced new TCP optimisations (HyStart++) that improve performance on high bandwidth delay product links like modern cloud and 5G networks. Except that web proxies don't generally keep up with optimisations like this, so you gain nothing even if you upgrade the desktops and server to modern operating systems. (Same thing applies to Linux too)

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

#56

Post by Ericson2314 »

monocasa wrote: post #44
ryukafalz wrote: post #35

Earlier quoted context omitted.

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

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

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!

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

#57

Post by cesarb »

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

We actually use it in a real codebase. When the software is running on "developer mode" (on a developer's machine), we install a SecurityManager which denies all outbound connections except for localhost by default.

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

#58

Post by cesarb »

Ericson2314 wrote: post #56
monocasa wrote: post #44

Earlier quoted context omitted.

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

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

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

#59

Post by monocasa »

Ericson2314 wrote: post #56
monocasa wrote: post #44

Earlier quoted context omitted.

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

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

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

#60

Post by nibix »

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

Elasticsearch is actually using SecurityManager with quite thoroughly locked down policies; and it seems that this actually saved ES from being vulnerable to the RCE.

The irony is now that OpenJDK just recently decided to deprecate the SecurityManager in Java 17 and remove it in Java 18.

See also this Twitter thread: https://twitter.com/rcmuir/status/1469730949810339843

Post reply on HN