3 ms·

Are you saying that log4j is also used for analyzing logs that have already been generated ? My understanding was that it was intended for use inside an applic

Are you saying that log4j is also used for analyzing logs that have already been generated ? My understanding was that it was intended for use inside an application for generating log messages and processing them before they are sent out to a file or syslog.

oasisbob 5y ago
I had the same thought. However, I think it's a more generic attack. If you can persist or inject the jdni strings, there's a chance they will be emitted by another component which analyzes the logs and has a log4j dependency elsewhere in the stack. I've heard people talk about this problem with analyzing windows event logs using Java-based software.
- tgflynn 5y ago
  That's interesting. It seems a bit weird that a log analyzer would need to do additional logging, but maybe that's the case in larger systems. I wonder if using log4j as a tool for log analysis as opposed to generation might be a shadow use case of the library. You could have an app that parses log files, converts them to Event objects and then processes that event stream through log4j. I have no idea whether that would be terribly useful and is actually being done by anyone but I guess that's one scenario where these CVE's could cause delayed effects.
retzkek 5y ago
Logstash is a hugely popular application for collecting/processing/shipping logs, mainly associated with elasticsearch ("ELK") but has lots of output plugins. It uses log4j, so if one of the log events it was processing contained an exploit string, and also caused logstash to encounter an error processing or shipping the message*, that message would get logged to logstash's own log, thus triggering the exploit deep in someone's infrastructure. * probably not too hard to come up with a way to break one of the many "grok" pattern regexes https://github.com/logstash-plugins/logstash-patterns-core/blob/main/patterns/legacy/httpd https://github.com/logstash-plugins/logstash-patterns-core/b...
regularfry 5y ago
In addition to sibling comments, there's also a SocketServer component in the library you can instantiate and fire log messages at if you want to. Which, if you're still on 1.2.x, also has an RCE against it.

oasisbob 5y ago

I had the same thought. However, I think it's a more generic attack. If you can persist or inject the jdni strings, there's a chance they will be emitted by another component which analyzes the logs and has a log4j dependency elsewhere in the stack. I've heard people talk about this problem with analyzing windows event logs using Java-based software.

tgflynn 5y ago
That's interesting. It seems a bit weird that a log analyzer would need to do additional logging, but maybe that's the case in larger systems. I wonder if using log4j as a tool for log analysis as opposed to generation might be a shadow use case of the library. You could have an app that parses log files, converts them to Event objects and then processes that event stream through log4j. I have no idea whether that would be terribly useful and is actually being done by anyone but I guess that's one scenario where these CVE's could cause delayed effects.

retzkek 5y ago

Logstash is a hugely popular application for collecting/processing/shipping logs, mainly associated with elasticsearch ("ELK") but has lots of output plugins. It uses log4j, so if one of the log events it was processing contained an exploit string, and also caused logstash to encounter an error processing or shipping the message*, that message would get logged to logstash's own log, thus triggering the exploit deep in someone's infrastructure. * probably not too hard to come up with a way to break one of the many "grok" pattern regexes https://github.com/logstash-plugins/logstash-patterns-core/blob/main/patterns/legacy/httpd https://github.com/logstash-plugins/logstash-patterns-core/b...

regularfry 5y ago

In addition to sibling comments, there's also a SocketServer component in the library you can instantiate and fire log messages at if you want to. Which, if you're still on 1.2.x, also has an RCE against it.