{"id":34515,"date":"2021-12-21T14:55:29","date_gmt":"2021-12-21T19:55:29","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=34515"},"modified":"2021-12-21T14:55:29","modified_gmt":"2021-12-21T19:55:29","slug":"infinite-recursion-in-log4j-2-16","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2021\/12\/21\/infinite-recursion-in-log4j-2-16\/","title":{"rendered":"Infinite Recursion in Log4j 2.16"},"content":{"rendered":"

Ross Cohen<\/a> (via Hacker News<\/a>):<\/p>\n

If a string substitution is attempted for any reason on the following string, it will trigger an infinite recursion, and the application will crash: ${${::-${::-$${::-j}}}}<\/code>.<\/p><\/blockquote>\n\n

This is fixed in Log4j 2.17.<\/p>\n\n

xg15<\/a>:<\/p>\n

\n

So, let me get this: Log4j is disabling JNDI, fixing various string substitution issues and who knows what else, but the root cause of the whole mess - that Log4j attempts string substitution on the actual parameter values<\/em> remains untouched?<\/p>\n<\/blockquote>\n\n

That is<\/em> weird, but presumably changing it would break a lot of stuff. However, this article<\/a> makes it seem like simply injecting into one of the parameters is not sufficient to trigger the infinite recursion, depending on how the logger was configured.<\/p>\n\n

The scary thing is that I doubt that Log4j is unusually buggy. It’s just that more people are scrutinizing it now and finding these latent problems.<\/p>\n\n

Previously:<\/p>\n