Hacker News Reader

Comment by bullen | Hacker News Reader

  Calendar date = Calendar.getInstance();
  PrintStream ps = new PrintStream(new FileOutputStream(new File("log.txt")), true, "UTF-8");
  ps.write(new SimpleDateFormat("yy-MM-dd HH:mm:ss.SSS").format(date.getTime()) + " message that does not need LDAP".getBytes("UTF-8"));

3 lines that replace 1705KB of log4j-core-2.14.1.jar

"It does more than that..." I hear you mutter... yes it does more than that!

Please build something that you are responsible for.

From scratch and with minimalism as a guideline.

Using only an OS and a programming language.

View on HN

That's not how logging works in real world. It might be sufficient for a pet project running on a single machine, but not when you have hundreds of instances running in parallel, when you to send logs to a central system for parsing/analysis in near realtime, when you need an ability to configure logging levels and formats in flight etc. and do all that with minimal impact on the performance. I don't advocate JNDI-like functionality enabled by default (as any sane person), but there's a middleground somewhere in between.

Log shipping is usually based on tailing a file on disk in a separate process. Eg FileBeat, Fluentd, Promtail, logrotate.

Separation of concerns. Keeps infrastructure details out of your app and is more likely to at least leave a trace on disk in case the central logging goes south, when you need it the most.

On demand changing of log levels is still something worth keeping in application, depending on your verbosity volumes.

Fair enough, but that's more of how you package things - you can either have a separate class in Java inside your jar or you can have a standalone agent application (often also yet another Java application), but the attack surface doesn't change much. If log4j would be a standalone agent running on the same application server with this RCE vulnerability, the end result would be exactly the same.

Didn’t mean to split the log shipper for sake of security but since you brought it up :) RCE in the app allows reading secrets the application holds in memory, a lot more difficult from another process. And if you run the log scraper in a less privileged container you could restrict the blast radius to basically nothing except shipping fake logs to the central system.

But sure, take this reasoning too far and you end up with micro service spaghetti, so some balance is needed.

While in theory you can, I'm yet to see a proper defense in depth implementation despite having >10 years in the industry. In my book, if you get shell access to pod, it's game over, as these secrets in program's memory are probably also available as environmental variables, accessible in k8s Secrets etc., not to mention other ways to compromise an underlying node and the whole cluster.. But yes, this is already too far from the original topic.

Actually some well-known logging solutions work exactly like this. There's a local agent running, listens to file changes and forwards them. Next more complex solution would be syslog with TLS, even supports log routing and is packaged with practically every Linux distribution.

After all I think Java isn't that bad but all this legacy stuff needs to be dropped.

Please handle logging levels, control of logging levels by package, log file rotation and logging to stdout instead or in addition to a file. Also, log statements should contain the calling class and method. Please also make sure that your logging implementation can be used by any libraries that you reference, I'd like to have their logs in the same format as the application logs and be able to control their level as well.

Do you still want to build something from scratch and maintain it yourself? Or would you rather not waste weeks of your time reinventing something that already exists and that other developers are already familiar with?

> From scratch and with minimalism as a guideline.

I am not sure I ever saw a minimal Java program (but I am not a Java programmer, so maybe it is just my limited perspective).

Really, what's the point of a quip like this? That's like saying I never saw a Lisp program that didn't have a lot of brackets.

Minimal only makes sense within one language ecosystem. Java tends to be more verbose than some other languages, I guess that is common knowledge.

In a corporate setting he's probably right. Java came of age in the early 00s when a new generation of programmers were seeking a revolution, and there was a Cambrian explosion of interfaces, modularity, and pluggability, first with J2EE and with Spring being the second wave. The pendulum of change is always in swing, and with time some people grew tired (but many didn't) of enormous "enterprise" application frameworks and sought minimalism again in their systems (see also [1] in general and [2] for something in this vein relevant to the bug in question.)

"Don't hate the player, hate the game."

[1] http://iam.georgecox.com/wp-content/uploads/2021/12/wirth-a-...

[2] https://tinylog.org/v2/

Java is kind of 'heavy'. One project I was changing yesterday. Well over 150MB of jar files dragged in. There is maybe 50 lines of total code in the whole project. You put in the right depend in your pom file and it seems like it drags in half of the java world. Plus whatever jar files are flatpacked into those.

So with the fun bit of flatpack you have to look at all of your dependencies and see if they are somehow sneaking that bad boy in. Luckily most just use pom depends and just pull the jar in and you can override at the top level.

Pity the poor sod who (for this fix) has to update from java 7 to java 8 only to find that he's on a version of spring which doesn't run on java 8 and then has to update spring first.

When one needs to respond without delay to an vulnerability being exploited in the wild, being up-to-date with other dependencies means that you need only pay attention to the one with the security flaw. Pay in small instalments over time or pay in one large hit (at the least convenient time, obviously...), but there is no avoiding it.

In an age where random code is downloaded from the internet on trust and included in projects on a whim without inspection, it's noteworthy that people don't use the very same features to keep aggressively up to date. (The reason is that the long-term benefit of doing so is not immediately obvious to the most influential stakeholders of a project.) Sic transit gloria mundi.

"Alexa, define yak-shaving"

How is reminding of the fundamental problem of dependencies’ impact on security a yak-shaving?

Because in a company setting at least, you will soon discover that you need more than file-based logs in the specific format some coder defined for his pet project. So, you start logging to a database which is easy enough and then you start writing some simple templating code so that different logalizers can work on the logs etc. And then you discover that your logging is slowing down the whole application as more users are added and so on.

In the end, you implement a subset of log4j, just worse. What you should have looked at is one of the lighter logging libraries and use slf4fj to switch them out if you need more.

So? The fact that someone needs this functionality doesn't mean everyone needs it. What you are describing is literally just software bloat, and is the root of the problem with log4j - and many, perhaps most, other vulnerabilities.

And yes, slf4j would be a proper solution, if it were the default.

I mean, if we decided to build everything from scratch using only the OS and a programming language, we wouldn't be building any products. Recommending using a hilariously basic log (straight to file, no modules/level control, no buffer to avoid performance hits, no multithread support) instead of using a established library for logging is pretty naive. Yes, one should know that dependencies can introduce security problems, but the protection against that is not "remove all dependencies and build everything yourself".

java.util.logging is available since Java 1.4. You don't need even those 3 lines.

Reply on news.ycombinator.com