#今天又看了啥 #security #CVE #docker
CVE-2026-33590 — Portainer 默认配置不安全导致宿主机接管
CVSS 3.1 8.2 HIGH
Portainer < 2.38.0 的 Endpoint Security 默认配置过度宽松，允许普通用户（非管理员）在创建容器时启用 bind mount、privileged mode、host namespace 等高危能力，攻击者可借此挂载宿主机文件系统或以特权模式运行容器，实现从容器逃逸到宿主机的完全接管。

默认开启的危险配置项（共 7 项）：
- allowBindMountsForRegularUsers — 允许挂载宿主机任意路径
- allowPrivilegedModeForRegularUsers — 允许特权模式
- allowHostNamespaceForRegularUsers — 允许共享宿主机 PID/IPC namespace
- allowDeviceMappingForRegularUsers — 允许访问宿主机设备
- allowContainerCapabilitiesForRegularUsers — 允许选择 root capabilities
- allowSysctlSettingForRegularUsers — 允许 sysctl 操作
- allowStackManagementForRegularUsers — 允许 compose stack 管理

PoC：以普通用户身份认证 → 找到本地 Docker endpoint → 用 alpine 镜像 bind mount 宿主机 /etc/ → 直接读取 /etc/shadow。

修复：升级至 2.38.0（STS）或 2.39.0（LTS），以上配置项默认改为 false（仅 stack 管理保留 true）。升级后需手动检查 Docker Security Settings。

说人话：

Portainer 老版本有个问题：管理员给你建了个普通账号，你能自己开个容器把整台宿主机的硬盘挂进去，然后随便翻文件、读密码、写 crontab——等于直接拿下宿主机 root。
原因是 Portainer 默认把 7 个高危开关全部打开了，比如"允许普通用户挂载宿主机目录""允许特权模式"。
你需要升级版本，然后去 Settings → Docker Security Settings 确认那些开关都关了。如果你是多人共用的 Portainer 实例，建议顺便审一下历史容器有没有被滥用过。

🔗 技术分析博文 · 安全公告

感觉这个漏洞本质上是个设计缺陷而非代码 bug，默认信任用户不会滥用容器特权，不过在多用户环境下还是有很大风险。

Intwave

Improving Portainer Security

Product Security Services

#security
Pintheft LPE
Linux RDS(Reliable Datagram Sockets) 模块存在重复释放问题导致攻击者可以利用 io_uring 模块去覆写具有 suid 的 Page cache 从而实现LPE。
缓解办法：拉黑 rds_tcp rds 模块

# rmmod rds_tcp rds
# printf 'install rds /bin/false\ninstall rds_tcp /bin/false\n' > /etc/modprobe.d/pintheft.conf

https://github.com/v12-security/pocs/tree/main/pintheft

#今天又看了啥 #security
io_uring ZCRX Freelist LPE — 从 u32 到 root -- ze3tar
https://ze3tar.github.io/post-zcrx.html

漏洞概要
- Linux 6.15~6.19 中 io_uring 新子系统 ZCRX（零拷贝收包）存在 OOB（越界）堆写入漏洞
- 漏洞位置：freelist[] 管理空槽索引时，free_count 无上界检查，导致写入 freelist[num_niovs]（超尾 4 字节）
- 写入值：niov 索引，范围 [0, N-1] —— 看似没用，实则致命

触发条件
- 需要 CAP_NET_ADMIN 权限
- 需要支持 ZCRX 的物理网卡（Mellanox ConnectX-6+、Intel E800、NFP 等）
- 触发方式：网卡 down（SIOCSIFFLAGS ~IFF_UP）→ page_pool_destroy() → 两条路径（ptr_ring drain + scrub loop）重复入栈导致 free_count 溢出

利用链
1. 选择 area 大小 → 控制 num_niovs → 控制 freelist 所在的 slab cache → 控制相邻对象
2. 堆喷 msg_msg（kmalloc-128）→ 让 freelist 与 msg_msg 相邻
3. 触发 OOB → 覆盖相邻 msg_msg 的 m_list.next 低 4 字节
4. msgrcv 堆读取 → 扫描内核指针 → 破解 KASLR
5. 写 modprobe_path（通过 /proc/sys/kernel/modprobe）→ 指向恶意脚本
6. 触发未知 socket 协议 → call_usermodehelper → 提权为 root

修复
- commit 770594e（2026-04-21），在 io_zcrx_return_niov_freelist 中增加 free_count >= num_niovs 检查
- 尚未合入任何 stable 分支，仍在路上的内核均有风险

PoCs 已公开
- zcrx_crash.c — 纯 OOB 触发验证
- zcrx_lpe.c — 完整 LPE 利用链（KASLR + modprobe_path + SUID bash）

一句话：io_uring 新版 ZCRX 没做边界检查，网卡 down 时重复入栈写穿 slab，一个 0~31 的小整数一路打到 root。 🔥

需要高端网卡，散了散了