4 ms·

Calendar date = Calendar.getInstance(); PrintStream ps = new PrintStream(new FileOutputStream(new File("log.txt")), true, "UTF-8"); ps.write(new SimpleDateF

by bullen 5y ago

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.

madmax108 5y ago
"Alexa, define yak-shaving"
- trasz 5y ago
  How is reminding of the fundamental problem of dependencies’ impact on security a yak-shaving?
  - gjulianm 5y ago
    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".
  - iSnow 5y ago
    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.
    - trasz 5y ago
      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.
atoav 5y ago
> 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).
- iSnow 5y ago
  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.
  - gjvc 5y ago
    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-plea-for-lean-software.pdf http://iam.georgecox.com/wp-content/uploads/2021/12/wirth-a-... [2] https://tinylog.org/v2/ https://tinylog.org/v2/
    - sumtechguy 5y ago
      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.
kbart 5y ago
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.
- Too 5y ago
  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.
  - kbart 5y ago
    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.
    - Too 5y ago
      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.
vbezhenar 5y ago
java.util.logging is available since Java 1.4. You don't need even those 3 lines.
ahtihn 5y ago
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?

by bullen 5y ago

madmax108 5y ago

"Alexa, define yak-shaving"

trasz 5y ago
How is reminding of the fundamental problem of dependencies’ impact on security a yak-shaving?
- gjulianm 5y ago
  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".
- iSnow 5y ago
  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.
  - trasz 5y ago
    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.

atoav 5y ago

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

iSnow 5y ago
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.
- gjvc 5y ago
  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-plea-for-lean-software.pdf http://iam.georgecox.com/wp-content/uploads/2021/12/wirth-a-... [2] https://tinylog.org/v2/ https://tinylog.org/v2/
  - sumtechguy 5y ago
    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.

kbart 5y ago

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.

Too 5y ago
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.
- kbart 5y ago
  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.
  - Too 5y ago
    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.

vbezhenar 5y ago

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

ahtihn 5y ago

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?