flawopen.com/Инциденты/Log4Shell

Log4Shell: день, когда запись в файл лога превратилась в удаленное исполнение кода

The lessons that actually transfer

• ✓Template and data must stay separate. This is the same principle behind parameterised SQL queries and safe HTML templating. Log4Shell is what happens when a library quietly interpolates the data side.
• ✓Features reachable from untrusted input are attack surface, however benign they look. Nobody logged a bug saying "our logger can load remote classes" — it was an emergent property of two reasonable features meeting.
• ✓You cannot patch what you cannot inventory. The hardest part of Log4Shell for most organisations was not applying the fix — it was discovering which of their applications bundled Log4j transitively. This is the strongest argument in recent memory for maintaining a software bill of materials.
• ✓Restrict outbound network egress from application servers. Exploitation depended on the victim server making an outbound connection to the attacker. Default-deny egress broke the chain even on unpatched systems.
• ✓Expect the first patch to be incomplete. 2.15.0 was not sufficient; two further CVEs followed. When a flaw is this structural, treat the first release as the start of remediation rather than the end.

FAQ

Related reading

• Is Java's ObjectInputStream safe to use on untrusted data?
• Command Injection — full class reference

Источники и официальные бюллетени

• Apache Log4j — security vulnerabilities page
• NVD — CVE-2021-44228 detail
• CISA — Apache Log4j vulnerability guidance
• CISA — Known Exploited Vulnerabilities catalog
• CWE-917 — Expression Language Injection