Log4J, SpringShell and all that Jazz (or why bad things can happen to good software)
summary
Log4j contains a JNDI lookup feature added in 2014 that allows user-controlled strings to trigger remote lookups and arbitrary code execution so Log4Shell's JNDI lookup leading to remote code execution becomes trivially exploitable in headers, cookies, DB fields or metadata. Supply‑chain attacks rise as 90% of apps depend on OSS and 30% of Maven Central downloads still contain vulnerable Log4j versions. Practical mitigations include producing and publishing *SBOMs (CycloneDX/SPDX) and using tools like bombdoctor.sonatype.com and CycloneDX Maven plugins to automate detection and patching.
AI-written summary · about
chapters (16)
- 0:00Introduction
- 1:11Log4j worst vulnerability
- 3:57Log4j JNDI lookups
- 6:53Developers and IT responsible
- 8:20Cybercrime financial impact
- 10:10Threats from profit to warfare
- 12:15Supply chain attacks
- 15:45Exploit before publication
- 17:51Open source compromise
- 19:15Government response
- 21:19Software Bill of Materials
- 23:25Assessing project security
- 25:10Developer software selection
- 27:39Trust in open source
- 28:42Developers own security
- 29:47Q&A SBOM tools
related talks
51mLog4Shell Armageddon or Opportunity
51mDouble plus Ungood Why Log4Shell Is So Bad
17mLog4j - A Placement Student's Baptism by Fire
48mThe Hidden Security Hazards in Your Java Stack
46mAre We Ready For The Next Cyber Security Crisis Like Log4Shell?
46mAre We Ready For The Next Cyber Security Crisis Like Log4Shell?
02h 38mJava application security the hard way - a workshop for the serious developer
58mWhat the log4j incident taught us about Secure by Design