6 ms·

Securing the Fundamentals: Our Support for Log4j

schalkneethling 3y ago
This was interesting to see after having read the following earlier in the week. https://www.theregister.com/2023/12/11/log4j_vulnerabilities/ https://www.theregister.com/2023/12/11/log4j_vulnerabilities...
snagglemouth 3y ago
Cool! As someone who has extensively used Log4j, it's nice to see STF investing in the technology. Log4j has been a bedrock in the Java-based software world for a long time now. The security vulnerabilities that sent everyone scrambling back December 2021 highlighted the need for more sustained efforts to enhance its security and functionality.
kazinator 3y ago
[flagged]
- zappb 3y ago
  Java keeps pumping out new releases, and slimming and modularizing codebases is itself development.
- 8organicbits 3y ago
  I would have assumed someone would build an alternative in the style of openssl alternatives. Log4j does some very complex things and has huge attack surface area. Does the 400k lines of code reflect actual, inherent complexity?
  - dwaite 3y ago
    Sort of. At its core is a logging interface, but there is a factory that gives you a configured local instance based on requesting a logger by name or by hierarchal class name. You have log levels but also markers which act as hierarchal filters. Based on the supplied configuration, something like debug-level log statements may become a no-op for a section of code. The appenders are an extension point and rather diverse - you can go to a file, a REST server, a database, etc. Writing a log message to a database or REST server may take a while, so there is a system to dispatch logging events to separate worker threads. Logging messages may be localized. This means there needs to be a parameterization system to inject data values into localized messages. You also may want to collect data from various parts of the system as available and log them, basically accumulating information as you go. There are thread contexts maps and stacks to accumulate such data, which can also be parameterized into messages. It's a highly flexible system without clear security boundaries. Maybe a log message comes from user input rather than being a parameter on a formatted log message. Maybe that user-supplied message contains a parameter itself. And maybe the parameters are written such that they are fulfilled by making system calls.
    - lifthrasiir 3y ago
      400K LoC is still far too huge for that kind of flexibility. Most of lines are probably attributed to the "batteries" included in Log4j. For example `log4j-core` contains too many plugins by default, including the notorious `JndiLookup`. It may have a modular interface, but its packaging is much less modular than it should be.
      - zappb 3y ago
        They’ve stated several times that version 3.x (in development) largely modularizes the system. In fact, the JNDI functionality has already been split out into its own repository for other JakartaEE/JavaEE integrations.
        deleted 3y ago
        [deleted]
    - kazinator 3y ago
      > but there is a factory If that's not a factory which makes factories which makes factories that make logging objects, we've got work to do!
- deleted 3y ago
  [deleted]
RedShift1 3y ago
Is there any reason to not use java.util.logging? I'm considering dumping slf4j and log4j over it.
- achoice 3y ago
  Mapped Diagnostic Context (MDC) is not available in plain java logging?
- derriz 3y ago
  I’ve done this before, don’t remember regretting it and always wonder why more don’t do it. I’ve even avoided any logging configuration files by configuring programmatically during application startup. I like minimal application configuration and find the “configuration surface” offered by most logging libraries much too large and also see it as a burden for users to learn/google the configuration file format of the chosen implementation. I prefer to offer minimal and ergonomic logging configuration options. Analogous to basic “-q”, “-v”, “-d” options typical of command line programs, which my code translates to whatever logging framework. And you don’t end up spending ages fiddling with slf4f and other exclusions and version range stuff in maven.
  - AtlasBarfed 3y ago
    The most annoying part of logging frameworks is figuring out their logging format file. A very very very close second is figuring out where to put the fucking config file so the app will pick it up in preference to whatever defaults or packaged settings are. There's an article on the feed today about events that was hitchikers something and then threw about 10 more layers of sarcasm and meme on the subject, and one of the frustrations I have with current logging frameworks is that a truly mature logging framework needs a LOT of interesting things: - how about a per-user log? - how about a per-core or per-node log? - how about a per-request log? - event extraction and publishing And of course the issue of cross-system-boundary tracking/tracing. Sure, log aggregation and mining can help, but it seems like a very very big expensive hammer for an intricate peg and hole. Anyway, Log4j was written from the age of computer science where computers were single machine monoliths with a database (two-tier or three-tier: that's right systems architect in two or three boxes rather than https://www.youtube.com/watch?v=y8OnoxKotPQ https://www.youtube.com/watch?v=y8OnoxKotPQ
elric 3y ago
My gut reaction was "what a waste of money, just move on to literally any other logging framework". Then I remembered that reality is still a thing, and that there are thousands of companies running oodles of unmaintained applications. Applications to which they probably don't have the source code, and if they do, are unable to build new versions because of bit rot. And that, maybe, these people can get away with replacing the Log4J JAR file in their installation. Maybe. The state of software security seems truly abysmal. Which is no surprise, given that many companies outsource development, receive a working product, and then the development team moves on and no one ever seems to bother with security maintenance.
neals 3y ago
Totally different question : what are people using for logging nodeJS or Deno these days?
deleted 3y ago
[deleted]

This was interesting to see after having read the following earlier in the week. https://www.theregister.com/2023/12/11/log4j_vulnerabilities/ https://www.theregister.com/2023/12/11/log4j_vulnerabilities...

snagglemouth 3y ago

Cool! As someone who has extensively used Log4j, it's nice to see STF investing in the technology. Log4j has been a bedrock in the Java-based software world for a long time now. The security vulnerabilities that sent everyone scrambling back December 2021 highlighted the need for more sustained efforts to enhance its security and functionality.

kazinator 3y ago

[flagged]

zappb 3y ago
Java keeps pumping out new releases, and slimming and modularizing codebases is itself development.
8organicbits 3y ago
I would have assumed someone would build an alternative in the style of openssl alternatives. Log4j does some very complex things and has huge attack surface area. Does the 400k lines of code reflect actual, inherent complexity?
- dwaite 3y ago
  Sort of. At its core is a logging interface, but there is a factory that gives you a configured local instance based on requesting a logger by name or by hierarchal class name. You have log levels but also markers which act as hierarchal filters. Based on the supplied configuration, something like debug-level log statements may become a no-op for a section of code. The appenders are an extension point and rather diverse - you can go to a file, a REST server, a database, etc. Writing a log message to a database or REST server may take a while, so there is a system to dispatch logging events to separate worker threads. Logging messages may be localized. This means there needs to be a parameterization system to inject data values into localized messages. You also may want to collect data from various parts of the system as available and log them, basically accumulating information as you go. There are thread contexts maps and stacks to accumulate such data, which can also be parameterized into messages. It's a highly flexible system without clear security boundaries. Maybe a log message comes from user input rather than being a parameter on a formatted log message. Maybe that user-supplied message contains a parameter itself. And maybe the parameters are written such that they are fulfilled by making system calls.
  - lifthrasiir 3y ago
    400K LoC is still far too huge for that kind of flexibility. Most of lines are probably attributed to the "batteries" included in Log4j. For example `log4j-core` contains too many plugins by default, including the notorious `JndiLookup`. It may have a modular interface, but its packaging is much less modular than it should be.
    - zappb 3y ago
      They’ve stated several times that version 3.x (in development) largely modularizes the system. In fact, the JNDI functionality has already been split out into its own repository for other JakartaEE/JavaEE integrations.
      - deleted 3y ago
        [deleted]
  - kazinator 3y ago
    > but there is a factory If that's not a factory which makes factories which makes factories that make logging objects, we've got work to do!
deleted 3y ago
[deleted]

RedShift1 3y ago

Is there any reason to not use java.util.logging? I'm considering dumping slf4j and log4j over it.

achoice 3y ago
Mapped Diagnostic Context (MDC) is not available in plain java logging?
derriz 3y ago
I’ve done this before, don’t remember regretting it and always wonder why more don’t do it. I’ve even avoided any logging configuration files by configuring programmatically during application startup. I like minimal application configuration and find the “configuration surface” offered by most logging libraries much too large and also see it as a burden for users to learn/google the configuration file format of the chosen implementation. I prefer to offer minimal and ergonomic logging configuration options. Analogous to basic “-q”, “-v”, “-d” options typical of command line programs, which my code translates to whatever logging framework. And you don’t end up spending ages fiddling with slf4f and other exclusions and version range stuff in maven.
- AtlasBarfed 3y ago
  The most annoying part of logging frameworks is figuring out their logging format file. A very very very close second is figuring out where to put the fucking config file so the app will pick it up in preference to whatever defaults or packaged settings are. There's an article on the feed today about events that was hitchikers something and then threw about 10 more layers of sarcasm and meme on the subject, and one of the frustrations I have with current logging frameworks is that a truly mature logging framework needs a LOT of interesting things: - how about a per-user log? - how about a per-core or per-node log? - how about a per-request log? - event extraction and publishing And of course the issue of cross-system-boundary tracking/tracing. Sure, log aggregation and mining can help, but it seems like a very very big expensive hammer for an intricate peg and hole. Anyway, Log4j was written from the age of computer science where computers were single machine monoliths with a database (two-tier or three-tier: that's right systems architect in two or three boxes rather than https://www.youtube.com/watch?v=y8OnoxKotPQ https://www.youtube.com/watch?v=y8OnoxKotPQ

elric 3y ago

My gut reaction was "what a waste of money, just move on to literally any other logging framework". Then I remembered that reality is still a thing, and that there are thousands of companies running oodles of unmaintained applications. Applications to which they probably don't have the source code, and if they do, are unable to build new versions because of bit rot. And that, maybe, these people can get away with replacing the Log4J JAR file in their installation. Maybe. The state of software security seems truly abysmal. Which is no surprise, given that many companies outsource development, receive a working product, and then the development team moves on and no one ever seems to bother with security maintenance.

neals 3y ago

Totally different question : what are people using for logging nodeJS or Deno these days?

deleted 3y ago

[deleted]