存储分布式文件系统对象存储后端高可用【免费下载链接】cephCeph is a distributed object, block, and file storage platform项目地址https://gitcode.com/gh_mirrors/ce/ceph点击查看免费下载本篇技术指南以 Ceph 官方安全文档doc/security/index.rst为主线系统梳理 Ceph 的安全响应体系——从漏洞报告渠道、漏洞管理生命周期、受支持版本策略到 Security Lead 与 Security Working Group 的治理架构并结合仓库内的 CVE 档案 与 近期高危漏洞详情深入剖析 CephX 认证绕过、RGW STS 令牌 CBC 位翻转提权、Monitor config-key 越权读取、SigV4 头注入等真实漏洞的成因、影响与修复方式同时以 Crypto.h、rgw_auth_s3.cc、KVMonitor.cc 等源码佐证底层实现。读完本文你将掌握 Ceph 安全公告的解读方法、漏洞升级与密钥轮换的完整步骤以及如何按官方流程负责任地披露安全问题。一、Ceph 安全响应体系概览Ceph 是一个分布式对象、块与文件存储平台其安全章节doc/security/目录围绕四份核心文档组织文档仓库路径核心内容安全索引页doc/security/index.rst漏洞报告渠道、受支持版本策略、章节导航历史漏洞 / CVEdoc/security/cves.rst完整 CVE 时间线列表及各漏洞详情页漏洞管理流程doc/security/process.rst从收到报告到公开披露的全生命周期安全负责人与工作组doc/security/securitylead.rst、doc/security/workinggroup.rst治理角色与安全改进协调机制Ceph 安全响应的总原则是协调披露Coordinated Disclosure漏洞在修复与公告就绪之前保持保密embargo涉及敏感信息的报告绝不进入公开的 ceph tracker。这一体系确保了像 CVE-2026-50152 中涉及的 cephadm SSH 私钥、OSD LUKS 口令等机密不会在修复前被公开利用。二、漏洞报告渠道、准则与信息要求2.1 官方报告渠道根据 doc/security/index.rst所有漏洞请通过邮件发送至securityceph.io。报告时需遵循以下硬性要求不要为漏洞创建公开的 ceph tracker issue——这是 Ceph 安全响应流程的红线公开跟踪单会在修复前暴露漏洞细节破坏 embargo 协调机制尽可能提供完整信息复现程序reproducer、受影响版本、修复补丁如有这些信息能显著加速处理流程说明希望给予的致谢对象及其所属机构如果该问题尚未公开披露且你有预期的披露日期请在报告中一并说明。2.2 受支持版本策略Ceph 的漏洞修复遵循严格的版本策略安全更新仅应用于当前的 Active Releases活跃发布版本。这意味着运维人员若想获得安全修复必须保持集群处于受支持的版本线上。从近期 CVE 的修复版本可以看出这一策略的具体执行CVE-2025-30156、CVE-2026-39944、CVE-2026-50152、CVE-2026-54330 的补丁均发布于Tentacle 20.2.4与Squid 19.2.6两个活跃版本线版本兼容性检查可见于仓库 doc/releases 目录下的发布记录。2.3 邮件列表与公告渠道漏洞公开披露后最快的获取渠道是低流量邮件列表ceph-announceceph.io—— Ceph 官方公告列表oss-securitylists.openwall.com—— 开源社区通用安全公告列表。三、漏洞管理全流程Vulnerability Management Processdoc/security/process.rst 完整定义了从报告受理到公开披露的十一步流程是理解 Ceph 安全响应节奏的关键回执确认报告将在3 个工作日内收到确认回执调查与沟通安全团队调查问题在邮件线程中更新相关信息并可能向报告者索要补充材料不确认则关闭若团队无法确认该报告将不再采取进一步行动并关闭问题确认后分配 CVE若报告被确认将分配唯一的CVE 标识符并告知报告者安全团队随即开始修复工作协调披露日期CRD若报告者没有预期的披露日期安全团队成员将与列表成员协调一个发布日期并将双方同意的披露日期告知报告者披露日期避让规则漏洞披露/发布日期避开周五与节假日以降低响应延迟风险Embargo 政策对于Critical 与 High影响级别的问题优先采用 embargo保密期保密期自漏洞确认之日起原则上不超过 90 天特殊情况除外。对于影响有限、存在简便规避措施或已公开的 Low/Moderate 问题则遵循标准补丁发布流程低危漏洞的发布节奏Medium 与 Low 严重度问题的修复将随下一个标准发布周期发布列表成员在修复发布前 7 天收到预先通知CVE 修复详情写入发布说明release notes发布说明链接随公开公告发布私有仓库修复提交将在私有仓库中完成评审与测试随后从该私有仓库发布新的补丁版本下游预留期若漏洞已在公开仓库中被无意修复会给下游利益相关方/厂商数天时间准备升级然后再公开披露公开披露发布漏洞公告最快订阅渠道即上文提到的ceph-announceceph.io与oss-securitylists.openwall.com。报告者的义务如果报告处于 embargo 状态在漏洞修复并公告之前不得自行披露除非安全团队明确允许。这一约定保证了协调披露的有效性。四、Ceph 历史漏洞全景CVE 时间线doc/security/cves.rst 维护了自 2016 年以来的完整漏洞档案表以下是按时间倒序梳理的关键条目严重度依据官方标注发布日期CVE严重度摘要2026-08-19CVE-2026-54330HighRGW SigV4 头注入提权2026-08-19CVE-2026-50152HighMonitor config-key 存储越权读取2026-08-19CVE-2026-39944HighRGW STS 令牌位翻转提权2026-08-19CVE-2025-30156HighCephX 认证绕过2023-02-02CVE-2023-46159MediumRGW 引发的 DoS2023-01-17CVE-2022-3650Highceph-crash 以用户而非 root 运行2022-07-21CVE-2022-0670MediumNative-CephFS Manila 路径限制绕过2021-05-13CVE-2021-3531MediumSwift API 拒绝服务2021-05-13CVE-2021-3524MediumRGW CORS HTTP 头注入2021-05-13CVE-2021-3509HighDashboard 通过 token cookie 的 XSS2021-04-14CVE-2021-20288Highcephx 中未授权 global_id 重用2020-12-18CVE-2020-277817.1 HighManila 用户读写 CephFS 凭据2021-01-08CVE-2020-256784.9 Mediummgr 模块明文密码2020-12-07CVE-2020-256775.5 Mediumceph-ansible iscsi-gateway.conf 权限2020-11-23CVE-2020-256608.8 HighCephx 重放漏洞2020-04-22CVE-2020-120597.5 High畸形 POST 可致 RGW 崩溃2020-06-26CVE-2020-107536.5 MediumRGW CORS HTTP 头注入2020-06-22CVE-2020-107368.0 Highmon 与 mgr 授权绕过2020-04-23CVE-2020-17606.1 Medium潜在 RGW XSS2020-04-13CVE-2020-17596.8 Mediumsecure 模式下 Cephx nonce 重用2020-02-07CVE-2020-17006.5 MediumRGW 断开连接泄漏 socket 可致 DoS2020-04-21CVE-2020-16997.5 HighDashboard 路径遍历2019-12-23CVE-2019-193376.5 Medium畸形头致 RGW DoS2019-11-08CVE-2019-102227.5 High非法 HTTP 头致 RGW 崩溃2019-03-27CVE-2019-38217.5 HighRGW 文件描述符耗尽2019-01-28CVE-2018-168897.5 High加密密钥明文日志2019-01-15CVE-2018-168466.5 Medium已认证 RGW 用户可致 DoS2019-01-15CVE-2018-146625.7 Medium只读用户可窃取 dm-crypt 密钥2018-07-10CVE-2018-108618.1 High已认证用户可创建/删除 pool2018-03-19CVE-2018-72627.5 High畸形头致 RGW DoS2018-07-10CVE-2018-11296.5 Medium网络 MITM 篡改消息2018-07-10CVE-2018-11287.5 HighCephx 重放漏洞2018-07-27CVE-2017-75194.4 Mediumlibradosstriper 未校验格式化字符串2018-08-01CVE-2016-95797.6 High潜在 RGW XSS2018-07-31CVE-2016-86266.5 Medium畸形 POST 可致 RGW DoS2016-10-03CVE-2016-70317.5 HighRGW 未授权 bucket 列表2016-07-12CVE-2016-50096.5 Mediummon 命令处理器 DoS2016-12-03CVE-2015-5245—RGW 头注入模式观察RGW对象网关是历史漏洞高发区涵盖头注入、DoS、XSS、认证绕过CephX 认证协议层出现了多次重放replay与密钥管理类漏洞Dashboard 与 ceph-ansible/cephadm 等管理组件则是配置类与权限类问题的重灾区。五、近期高危漏洞深度剖析以下四个漏洞均于 2026-08-19 同日公告修复版本均为 Tentacle 20.2.4 与 Squid 19.2.6构成了 Ceph 安全体系近期的核心风险面且存在共同的根因链条——未认证的 AES-128-CBC 加密处理。5.1 CVE-2025-30156CephX AES-CBC 误用导致认证绕过根因CephX 的 AES-128-CBC 加密是未认证的——无 HMAC、使用硬编码初始化向量IV。这与 MIT 在 2004 年 PERILS 论文中记载的 Kerberos 4 缺陷同源固定 IV 意味着相同明文加密出相同密文泄露了两个加密值是否相等的信息缺少认证意味着攻击者可对密文翻转任意比特而不会被发现。攻击链攻击者只需一个被攻陷的低权限密钥如客户端凭据或能观测网络上 CephX 密文的位置即可篡改 Monitor 签发的加密服务票据。CLYSO 的 David Mohren 已演示利用该漏洞获取集群管理员权限的 PoC——具体手法包括对加密 AuthTicket 结构中的allow_all字段执行 CBC 位翻转从而获得 OSD、MDS、MGR 服务的 admin 权限。CVSS 分解机密性 High可解密/枚举凭据内容、完整性 High可重写凭据并冒充任意集群身份、可用性 Partial伪造 MGR 凭据操控集群、伪造 OSD 凭据损坏数据、认证要求为必须持有有效低权限 CephX 密钥并可访问集群网络。受影响范围所有使用aes密钥类型的旧版本 Ceph。修复方案详见 doc/security/CVE-2025-30156.rst引入基于RFC 8009Kerberos 5 标准的 AES256-CTS-HMAC-SHA384-192新密钥类型aes256k——这是 Ceph 历史上首次为 CephX 凭据引入新密钥类型每次加密操作生成128 位随机 confounder使相同明文产生随机密文HMAC-SHA384提供消息认证阻止位翻转攻击密文窃取Cipher Text Stealing消除填充防止 padding oracle 攻击密钥用途编号key usage numbers确保跨加密上下文的密钥分离。从源码看这一新密钥类型已落地于认证层src/auth/Crypto.h 中新增了crypto_aes256krb5处理器的成员声明与既有 AES 处理器并列构成新老密钥类型并存、平滑迁移的基础。升级要点升级后系统会检测遗留的不安全密钥并显示健康警告全新安装自动使用安全密钥类型现有部署继续运行但收到迁移提示。所有 Ceph daemon 包/容器必须全部升级客户端/内核升级被推荐以支持新密钥类型但非解决最严重问题所必需——Linux 内核自 7.0 起支持并已 backport 至 CentOS Stream 9/10。CVE-2025-30156 专属升级流程由于首次引入新密钥类型官方设计了专门的 daemon 密钥升级/轮换流程关键点是升级过程中会产生六个新的健康警告与错误属正常现象运维人员按auth-insecure-keys-creatable等文档指引逐项处理即可cephadm 部署会自动完成该过程客户端密钥除外Rook 部署也会自动轮换部分客户端密钥。5.2 CVE-2026-39944RGW STS 令牌 CBC 位翻转提权根因RGW 的 STS 会话令牌使用了与 CVE-2025-30156相同的未认证 AES-128-CBC 处理器——同样无 HMAC、硬编码 IV。由于密文未认证持有任意有效 STS 令牌的攻击者可对令牌中已知的acct_type与is_admin字段执行位翻转而不被察觉。攻击链伪造的is_admin值会触发rgw_process_authenticated()中的全局is_admin()覆盖绕过所有check_caps()限制授予完整 RGW admin 权限。该漏洞仅依赖攻击者已持有的有效非特权 STS 令牌且要求 STS 已启用rgw_s3_auth_use_sts true。CVSS 分解机密性 HighRGW admin 可解密该实例管理的所有账户下的对象、完整性 High、可用性 High可删除/拒绝存储数据、认证要求 Partial持有有效 STS 令牌即可无需任何初始权限。修复补丁随 Tentacle 20.2.4 / Squid 19.2.6 发布与 CVE-2025-30156 的加密层加固同源。详细档案见 doc/security/CVE-2026-39944.rst。5.3 CVE-2026-50152Monitor config-key 存储可被任意 CephX 密钥读取根因这是 Monitor订阅处理器subscription handler的越权缺陷。任何持有mon allow rcaps 的 CephX 用户只需发送一条精心构造的MMonSubscribe消息即可读取整个 Monitor config-key 存储。危险面config-key 存储用于维护 Ceph 中的各类机密包括OSD LUKS 口令在 cephadm 管理的集群上还包括 cephadm 用于在所有 Ceph 主机上认证的SSH 私钥。这意味着一个低权限的mon allow r身份可直接升级为拥有全部主机 root 权限。CVSS 分解机密性 High可窃取整个集群机密存储含 dm-crypt 密钥、dashboard 机密、网关凭据、完整性 Low凭借恢复的 cephadm SSH 密钥可间接获得每台主机 root视配置可能摧毁整个集群的密钥完整性、可用性 Low、访问复杂度 Low单条消息确定性转储无附加条件。修复与缓解修复随 Tentacle 20.2.4 / Squid 19.2.6 发布。官方建议所有用户立即升级cephadm 管理集群的运维人员强烈建议轮换 cephadm SSH 密钥流程见cephadm-ssh-configuration文档其他机密的轮换流程尚未建立运维人员应评估集群的实际暴露面决定是否立即轮换 Monitor config-key 机密。源码佐证config-key 的命令处理逻辑位于 src/mon/KVMonitor.ccconfig-key get、config-key list、config-key dump等命令前缀订阅消息处理在 src/mon/MonClient.cc / src/mon/Monitor.cc 中这正是漏洞所在的权限校验路径。5.4 CVE-2026-54330SigV4 验证器缺陷导致任意 x-amz-* 头附加提权根因AWS S3 要求 SigV4 请求中的每个x-amz-*头都必须被签名未签名的此类头会被拒绝。而 RGW只验证X-Amz-SignedHeaders中列出的头忽略其余头导致未签名的x-amz-*头绕过签名检查。攻击链仅持有预签名 PUT URL的攻击者即可附加签名者从未授权的头将 URL 的权限提升到签名账户的全部权限x-amz-copy-source public-read ACL → 读取签名者身份可访问的每个对象机密性 High写入并修改预签名 URL 目标对象的 ACL完整性 High可用性影响None。修复细节见 doc/security/CVE-2026-54330.rst补丁后的 RGW 会检查 SigV4 请求中任何未包含在签名内的新x-amz-*头若存在则直接拒绝请求。该检查逻辑可在 src/rgw/rgw_auth_s3.cc 的签名验证路径中看到——当rgw_sigv4_insecure配置为 false 时RGW 强制要求host头以及x-amz-*头必须包含在 CanonicalHeaders 签名中否则拒绝请求。关键升级步骤多站点注意事项RGW 新版本会拒绝包含未签名host与x-amz-*头的 SigV4 请求而多站点multisite场景下使用的 REST 客户端此前生成的正是这类不合法签名请求。因此升级前必须先将rgw_sigv4_insecure选项设为true所有集群升级完成后再将此选项设回false。官方强烈建议使用预签名 URL 功能的用户应尽快升级到补丁版本在未应用更新时不建议在任何情况下使用该功能。六、安全治理Security Lead 与 Security Working Group6.1 Security Lead安全负责人根据 doc/security/securitylead.rstCSCCeph 社区委员会指定一名成员担任 Security Lead职责包括协调整体安全态势向 CSC 持续更新 Ceph 内的漏洞及修复进展重点推动关键漏洞的解决每月向 CSC 汇报漏洞与新型安全关切如 AI 漏洞扫描器、抗量子加密负责漏洞的正确接收intake、分诊triage与分配assignment并在修复就绪时协调开源社区的解除 embargo维护securityceph.io邮件列表定期检查并保持利益相关方邮件处于最新状态。6.2 Security Working Group安全工作组doc/security/workinggroup.rst 说明了工作组存在的必要性随着行业对安全的关注加深Ceph 已成为成熟软件项目漏洞在数量与复杂度上持续增长单纯的被动响应已不足够需要在一个由有知识、有动力的成员组成的群体中讨论前瞻性政策。加入机制任何合理的 Ceph 安全利益相关者均可经 CSC 与安全组批准加入任何 CSC 成员可提名他人加入并参加会议。1 年以上不参加会议或故意违反 embargo 的成员将被移除并通知。加入后可获得的能力参与 Ceph 安全流程、查看所有 embargo 中的 bug、协助协调上游修复。不要求必须提交安全修复核心期望是分诊、分配与协调。职责参加每月两次的工作组会议、每月向 CSC 汇报、遵守漏洞 embargo任务按兴趣与时间在志愿者中分担。当前目标项目编写 Ceph 安全事件响应流程、编写 embargo 流程、协调积压安全 bug 的修复、协调渗透测试与扫描、审查 Ceph 的依赖与容器升级、最终协作实现 Ceph 抗量子加密。七、运维实践建议如何保持集群安全综合上述文档与源码给 Ceph 运维人员的可执行建议如下保持活跃版本线安全更新仅覆盖 Active Releases务必跟踪 doc/releases 中的版本状态及时规划升级立即评估近期漏洞若运行于 Tentacle 20.2.4 / Squid 19.2.6 之前需评估 CephX 密钥类型、STS 令牌、Monitor config-key 暴露面与预签名 URL 使用情况执行 CVE-2025-30156 密钥升级流程升级后按文档处理六个健康警告逐步轮换 daemon 密钥cephadm/Rook 部署可利用自动化客户端密钥需手动处理多站点场景升级 RGW 前先设置rgw_sigv4_insecure true全部集群升级完成后再设回false轮换机密cephadm 集群优先轮换 cephadm SSH 密钥评估 Monitor config-key 中 LUKS 口令等机密的轮换需求遵守披露纪律发现漏洞时通过securityceph.io报告绝不提交公开 tracker按流程配合 embargo 与 CRD 协调。八、总结Ceph 的安全体系是一个从漏洞发现 → 协调披露 → 补丁发布 → 运维落地的完整闭环清晰的报告渠道与十一步管理流程保障了披露节奏的可控性活跃版本线策略限定了修复覆盖范围Security Lead 与 Security Working Group 则从治理层面推动前瞻性安全改进。近期集中披露的四个高危漏洞揭示了一个重要事实——Ceph 历史上大量安全缺陷集中于未认证加密与签名验证的边界而 AES256-CTS-HMAC-SHA384-192 新密钥类型与 SigV4 严格校验的引入标志着 Ceph 在密码学层面的系统性加固。对运维者而言读懂 doc/security 目录下的每份档案、跟进活跃版本的每次补丁是保障分布式存储集群安全的最低成本路径。赞分享存储分布式文件系统对象存储后端高可用【免费下载链接】cephCeph is a distributed object, block, and file storage platform项目地址https://gitcode.com/gh_mirrors/ce/ceph点击查看免费下载相关推荐laf安全漏洞响应流程报告与修复机制安全政策概述 laf项目高度重视软件产品和服务的安全性。为保障用户数据安全和系统稳定运行我们建立了完善的安全漏洞响应机制。所有安全相关问题请通过专用渠道报告后端Serverless前端云原生如何为 Superpowers 配好持续集成从零到可部署的测试流水线如何为 Superpowers 配好持续集成从零到可部署的测试流水线 Superpowers 是一个给编程智能体用的技能库让智能体按固定方法论完成需求、计划存储分布式文件系统对象存储后端高可用Eclipse Mosquitto 安全漏洞报告指南与历史 CVE 漏洞全解析Eclipse Mosquitto 安全漏洞报告指南与历史 CVE 漏洞全解析 导读 本文以 Mosquitto 官方安全页面 www/pages/secu后端消息队列消息路由上一篇zlog源码剖析从初始化到日志输出的完整流程下一篇Fig社区生态建设为什么这个终端工具能够快速崛起创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
