通过与 Jira 对比,让您更全面了解 PingCode

  • 首页
  • 需求与产品管理
  • 项目管理
  • 测试与缺陷管理
  • 知识管理
  • 效能度量
        • 更多产品

          客户为中心的产品管理工具

          专业的软件研发项目管理工具

          简单易用的团队知识库管理

          可量化的研发效能度量工具

          测试用例维护与计划执行

          以团队为中心的协作沟通

          研发工作流自动化工具

          账号认证与安全管理工具

          Why PingCode
          为什么选择 PingCode ?

          6000+企业信赖之选,为研发团队降本增效

        • 行业解决方案
          先进制造(即将上线)
        • 解决方案1
        • 解决方案2
  • Jira替代方案

25人以下免费

目录

漏洞深度分析|CVE-2023-25141 sling-org-apache-sling-jcr-base存在JNDI注入漏洞

项目介绍

Apache Sling提供对可插入资源提供程序的支持。虽然这允许将自定义数据提供程序非常灵活和高效地集成到Sling中,但这种集成是在Sling的资源 API 级别上完成的。可能依赖于能够将资源适配到JCR节点并继续使用JCR API的遗留代码将不适用于此类资源提供者。

为了支持遗留代码,这个包提供了一个SPI接口org.apache.sling.jcr.base.spi.RepositoryMount,它扩展了JackrabbitRepository(并通过这个javax.jcr.Repository)。注册为RepositoryMount的服务使用服务注册属性RepositoryMount.MOUNT_POINTS_KEY 注册自己,这是一个 String+ 属性,包含 JCR 树中的路径,其中挂载接管 JCR 节点的控制。RepositoryMount可以注册在一个或多个路径。

由于RepositoryMount扩展了JackrabbitRepository挂载的实现需要实现整个 JCR API。与ResourceProvider相比,这是很多工作,因此只有在需要支持使用 JCR API 的遗留代码时才应使用RepositoryMount 。

JCR 基础包提供 JCR 实用程序类和对存储库安装的支持。

项目地址

https://github.com/apache/sling-org-apache-sling-jcr-base

https://sling.apache.org/

漏洞概述

在 JDK 1.8.191 或更低版本中运行 Apache Sling JCR Base 且项目版本小于 3.1.12 时可能存在注入漏洞,由于 RepositoryAccessor.java 中的 getRepository 方法和 getRepositoryFromURL 方法对传入的参数验证不当导致 JNDI 或 RMI 注入漏洞。远程攻击者可以通过 JDNI 和 RMI 连接访问存储在服务器上的任意数据。

影响版本

org.apache.sling:org.apache.sling.jcr.base@(-∞, 3.1.12)

环境搭建

下载源码,运行构建即可。

漏洞分析

sling 项目的jcr基础库(/sling-org-apache-sling-jcr-base)提供两个函数

RepositoryAccessor#getRepository 和 RepositoryAccessor#getRepositoryFromURL

其中 RepositoryAccessor#getRepositoryFromURL

这个函数的功能是根据给定的 URL 获取仓库对象 Repository,这个函数可能是为应用程序提供访问存储在远程位置的数据的方法

1676546604_63ee122c24316a719c05c.gif!small?1676546604794

该函数将传入的 jndi name 和 内容传给类里的另一个函数 RepositoryAccessor#getRepository

1676546621_63ee123d909401324bedf.gif!small?1676546623140

这个函数的作用是根据给定的 URL 获取仓库对象 Repository。

函数的参数:

  • url:一个字符串,表示仓库对象的 URL。

函数的返回值:

  • 如果成功获取仓库对象,则返回仓库对象。
  • 如果无法获取仓库对象,则抛出异常。

如果 URL 的前缀是 “jndi://”,则函数会尝试从 JNDI 环境获取仓库对象。否则,它会使用 getRepository 函数尝试从 JNDI 和 RMI 两种途径获取仓库对象。

但是存在直接使用 initialContext.lookup(repositoryName) 的漏洞点,

仅存在一个if判断 jndiContext 是否为空或大小是否为 0,并未对用户可控的值进行检查

source点如下所示

1676546634_63ee124a6269f4335b5d9.gif!small?1676546635208lookup存在两个重载

1676546655_63ee125f230bf4bdcef65.gif!small?1676546655689

看一下 lookup 的调用方法,传进 InitialContext#getURLOrDefaultInitCtx

1676546664_63ee12686f111b1577b8a.gif!small?1676546665028

lookup 拿到 name ,getURLScheme匹配 :和 /;之后获取链接内容,getURLContext 解释包含样例

For example, if the scheme id is “ldap”, and the Context. URL_PKG_PREFIXES property contains “com.widget:com.wiz. jndi”, the naming manager would attempt to load the following classes until one is successfully instantiated:
· com.widget.ldap.ldapURLContextFactory
· com.wiz.jndi.ldap.ldapURLContextFactory
· com.sun.jndi.url.ldap.ldapURLContextFactory

而我们可以控制 lookup 函数的参数,使客户端访问提前设置好的恶意的 RMI 服务链接来加载恶意的对象class 字节码文件来实例化,从而执行代码,完成利用。

该类并不存在任何黑/白名单对用户传入进行过滤,用户可直接传入rmi 恶意链接执行命令。确定该处存在 jndi注入,可被利用导致命令执行

修复方式

组件 org.apache.sling:org.apache.sling.jcr.base 升级至 3.1.12 及以上版本

参考链接

https://nvd.nist.gov/vuln/detail/CVE-2023-25141

查看更多安全漏洞:快速查询安全漏洞柒巧板

文章来自:https://www.freebuf.com/

相关文章