abraxaslabs.tech  ·  github.com/abraxas  ·  @abraxas_null  ·  [email protected]  ·  spark-proxyuser-classpath

spark-proxyuser-classpath

类别： 权限残留（CVE-2023-22946 / SPARK-41958 的遗留问题） 可达性： 远程

Apache Spark 4.2.0 (32f72996) - Apache Software Foundation

CVE-2023-22946 / SPARK-41958 仍然将 spark.submit.proxyUser.allowCustomClasspathInClusterMode 默认为 false，并且在 --proxy-user 集群提交时仍然执行 childClasspath.clear()。这是公开的 YARN --jars 路径。Spark 4.0 随后添加了 spark.driver.defaultExtraClassPath。启动器始终将该键前置到 spark-submit JVM 的 -cp 中，包括集群模式。SPARK-41958 从未看到它。

Livy 风格的租户仍然可以在网关 spark-submit JVM 内加载已暂存的 jar。Hadoop 的 UserGroupInformation.doAs 不会改变该 Unix UID。

ID	暂无 CVE
类别	权限残留（CVE-2023-22946 / SPARK-41958 的遗留问题）
可达性	远程（通过网关的 Livy 风格 --proxy-user 作业提交）
CWE	CWE-269、CWE-427
CVSS	高危：8.8 CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
产品	Apache Spark
受影响版本	Apache Spark 4.2.0 (32f7299601108917fb01920a54e084595b7b3bf8)
认证	Livy / Kyuubi / Oozie 风格网关的已认证租户，该网关将 --conf 和已暂存的 --jars 转发到 spark-submit --proxy-user ... --deploy-mode cluster
许可证	GNU Affero GPL v3.0
实验环境	仅 127.0.0.1:18950。见证文件。所引用启动器 / 提交路径的利用组件。

攻击者能做什么

在多租户 Spark 网关（Livy、Kyuubi、Oozie 等）上持有一个租户账户，该网关以超级用户 UID 运行 spark-submit --proxy-user <tenant> --deploy-mode cluster。暂存一个网关 JVM 可以打开的 jar。发送 --conf spark.driver.defaultExtraClassPath=<staged jar>。SPARK-41958 的门控可以保持为 false。构造出的 spark-submit -cp 仍然以该 jar 开头。其中的类以网关 Unix UID 加载。

--conf spark.submit.proxyUser.allowCustomClasspathInClusterMode=true 是第二条路径：.internal() 仅用于文档，--conf 仍然会写入该键，然后 YARN 集群会将 --jars 保留在 childClasspath 上。公开的 CVE-2023-22946 仍然是 clear() 已覆盖的 YARN 默认 --jars 路径。此遗留问题是未受门控的 defaultExtraClassPath。

干净提交后的 Hadoop 模拟仍然是 YARN AM / k8s driver 的代理用户。此遗留问题仅涉及网关 JVM。

方法	汇聚点	侦察	完整性	可用性	来源
Livy 风格提交 --proxy-user + yarn/k8s/standalone 集群 + --conf spark.driver.defaultExtraClassPath=<staged local jar>，SPARK-41958 标志保持 false	SparkSubmitCommandBuilder.buildSparkSubmitCommand SparkSubmitCommandBuilder.java:317-327 -cp 第一项	列出/读取网关 UID 可读的文件（keytab 目录、spark-defaults、本地暂存区）。后续 RPC 的 Hadoop 身份仍然是代理用户。	在 spark-submit JVM 内加载租户类。Unix UID 保持为网关（Hadoop 代理超级用户）。实验：defaultExtraClassPath-on-cp=yes childClasspath-cleared=yes lab.WitnessMain 写入了 SPARK-PROXYUSER-CLASSPATH-WITNESS。从公开 CVE 类别推断：以该 UID 进行 Hadoop Configuration 资源覆盖 / FileSystem 实现查找。	如果覆盖抛出异常，提交 JVM 崩溃。不是该类。	实验证明的加载 + 以构造的 -cp 写入见证。Hadoop 覆盖为推断。Livy/Kyuubi --conf 透传为推断（那些代码树不是此固定版本）。
相同提交加上 --conf spark.submit.proxyUser.allowCustomClasspathInClusterMode=true 以及 --jars / 主资源	SparkSubmit.prepareSubmitEnvironment SparkSubmit.scala:333-336,738-743,917-924 然后 runMain :980-987	与路径 A 相同的侦察，在子 URLClassLoader 上而非系统加载器上。	将 --jars 保留在 childClasspath 上，以便 addJarToClasspath 运行。实验：conf-flag-keeps-jars=yes。	相同。	实验证明的 childClasspath 保留。不是对公开 YARN --jars 路径（当标志保持 false 时 clear() 覆盖该路径）的重新提交。

实验证明 vs 推断： 构造的 -cp 在集群模式下包含 defaultExtraClassPath；childClasspath.clear() 在默认标志下仍然运行；spark.driver.extraClassPath 在集群中被省略；标志为 false 时 --jars 被清除；该 -cp 上的见证类写入 oracle。Hadoop 配置类执行是公开的 CVE-2023-22946 机制，此处未重新运行。Livy/Kyuubi 转发 --conf 是这些项目所记录的架构。

相邻已关闭（不要夸大）

方法	汇聚点	保持关闭
集群模式下的 --driver-class-path / spark.driver.extraClassPath	SparkSubmitCommandBuilder.java:318-319	未添加到 spark-submit 的 -cp。实验：extraClassPath-omitted=yes。传递给集群 driver，YARN/K8s 以代理用户启动它。
默认集群 + --proxy-user + --jars，不翻转标志且不使用 defaultExtraClassPath	SparkSubmit.scala:917-918 childClasspath.clear()	YARN/standalone/k8s 集群子类路径被清空。实验：对照路径上 childClasspath-cleared=yes。公开的 CVE-2023-22946 仍然是此路径。
网关上的 --proxy-user 客户端模式 driver	docs/security.md 代理用户章节	已记录：客户端模式 driver JVM 是超级用户。厂商表示不是 CVE。Livy/Kyuubi 被要求强制使用集群模式。
K8s 集群模式 driver 容器（spark.kubernetes.submitInDriver=true）将 . 添加到类路径	SparkSubmit.scala:420-431 SPARK-43540	driver pod 内的第二个 spark-submit，不是 Livy 主机。Pod UID 是容器用户。
集群模式下的 spark.driver.extraJavaOptions	SparkSubmitCommandBuilder.java:341-357	未应用于 spark-submit JVM。SPARK_SUBMIT_OPTS 是网关环境变量，不是租户 --conf。
所提交应用的 YARN AM / k8s driver	干净提交后的 Hadoop 模拟	仍然是集群启动的代理用户。此遗留问题仅涉及网关 JVM。
未认证作业提交 / Connect SQL / ML 模型加载	SECURITY.md FAQ / docs/ml-security.md	按设计。不是此遗留问题。

我是如何发现的

我固定了 Spark 4.2.0（32f7299601108917fb01920a54e084595b7b3bf8），并走查了 SparkSubmit.submit / prepareSubmitEnvironment / runMain、SPARK-41958 标志以及启动器 -cp 构建器。公开的 Medium 文章在 --jars 路径上仍然成立：默认 allowCustomClasspathInClusterMode 为 false（package.scala:2849-2854），并且集群 + proxy-user 仍然清除 childClasspath。--conf 仍然写入该内部键（SparkSubmitArguments.scala:474-476）。另外，Spark 4.0.0 的 spark.driver.defaultExtraClassPath 始终在 spark-submit 的 -cp 上，包括集群模式：

boolean isClientMode = isClientMode(config);
String extraClassPath = isClientMode ? config.get(SparkLauncher.DRIVER_EXTRA_CLASSPATH) : null;
String defaultExtraClassPath = config.get(SparkLauncher.DRIVER_DEFAULT_EXTRA_CLASS_PATH);
if (extraClassPath == null || extraClassPath.trim().isEmpty()) {
  extraClassPath = defaultExtraClassPath;
} else {
  extraClassPath += File.pathSeparator + defaultExtraClassPath;
}
List<String> cmd = buildJavaCommand(extraClassPath);

4.0.0 的键是 .internal()（package.scala:80-85）。--conf 仍然写入它（SparkSubmitCommandBuilder.java:572-576）。SPARK-41958 从未对此路径设门控：该 jar 在 SparkSubmit 启动之前就已在系统类加载器上。

已记录的弯路：重新提交公开的 CVE-2023-22946（clear() 覆盖的 YARN --jars 路径）；将客户端模式 driver 作为超级用户视为 CVE（security.md 表示不是）；Ivy spark.jars.ivySettings（不同的利用组件）；SPARK_DIST_CLASSPATH / SPARK_SUBMIT_OPTS（网关环境变量，不是租户 --conf）；clear() 之后的日志行（记录已为空的缓冲区）。表演：反向 shell。oracle 是当构造的 -cp 加载 lab.WitnessMain 时写入的见证字符串。

实验环境

python3 spark-proxyuser-classpath-Abraxas-Labs.py

或

cd lab
./run.sh

固定版本 SparkSubmitCommandBuilder.buildSparkSubmitCommand 和 SparkSubmit.prepareSubmitEnvironment 的利用组件。回环 127.0.0.1:18950。Docker。一个进程中的四条路径：

1. 对照：--proxy-user + yarn 集群 + --jars evil.jar - childClasspath.clear()，构造的 -cp 中没有攻击者 jar。
2. 已关闭：--conf spark.driver.extraClassPath=evil.jar 从提交 -cp 中省略。
3. 遗留：--conf spark.driver.defaultExtraClassPath=/opt/lab/evil.jar 且门控仍然关闭 - -cp 为 evil.jar，子 JVM 加载 lab.WitnessMain，写入 WITNESS。
4. 标志翻转：--conf spark.submit.proxyUser.allowCustomClasspathInClusterMode=true 将 --jars 保留在 childClasspath 上。

SUCCESS SPARK-PROXYUSER-CLASSPATH defaultExtraClassPath-on-cp=yes childClasspath-cleared=yes extraClassPath-omitted=yes conf-flag-keeps-jars=yes SPARK-PROXYUSER-CLASSPATH-WITNESS

修复方案