4 ms·

No, this is about log4j2 which is kinda new (2.0.0 was released 2014). Otherwise, yeah, this is terrible, especially since the tag doesn't even have to be in th

No, this is about log4j2 which is kinda new (2.0.0 was released 2014). Otherwise, yeah, this is terrible, especially since the tag doesn't even have to be in the formatting string.

maxdamantus 5y ago
The sample in the in post is log4j1 ("org.apache.log4j" rather than "org.apache.logging.log4j"), which is why it's using: > log.info("foo: " + bar); rather than: > log.info("foo: {}", bar); But the issue also affects log4j2, and it doesn't matter which form of logging you use, since the transformation apparently happens further along in some appender, used by both versions of log4j.
- Zardoz84 5y ago
  The post examples its : log.info("Request User Agent:{}", userAgent); Also, I just try with log4j1 , and I can't reproduce it. At least with the netcat trick doesn't work : https://twitter.com/thetaph1/status/1469264526214406150?s=20 https://twitter.com/thetaph1/status/1469264526214406150?s=20
  - maxdamantus 5y ago
    The post has been partially updated to log4j2 [0] (the import is still log4j1, but I imagine this will be updated soon [1]). And yes, I'm actually not sure log4j1 is vulnerable. I assumed it was because the sample code in the post was using log4j1, though the description only explicitly mentions log4j2. [0]: https://github.com/lunasec-io/lunasec/pull/270 https://github.com/lunasec-io/lunasec/pull/270 [1]: https://github.com/lunasec-io/lunasec/pull/277 https://github.com/lunasec-io/lunasec/pull/277
whizzter 5y ago
Even if 2.x is the main culprit right now some one twitter started testing and it seems that 1.x might be exploitable as well.
- cpu_ 5y ago
  can you share a link to the tweet/source?
  - whizzter 5y ago
    Nah it's long gone, however I've later read that the 1.2 series was declared deprecated long ago and after that there was an exploit for 1.2 released in 2019, not entirely sure if it was ever patched so that might've been the source.

No, this is about log4j2 which is kinda new (2.0.0 was released 2014). Otherwise, yeah, this is terrible, especially since the tag doesn't even have to be in the formatting string.

maxdamantus 5y ago

The sample in the in post is log4j1 ("org.apache.log4j" rather than "org.apache.logging.log4j"), which is why it's using: > log.info("foo: " + bar); rather than: > log.info("foo: {}", bar); But the issue also affects log4j2, and it doesn't matter which form of logging you use, since the transformation apparently happens further along in some appender, used by both versions of log4j.

Zardoz84 5y ago
The post examples its : log.info("Request User Agent:{}", userAgent); Also, I just try with log4j1 , and I can't reproduce it. At least with the netcat trick doesn't work : https://twitter.com/thetaph1/status/1469264526214406150?s=20 https://twitter.com/thetaph1/status/1469264526214406150?s=20
- maxdamantus 5y ago
  The post has been partially updated to log4j2 [0] (the import is still log4j1, but I imagine this will be updated soon [1]). And yes, I'm actually not sure log4j1 is vulnerable. I assumed it was because the sample code in the post was using log4j1, though the description only explicitly mentions log4j2. [0]: https://github.com/lunasec-io/lunasec/pull/270 https://github.com/lunasec-io/lunasec/pull/270 [1]: https://github.com/lunasec-io/lunasec/pull/277 https://github.com/lunasec-io/lunasec/pull/277

whizzter 5y ago

Even if 2.x is the main culprit right now some one twitter started testing and it seems that 1.x might be exploitable as well.

cpu_ 5y ago
can you share a link to the tweet/source?
- whizzter 5y ago
  Nah it's long gone, however I've later read that the 1.2 series was declared deprecated long ago and after that there was an exploit for 1.2 released in 2019, not entirely sure if it was ever patched so that might've been the source.