针对 Apache Log4j 2 CVE-2021-44228 和 CVE 2021-45046 的修复,PTC 建议删除 JNDILookup.class,正如 Apache 在提供的修复中所述。在 PTC 迄今为止的整个测试过程中(2021 年 12 月 10 日至 12 月 15 日),使用此方法没有产生任何不利影响。PTC 没有在我们的产品中使用这种动态加载功能,该修复方法对漏洞有效并且对我们产品风险非常低。此更改的任何风险都仅限于应用程序的日志记录子系统,并且由此产生的任何错误都远没有此漏洞的暴露那么严重。客户可以在等待官方认证的同时抢先修复漏洞,以减少其对这一关键问题的直接暴露。
在下面提供的 PTC 修复文档中,我们还将阐明 Log4j 2 在第三方应用程序中的嵌入位置以及如何修复这些应用程序。虽然 PTC 的软件可能没有使用 Log4j 2,但这些第三方组件可能已经嵌入了它们,因而应该以类似的方式修复它们。对于使用了 Log4j 2 的 PTC 产品,我们将使用更新的 Log4j 2 版本生成修补程序。但是,客户应该立即采取干预措施来保护系统而不是等待。此建议适用于客户的所有安装,包括开发和测试系统以及如下所示的生产系统以及一些桌面应用程序。
PTC 已经决定不推荐使用系统属性禁用该功能的这一替代修复选项。我们的立场是,这些在通过应用程序正确传递属性时容易出现故障情况。更糟糕的是,将来可能会被排除在外,可能无法充分保护您的系统。在 2021 年 12 月 15 日,此方法也已在公告中被声明无效:https://www.lunasec.io/docs/blog/log4j-zero-day-mitigation-guide/#option-2-enable-formatmsgnolookups
关于 2021 年 12 月 14 日发布的 Apache Log4j 1.x CVE-2021-4041 (https://bugzilla.redhat.com/show_bug.cgi?id=2031667) PTC 目前正在积极调查每个产品所需的任何修复步骤。所描述的 JMSAppender 方法会产生类似于 Log4j 2 中的漏洞的场景,攻击者可以利用 JMS Broker 对抗 JNDI/LDAP 攻击向量。此漏洞需要对系统的管理访问权限以启用此功能,默认情况下此功能处于禁用状态。考虑到启用它所需的干预操作,此 CVE 的严重性为中等风险。如果客户给自己启用了此功能,则需要考虑为此 CVE 提供的修复步骤。当获取到更多可用信息时,PTC 将披露更多有关此漏洞路径的信息。