This is especially true if that data is likely to not be strictly validated prior to logging. * Flags or properties do not fully mitigate the issue for certain (unusual) cases where user provided data is used as part of the message pattern. * Using flags such as log4j2.formatMsgNoLookups in versions < 2.15 (disabling message lookup) should only be done if upgrading is not possible, and while being aware of limitations below. * Version 2.15 can trigger JNDI calls under certain circumstances, but is unlikely to be vulnerable to any practical attacks due to 2.15 introducing a host filter in JNDI calls. This removes the attack surface and mitigate special cases mentioned below. * Version 2.16 removes message lookups altogether and disables JNDI by default (even for JMS use cases). Update 17:40 CET: * Log4j 2.16 has been released * 2.16 is now the recommended version to install. See "Older (discredited) mitigation measures" * Fixed version for apps targeting Java 7 in the works. * Even more information available at the log4j2 security page. * As mentioned below: Flags and env variables no longer considered full countermeasures. Previous versions lack the host filter, and may risk CVE if unusual logging patterns are used. In most cases this looks to be a small risk. * The CVE is marked as DOS, but note that JNDI calls can be issued to machine local addresses (Update : Reports of host filter bypass). This is for the case where attacker controlled data ends up in the log pattern (as opposed to in the log message in CVE-2021-44228), which is a less common scenario. Update 21:40 CET: * The new CVE is for the additional vulnerability is CVE-2021-45046. * Recommendations remain: Upgrade to 2.16+ if possible or remove vulnerable classes. * Most apps likely not be vulnerable to CVE-2021-45046 (requires non-standard logging procedures). Update 18:20 CET: * Reports of bypass of the host filter in 2.15 could make CVE-2021-45046 higher risk than previously discussed. Truesec has previously reported serial filter bypass internally to Log4j (among other independent reporters). * This issue is RCE since there are bypasses of the local IP filter as well as bypasses of the serialization filter. * Note that it still requires non-default logging configuration, making it considerably lower risk than the original CVE-2021-44228. CVE-2021-45105 does not look to have effects beyond DOS so far. As Truesec mentioned when that CVE was released, CVE-2021-45046 always looked to have other effects than DOS (and was later reclassified). * This CVE from CVE-2021-45046, which was initially also marked as DOS. Even in affected systems, the effect can be small. Even in those few systems that are affected, it will be highly context dependent whether the payload crashes the application or if the application recovers. * Most systems should not be affected by the DOS vector, regardless of patch level. Update 11:20 CET: * As mentioned in our other blog post, Log4j 2.17 was released and fixes CVE-2021-45105 * The CVE has a base score of 7.5, but requires special circumstances (non-standard logging procedures).
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |