Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Log4j RCE Found

lunasec.io

Post reply on HN
Print view View original

341–350 of 531 posts

Re: Log4j RCE Found

#341

Post by blktiger »

ironmagma wrote: post #305
michaelt wrote: post #242

Earlier quoted context omitted.

> A logging framework's job is to ship strings to stdout or files or something. I've seen people (including here on HN) dismiss libraries as "abandoned" when they went a year without a release. The software industry will never get bug-free, feature-complete software so long as we're selecting for the opposite.

Code is alive and there’s typically always something to do: adding tests, removing bugs, or simply paying back technical debt. If you go a full year without any releasable changes, chances are the project has been abandoned.

Not only that, but no release in the last year is likely to be missing fixes for security issues on any sufficiently complicated project.

Re: Log4j RCE Found

#342

Post by d3nj4l »

jsiepkes wrote: post #220

Logback has an interesting commit[1]: "disassociate logback from log4j 2.x as much as possible". They also updated their landing page [2]: "Logback is intended as a successor to the popular log4j project, picking up where log4j 1.x leaves off. Fortunately, logback is unrelated to log4j 2.x and does not share its vulnerabilities." Can't say I blame them. [1] https://github.com/qos-ch/logback/commit/b810c115e363081afc7…

I don't think that's them being cheeky or anything. The first thing I thought of when I saw this vuln was whether logback was also affected - a lot of the services at my workplace use logback, and I've used logback for a couple of personal projects. It makes sense for them to come out today and say "We are not associated with log4j2 and don't have this vulnerability", especially because logback was built to succeed log4j 1.

Re: Log4j RCE Found

#344

Post by jcheng »

layer8 wrote: post #302
niea_11 wrote: post #283

Earlier quoted context omitted.

The method responsible for variable substitution is here [1]. There are other lookup mechanisms, (didn't check them all) but they only retrieve environment/static values (this one [2] for example retrieves kubernetes attributes). I think the jndi one is the only one that load and execute code. Edit : I think my understanding of the docs is incorrect so ignore the next paragraph From the documentation [3], I have the…

> I agree that the input should be sanitized but only if the formatting behavior is a bug and was not intentional. Non-pattern arguments should not do any substitution, because otherwise developers have to jump through hoops to output strings verbatim. You don’t want "Invalid identifier: '${ }'" to be turned into "Invalid identifier: ' '" when the actual invalid identifier (e.g. from user input) was the "${…}" syntax…

I was so surprised by the behavior your comment describes that I didn't believe it, but it's true. And it's not a bug, they do this on purpose!

From https://logging.apache.org/log4j/2.x/log4j-core/apidocs/org/...:

> Variable replacement works in a recursive way. Thus, if a variable value contains a variable then that variable will also be replaced.

And an example where this caused problems for someone:

https://www.tasktop.com/blog-under-construction/log4j-2-the-...

Re: Log4j RCE Found

#345

Post by twic »

cjcampbell wrote: post #179
garydgregory wrote: post #42

Earlier quoted context omitted.

Oracle says this is in 8u121, not 8u191: https://www.oracle.com/java/technologies/javase/8u121-relnot...

8u121 seems to address the RMI vector but not LDAP (per https://www.veracode.com/blog/research/exploiting-jndi-injec... ).

The trustURLCodebase check was added to the LDAP provider in 2009:

https://github.com/openjdk/jdk8u/commit/006e84fc77a582552e71...

This change is included in tag jdk8-b01, which was the first release build of Java 8.

I don't think this exploit as described actually works against a default-configured JVM released any time in the last decade. Is there actually an executable PoC which shows otherwise?

Now, it's true there are ways to exploit deserialisation without loading code. You need to find a class in the classpath that does something sketchy when deserialised. There has been a lot of work to clean up such things in recent years, but it's possible some still exist. Again, i would like to see a PoC.

Re: Log4j RCE Found

#346

Post by Zardoz84 »

maxdamantus wrote: post #224
JanecekPetr wrote: post #200

Earlier quoted context omitted.

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.

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.

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

Re: Log4j RCE Found

#347

Post by twic »

lewisjoe wrote: post #163

To folks wondering what the issue is about, I'll give a short summary that I myself needed. Typically a logging library has one job to do: swallow the string as if it's some black box and spit it elsewhere as per provided configurations. Log4j though, doesn't treat strings as black boxes. It inspects its contents and checks if it contains any "variables" that need to be resolved before spitting out. Now there's a bun…

> Turns out, by including "." in some part of the URL to this remote class, Log4j lets off its guard & simply looks up to that server and dynamically loads the class file.

No it doesn't. That was disabled by default in 2009, and was disabled by default in every release of Java 8 or later: https://github.com/openjdk/jdk8u/commit/006e84fc77a582552e71...

Unless i am mistaken, i don't believe the attack as described by LunaSec actually works against a default-configured JVM released any time in the last decade.

Re: Log4j RCE Found

#348

Post by Zardoz84 »

testplzignore wrote: post #333
raesene9 wrote: post #188

Earlier quoted context omitted.

There are indications ( https://twitter.com/dlitchfield/status/1469199750452822017?s... ) that log4j1 can be affected too...

That tweet has since been deleted. I haven't seen anything so far to indicate that log4j v1 is affected.

I can't reproduce with log4j 1.2.17

Re: Log4j RCE Found

#349

Post by ivan_gammel »

jimrandomh wrote: post #213
didibus wrote: post #151

Earlier quoted context omitted.

I think there's a tradeoff. Your implementation is also likely to have vulnerabilities you haven't caught, but it would be more obscure and maybe people wouldn't bother as much finding exploits for it. On the other hand, using a popular commonly used library, it will get tested for vulnerabilities a lot more thoroughly, reported and eventually patched, so it is possibly more hardened.

I don't think so. If you write your own implementation, you'll limit the scope of what you write to stuff you're actually going to use, which isn't going to include crazy stuff like what log4j turned out to have lurking inside it.

Even trivial things can have vulnerabilities. You can always substitute Criteria API in JPA with concatenation of SQL, but one missed check and you will get SQL injection.

Re: Log4j RCE Found

#350

Post by skimania »

LOG4J2-2109 wrote: post #159
nightpool wrote: post #108

Earlier quoted context omitted.

Note that the formatMsgNoLookups workaround only applies to recent versions of the log4j library, while it's still unclear how far back this bug may stretch. Other options for patching are detailed in the thread: https://github.com/apache/logging-log4j2/pull/608#issuecomme... mentions that just removing the class providing the vulnerable behavior works well, and https://github.com/Glavo/log4j-patch is a JAR that you…

The 'formatMsgNoLookups' property was added in version 2.10.0, per the JIRA Issue LOG4J2-2109 [1] that proposed it. Therefore the 'formatMsgNoLookups=true' mitigation strategy is available in version 2.10.0 and higher, but is no longer necessary with version 2.15.0, because it then becomes the default behavior [2][3]. If you are using a version older than 2.10.0 and cannot upgrade, your mitigation choices are: - Modi…

The solution of using {nolookups} on every logging pattern is only available from version 2.7 and above.

https://stackoverflow.com/a/42802636/270317

Post reply on HN