While this is technically a denial-of-service, had the exact conditions for it not also enabled code execution as outlined above, it would have only presented a risk to code that assumed there would be no uncaught exceptions. Based on the stack trace provided by LunaSec, it appears that at least simple self-references are detected by Log4j, which raises a a type of RuntimeException that would generally raise until a catch-all exception handler. The denial-of-service listed appears to be the potential for infinite loops whereby an controlled ThreadContext value self-references itself. Log4j 2.15.0 restricts JNDI LDAP lookups to localhost by default. As you have probably learned, basically every Java app in the world uses a library called “ log4j” to handle logging, and that any string passed into those logging calls will evaluate magic $) or a Thread Context Map pattern (%X, %mdc, or %MDC) to craft malicious input data using a JNDI Lookup pattern resulting in a denial of service (DOS) attack. Update (12/16/21): This post has been updated in line with new information regarding incomplete patches for CVE-2021-44228 CVE-2021-45046 weaknesses in the official mitigations and the log4j release with updated fixes, 2.16.0. In this post, we first offer some context on the vulnerability, the released fixes (and their shortcomings), and finally our mitigation (or you can skip directly to our mitigation tool here). This will prevent malicious inputs from triggering the “Log4Shell” vulnerability and gaining remote code execution on your systems. Tl dr Run our new tool by adding -javaagent: log4j-jndi-be-gone-1.0.0-standalone.jar to all of your JVM Java stuff to stop log4j from loading classes remotely over LDAP.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |