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

111–120 of 158 posts

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

#111

Post by kragen »

alasdair_ wrote: post #108

No, it wouldn’t have, for the simple reason that no one is willing to go to the extra effort to use a capability-safe language, for the same reason we don’t all code in formally-verified languages - it’s just too much work. The claim in the article could be “The log4j vulnerability could have been prevented by hiring someone to punch any developer who tries to use JNDI in a logging library in the face” and would be e…

It sounds like you haven't tried it, so you're just guessing that it would be hard without any knowledge, because you're used to writing code in such a way that security is inconvenient.

Writing code in E is nothing like writing formally verified code. It's a lot less work than writing code in Java or C++.

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

#112

Post by MattPalmer1086 »

avar wrote: post #46
MattPalmer1086 wrote: post #30

Earlier quoted context omitted.

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?

The usual ways to do that are to open a connection to the things you need at startup, and then drop your privileges, set ulimits or whatever. Or you don't have network access at all, but pipe your logs to a local process that does. Alternatively the application can be made to have some OS-specific rules to e.g. generate iptables rules on Linux, so it can contacts its logger, but not anything else. All of those are pr…

I don't think Java apps can drop privileges like that, but yes, that would prevent unexpected bits of code from acquiring a network connection. I suspect only the most secure code bases would bother though, and most things would still be affected even if it were possible in Java.

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

#113

Post by PedroBatista »

kragen wrote: post #111
alasdair_ wrote: post #108

No, it wouldn’t have, for the simple reason that no one is willing to go to the extra effort to use a capability-safe language, for the same reason we don’t all code in formally-verified languages - it’s just too much work. The claim in the article could be “The log4j vulnerability could have been prevented by hiring someone to punch any developer who tries to use JNDI in a logging library in the face” and would be e…

It sounds like you haven't tried it, so you're just guessing that it would be hard without any knowledge, because you're used to writing code in such a way that security is inconvenient. Writing code in E is nothing like writing formally verified code. It's a lot less work than writing code in Java or C++.

Is it?

I’m referring to real world coding to solve real world problems in order to get real world paychecks.

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

#114

Post by clusterfish »

alasdair_ wrote: post #108

No, it wouldn’t have, for the simple reason that no one is willing to go to the extra effort to use a capability-safe language, for the same reason we don’t all code in formally-verified languages - it’s just too much work. The claim in the article could be “The log4j vulnerability could have been prevented by hiring someone to punch any developer who tries to use JNDI in a logging library in the face” and would be e…

I don't think a well designed capability system would be so onerous as to be unworkable, people use other complex features in Rust and C++ and Haskell just fine. It's just that being capability-safe by itself is not enough to carry a niche language. Eventually these ideas will find their way into more mainstream languages, one way or another.

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

#115

Post by kragen »

PedroBatista wrote: post #113
kragen wrote: post #111

Earlier quoted context omitted.

It sounds like you haven't tried it, so you're just guessing that it would be hard without any knowledge, because you're used to writing code in such a way that security is inconvenient. Writing code in E is nothing like writing formally verified code. It's a lot less work than writing code in Java or C++.

Is it? I’m referring to real world coding to solve real world problems in order to get real world paychecks.

You're going to have a hard time getting a job writing E, or for that matter finding E libraries, because nobody uses E. Same story with Lobster, Clean, RScheme, Cobra, or a zillion other languages that don't have much adoption. But that is an entirely separate question from it being a cumbersome programming language, which is what the grandparent comment was alleging of all ocap languages—based on, apparently, total ignorance.

There's nothing wrong with total ignorance; it's where we all start. But there is a great deal wrong with pretending that your total ignorance is expertise that justifies dismissing what you're ignorant of. Believe me, I have a lot of experience being that guy. It sucks.

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

#116

Post by MattPalmer1086 »

mikewarot wrote: post #83

So close to getting to the actual root issue (ambient authority), but so far away (blaming the programmer, instead of structural deficits in the OS). We need operating systems that don't hand out authority like candy if we're ever going to have the usability and freedom that we used to have in the 1980s with floppy based IBM PCs running MS-DOS. I'm constantly dismayed at the ongoing failure of imagination that accept…

I agree that ambient authority is the root issue here, but not necessarily at the OS level.

Since logging is just another bit of code intertwined with your other code, it's not clear to me that OS capabilities would help here.

Let's say you have an app that needs JNDI and also needs logging, So JNDI is given a network capability, then log4j calls it. Now we just have a confused deputy within your code.

Ah - but log4j shouldn't be able to get JNDI without being given it! Or the Network object. Or whatever is the thing you need to get a job done. This is the argument by reachability of capability security.

Now you need to ensure that your internal code is structured along those lines, which is really what the OP is getting at.

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

#117

Post by Zababa »

continuational wrote: post #107

I am working on a capability-safe language! I fully agree with this article, and the great thing about object capabilities is that they are just plain values, and require nothing special from the type system. This also means that object capabilities aren't "colored" like async/await, monads, or other effect systems.

Do you have more to share, like resources about capability-safe languages, or your ongoing work?

> This also means that object capabilities aren't "colored" like async/await, monads, or other effect systems.

That's interesting. How does that work? Is it by passing around a value from your main function to the functions that need it?

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

#118

Post by mikewarot »

catern wrote: post #87
mikewarot wrote: post #83

So close to getting to the actual root issue (ambient authority), but so far away (blaming the programmer, instead of structural deficits in the OS). We need operating systems that don't hand out authority like candy if we're ever going to have the usability and freedom that we used to have in the 1980s with floppy based IBM PCs running MS-DOS. I'm constantly dismayed at the ongoing failure of imagination that accept…

Operating systems are also written by programmers. An operating system written in a capability-safe language would not have such ambient authority problems.

Please let me re-state my objection to your assertion, in a different, and hopefully more constructive, manner.

An Operating System is a program that multiplexes hardware resources and makes them safely usable by a number of applications. If the design of that system is flawed, how could a capability-safe language do anything to correct the problem?

It is my assertion that the design of Linux, Windows, MacOS are all flawed. They provide, by default, any program the computer equivalent of "power of attorney". All you have to do is confuse, or subvert any program the user runs one time to abuse that privilege on behalf of an outside influence, and the system is on the way to being pwned.

Memory safe, and even capability safe languages won't do any good, if the underlying OS doesn't enforce the will of the user, but instead freely gives the users authority to any program they happen to run, intentional or otherwise.

I'm not saying memory or capability safety isn't useful, I'm just saying it isn't sufficient.

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

#119

Post by DarkmSparks »

fiddlerwoaroof wrote: post #63
DarkmSparks wrote: post #61

Earlier quoted context omitted.

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.

I don't see the difference between passing tokens around and inheriting a security manager that can only have permissions and capabilities revoked?

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

#120

Post by thrower123 »

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…

Same, all of our Java projects were using 1.X log4j, and have been for years and years without issue. Ironically, all of this scrutiny on the problems of the 2.X releases has forced us to agree to update from those rather dumb, safer builds to the latest releases, so that we'll have to be on the treadmill.
Post reply on HN