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

21–30 of 158 posts

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

#21

Post by DarkmSparks »

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, "capabilities" wont get round that, the number of applications that dont need network access these days is as good as zero.

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

#22

Post by gnufx »

to11mtm wrote: post #16

So, IDK what the Java world had that was similar, but in .NET at one time they tried to solve this at the runtime VM level with the concept of Security Permissions and trust levels. In practice, this wound up being: - Somewhere between too confusing/frustrating to developers (especially ASP.NET ones, where often the escape hatch of 'AllowPartiallyTrustedCallersAttribute' would get thrown around) - Hard to manage from…

http://joeduffyblog.com/2015/11/03/blogging-about-midori/ sounds relevant as what sounds like a contrast in that space.

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

#23

Post by xxpor »

to11mtm wrote: post #16

So, IDK what the Java world had that was similar, but in .NET at one time they tried to solve this at the runtime VM level with the concept of Security Permissions and trust levels. In practice, this wound up being: - Somewhere between too confusing/frustrating to developers (especially ASP.NET ones, where often the escape hatch of 'AllowPartiallyTrustedCallersAttribute' would get thrown around) - Hard to manage from…

There's what I think is a similar concept in Java called security contexts. I've never encountered it actually being used, and it just tends to get in the way, like you said. These strike me as similar to SELinux in that regard.

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

#24

Post by Smaug123 »

vsareto wrote: post #6

Why should a programming language be limiting network access? Why wouldn't we do this via the operating system?

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", or "does this code have any side effects", or "does this code throw", or "does this code allocate".)

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

#25

Post by monocasa »

armchairhacker wrote: post #11
monocasa wrote: post #7

Except the vulnerability was a stack up. The logger wasn't making network calls per se, but passing requests to a component (JNDI) that would obviously need network access. You'd have the same root issue, it'd just manifest more as sort of a confused deputy with a capability based model.

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.

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

#26

Post by xxpor »

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.

NAT != firewalling. People conflating the two leads to policies like needing NAT for ipv6.

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

#27

Post by MattPalmer1086 »

vladvasiliu wrote: post #15
MattPalmer1086 wrote: post #8

Earlier quoted context omitted.

Sounds better in general, but probably wouldn't help with something like logging which would probably be used in all the processes. Unless you want to make IPC calls for every logging call.

> Unless you want to make IPC calls for every logging call Isn't this more or less what ends up happening anyway? Sure, from the application's perspective it's just a function call. But usually, in the end, the logs are shipped to some central location one way or another.

Hmmm, good point!

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

#28

Post by [deleted] »

monocasa wrote: post #7

Except the vulnerability was a stack up. The logger wasn't making network calls per se, but passing requests to a component (JNDI) that would obviously need network access. You'd have the same root issue, it'd just manifest more as sort of a confused deputy with a capability based model.

[deleted]

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

#29

Post by jrockway »

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.

What sort of software are you using for the NAT gateways? (I know that's an AWS term, but not what I'm looking for. I've used that to provide a consistent outbound IP for production traffic so that upstream providers can allowlist an IP to talk to their API. Dumb security model when TLS client certificates exist, but... easy to set up I guess.)

I've always wanted to defend against the attack where an application routinely talks to some API hosted on AWS, but an attacker starts using the application to exfiltrate data to another API hosted on AWS. If you just look at outgoing IP addresses, you'll think something like "oh, that API just started another replica" and not "my app is doing something weird". I want to do MITM on my applications so that every outgoing payload can be inspected.

(I come at this from a security angle, but I'm really more interested in debugging in production. "Page foo that talks to the bar API has stopped working" "Oh, here's the JSON it started returning instead of text/plain." Bug fixed in 5 minutes.)

I know this sort of pattern is common for, say, corporate firewalls, but I haven't seen any good projects for doing it to arbitrary applications running in production. I looked at Apache Traffic Server which might be the right thing, but seems super old and doesn't support any integrations I'd want (OpenTracing, Prometheus). I also tried configuring Envoy to do what I want, but it also didn't work. (Things like Istio's Egress Gateways seem to not intercept TLS, so you just get a list of IP addresses requested, not URLs.)

I was thinking of just writing something to do this, but I know that everyone on Earth wants the same thing, so I figure I'm just missing the obvious out of the box solution. I'm 100% OK with fail closed (applications must be configured to only egress through a known-trusted IP of the proxy, all other network connections fail), reconfiguring my applications (happy to use some library for this, or inject TLS certificates for authenting the MITM proxy to the application), and this only working with HTTP. Suggestions?

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

#30

Post by MattPalmer1086 »

vsareto wrote: post #6

Why should a programming language be limiting network access? Why wouldn't we do this via the operating system?

That would be difficult to do within an application. If your app needs network access, but logging performed by the app should not, how could the OS help there?
Post reply on HN