News for hackers. Stuff that matters.

A comment on Log4Shell Log4j vulnerability (CVE-2021-44228) – cheat-sheet reference guide.

Re:Log4Shell Log4j vulnerability (CVE-2021-44228) – cheat-sh... by layer8 on Monday December 13, 2021 @02:47PM (#29543609)
> A project with a footprint like Log4j is not possible to avoid as a transient dependency even if you don’t directly import it.

But it’s often still possible to use a different backend, via the Log4j to SLF4J adapter: https://logging.apache.org/log4j/2.x/log4j-to-slf4j/

[ Parent | on HN ]
Re:Log4Shell Log4j vulnerability (CVE-2021-44228) – cheat-sh... by shartte on Monday December 13, 2021 @03:44PM (#29544383)
I believe this is the default in Spring Boot. Logback is used by their starters (see https://docs.spring.io/spring-boot/docs/current/reference/ht...).
[ Parent | on HN ]
Re:Log4Shell Log4j vulnerability (CVE-2021-44228) – cheat-sh... by zorr on Monday December 13, 2021 @04:38PM (#29545015)
Yes, recent Spring-boot projects include log4j-to-slf4j, slf4j-api, logback-core and logback-classic which AFAIK are not vulnerable.
[ Parent | on HN ]
Re:Log4Shell Log4j vulnerability (CVE-2021-44228) – cheat-sh... by staticassertion on Monday December 13, 2021 @03:57PM (#29544555)
Does this routing happen before or after log4j would be exploitable? Like if log4j is still running its parser and doing all the crazy stuff, but then routes to some other logger, it doesn't matter.
[ Parent | on HN ]
Re:Log4Shell Log4j vulnerability (CVE-2021-44228) – cheat-sh... by layer8 on Monday December 13, 2021 @04:03PM (#29544620)
The routing happens before. The vulnerability is due to processing in the log4j back-end, after normal message formatting.
[ Parent | on HN ]
Re:Log4Shell Log4j vulnerability (CVE-2021-44228) – cheat-sh... by staticassertion on Monday December 13, 2021 @04:08PM (#29544663)
Got it, thanks.
[ Parent | on HN ]