Hacker News Reader

Comment by DarkmSparks | Hacker News Reader

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.

View on HN

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.

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

The former is explicit, and an IDE can help with highlighting unused ones. The latter is difficult to audit because the code that uses relevant APIs is disconnected from the privilege-enforcing mechanism. It's either some sort of abstract policy framework or explicit privilege dropping

I don't remotely see how an ide could help highlight which functions are insecure to call reflectively, other than linting, and that applies to both and only helps so much.

You should probably spend ten minutes reading an introduction to capabilities then so you can understand the basic concepts before commenting. I don't know what to recommend nowadays, but mlinksva posted a link to one.

I wasnt the one saying security manager was the same as an acl.

Nothing you posted explains why a reference to the security manager class isn't a token.

It seems to me more that you dont understand either capabilities or the old security manager class.

> It seems to me more that you dont understand either capabilities or

Mark Miller cited me ("K. Sitaker") in Capability Myths Demolished and Paradigm Regained:

https://www-users.cselabs.umn.edu/classes/Fall-2019/csci5271...

https://www.hpl.hp.com/techreports/2003/HPL-2003-222.pdf?jum...

Tyler Close cited me in ACLs Don't:

https://www.hpl.hp.com/techreports/2009/HPL-2009-20.pdf?q=do....

It sounds like you disagree with their judgment on this point.

acls are only a tiny part of security manager did. It was a full fledged class based security system.

Yes, I do disagree that something like pfsense "is only an acl"

Or that capabilities can function without lists.

You dont?

I'm not going to argue with you. You haven't earned it. Go and study.

You didnt argue. You just posted a load of completely irrelevant links that have absolutely nothing to do with the java security manager class or why it was depreciated in Java 17.

I believe there is a name for that - strawman.

the jep is here https://openjdk.java.net/jeps/411

Not checked but Im fairly certain none of your links are referenced there.

> 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 advice? There are dozens of dependencies in a simplest application. A non-trivial may easily have above hundred dependencies.

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.

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

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.

Log4j 1.x contains vulnerabilities and errors that were never addressed because it was declared end-of-life in 2015 and the Apache project has stopped supporting it!

https://logging.apache.org/log4j/1.2/index.html

https://www.cvedetails.com/cve/CVE-2019-17571/

> the number of applications that dont need network access these days is as good as zero

You can still have all outgoing traffic be sent through a proxy that denies any target that is not explicitly on the allowlist.

Reply on news.ycombinator.com