物联网消息队列后端网络/通信【免费下载链接】mosquittoEclipse Mosquitto - An open source MQTT broker项目地址https://gitcode.com/gh_mirrors/mo/mosquitto点击查看免费下载本篇文章以 Eclipse Mosquitto 官方安全公告security-advisory-cve-2017-7650为骨架结合当前仓库源码src/security_default.c、src/plugin_acl_check.c、lib/util_topic.c与配置示例aclfile.example、mosquitto.conf完整还原 CVE-2017-7650 的成因、危害、修复方案及当前实现中的纵深防护逻辑。读者读完后将能准确理解 Mosquitto Pattern 型 ACL 的匹配机制识别并规避同类绕过风险并掌握 1.4.12 修复版本中针对危险用户名/客户端 ID 的访问限制策略。一、漏洞总览什么是 CVE-2017-7650CVE-2017-7650 是 Mosquitto 历史上一个与**基于模式Pattern的访问控制列表ACL**相关的安全漏洞影响0.15 至 1.4.11含的所有版本。漏洞的核心危害在于客户端将自身的 username用户名或 client id客户端标识设置为#或时可以绕过 Pattern 型 ACL 的限制从而访问本无权访问的 MQTT 主题。由于 MQTT 的#与分别是多层通配符与单层通配符它们在主题过滤器中具有特殊语义而当它们出现在 username / client id 中并被拼入 Pattern ACL 的检查路径时会破坏 ACL 匹配的预期语义导致权限判定被绕过。公告同时指出同样的缺陷可能存在于第三方认证/访问控制插件中即使用 Mosquitto 插件接口实现 ACL 判断的插件若直接以%c/%u方式拼装主题后再做通配匹配同样面临被#/注入的风险。漏洞仅在使用Pattern 型 ACL或可能使用第三方插件的部署场景下才会实际触发不使用 Pattern ACL 的默认配置不受影响。该漏洞由 HackerDom CTF 战队的 Artem Zinenko 发现并负责任地报告已在Mosquitto 1.4.12中修复官方同时为旧版本提供了补丁。二、前置知识Mosquitto 的 ACL 与 Pattern 型 ACL要理解漏洞先要理解 Mosquitto 的访问控制体系。Mosquitto 的 ACL 定义在acl_file指定的文件中对应配置项acl_file支持三种粒度匿名/全局主题规则文件开头的topic行作用于所有匿名客户端用户专属规则user username行之后的topic行只作用于指定用户Pattern模式替换规则pattern行使用%c客户端 ID与%u用户名做占位符对所有客户端生效。官方示例文件 aclfile.example 完整展示了这三种写法# This affects access control for clients with no username. topic read $SYS/# # This only affects clients with username roger. user roger topic foo/bar # This affects all clients. pattern write $SYS/broker/connection/%c/state其中最后一行pattern write $SYS/broker/connection/%c/state的含义是允许任意客户端以其 client id 替换%c向$SYS/broker/connection/client-id/state主题写入连接状态消息——这也是官方推荐的 bridge 连接消息授权写法。Pattern 语法的官方约束mosquitto.conf 中对 Pattern ACL 的语法做了完整说明可用占位符%c匹配客户端 ID%u匹配用户名替换占位符必须是主题层级中唯一的文本即%c/%u必须独占一个 topic level不能与其它字符拼接如foo%c属于非法用法语法形式与topic关键字相同只是关键字换成patternpattern [read|write|readwrite] topic示例pattern write sensor/%u/data允许各用户向自己的sensor/username/data写数据Pattern ACL 对所有用户生效即使前面已经定义了user规则deny型规则topic ... deny或pattern ... deny优先于放行规则处理。在源码层面Pattern 规则的解析与存储由 src/security_default.c 中的add__acl_pattern()完成函数会统计该 pattern 中包含的%cacl-ccount与%uacl-ucount出现次数用于后续匹配时判断是否需要替换若一条 pattern 既不含%c也不含%u会打印警告日志。同时denyMOSQ_ACL_NONE型 ACL 会被插入到放行型 ACL 链表头部保证先否定、后放行的判定顺序。三、漏洞原理深度剖析#与如何绕过 Pattern ACL3.1 匹配替换机制Pattern ACL 的匹配逻辑位于 src/security_default.c 的mosquitto_acl_check_default()中。核心调用是mosquitto_topic_matches_sub_with_pattern(acl_root-topic, ed-topic, ed-client-id, ed-client-username, result);该函数声明于 lib/util_topic.c实为topic_matches_sub(sub, topic, clientid, username, true, result)的封装先把 pattern 中的%c/%u替换为客户端真实的 client id / username再按 MQTT 主题通配规则单层、#多层进行匹配。3.2 绕过路径通配符注入问题出在替换后的匹配阶段。当客户端将 username 或 client id 设置为#或时#作为 username/client id替换进 pattern 后形如sensor/%u/data会变成sensor/#/data——在 MQTT 主题语义中#是匹配剩余所有层级的多层通配符。虽然sensor/#/data这种#不在末级的写法在标准订阅里不合法但基于字符串的匹配实现中#一旦被注入就可能使检查路径产生非预期的匹配成功结果从而让客户端获得它本不该拥有的读/写权限。作为 username/client id同理被替换进 pattern 后充当匹配任意单层的通配符使客户端得以命中任何符合该层级结构的主题。因此攻击者只需要把 MQTT CONNECT 报文中的 username 或 client id 直接写成#/就能让 Pattern ACL 的权限判定自我放行实现本地或远程的越权访问。公告原话是这类客户端可以访问它们本没有权限访问的 MQTT 主题。3.3 影响面判定仅限 Pattern 与插件场景从源码可以精确确认漏洞的触发前提。在mosquitto_acl_check_default()中若acl_file、内存 ACL 列表、pattern 列表三者皆为空直接返回MOSQ_ERR_PLUGIN_IGNOREsrc/security_default.c仅当security_opts-acl_patterns非空时才会进入危险字符检查与 pattern 匹配循环src/security_default.c。这印证了公告的结论只有启用 Pattern 型 ACL或使用存在同类问题的第三方认证/访问控制插件时漏洞才实际生效。纯topic字面量 ACL含/#通配符的静态规则不受此漏洞影响——因为静态规则中的通配符是管理员明确写入的不存在客户端可控的注入面。此外还有一个值得注意的细节从当前源码看mosquitto_acl_check_default()对MOSQ_ACL_SUBSCRIBE/MOSQ_ACL_UNSUBSCRIBE直接返回成功src/security_default.c即订阅/退订请求不经过默认 ACL 的 pattern 检查漏洞风险主要集中于**发布write与读取read**路径。3.4 完整调用链消息收发路径上的 ACL 判定统一收敛到 src/plugin_acl_check.c 的mosquitto_acl_check()其调用链如下发布路径src/handle_publish.c 以MOSQ_ACL_WRITE调用订阅路径src/handle_subscribe.c 以MOSQ_ACL_SUBSCRIBE调用退订路径src/handle_unsubscribe.c 以MOSQ_ACL_UNSUBSCRIBE调用投递/保留消息读取路径src/database.c、src/retain.c、src/subs.c 以MOSQ_ACL_READ调用持久化恢复场景src/context.c。mosquitto_acl_check()的判定顺序是先执行插件的 ACL 检查回调plugin__acl_check再执行内置的默认 ACL 检查mosquitto_acl_check_default并处理MOSQ_ERR_PLUGIN_IGNORE视为插件不存在与MOSQ_ERR_PLUGIN_DEFER延迟判定最终按拒绝处理两种特殊返回码。这意味着即便内置 ACL 已修复第三方插件若直接用%c/%u拼接后做通配匹配仍可能单独存在同类漏洞——这正是公告特别提醒同一问题可能存在于第三方插件的原因。四、官方修复方案1.4.12对危险用户名/客户端 ID 的访问限制4.1 修复策略Mosquitto 1.4.12 的修复思路是从源头切断通配符注入对 username 或 client id 中包含#、的客户端直接拒绝其收发任何受 Pattern ACL 或插件检查的消息。公告明确列出的修复要点如下修复针对客户端 username / client id 中含#、的访问限制问题/斜杠也被一并列入禁用字符因为它在主题中同样具有层级分隔的特殊语义可能构成额外风险受限制的客户端将不能接收或发送任何受 Pattern ACL 检查的消息也不能收发任何受插件检查的消息。4.2 当前仓库源码中的防护实现虽然本仓库为后续演进版本但防护逻辑清晰保留在 src/security_default.c 的mosquitto_acl_check_default()中。在进入 pattern 匹配循环之前源码先做危险字符检查if(ed-client-username strpbrk(ed-client-username, #)){ log__printf(NULL, MOSQ_LOG_NOTICE, ACL denying access to client with dangerous username \%s\, ed-client-username); return MOSQ_ERR_ACL_DENIED; } if(ed-client-id strpbrk(ed-client-id, #)){ log__printf(NULL, MOSQ_LOG_NOTICE, ACL denying access to client with dangerous client id \%s\, ed-client-id); return MOSQ_ERR_ACL_DENIED; }这段代码的语义要点检查对象是username 与 client id 两者任一带或#即拒绝检查仅发生在 pattern ACL 存在时外层有if(acl_root){...}包裹与公告仅 Pattern 场景受影响的定位一致拒绝时打印MOSQ_LOG_NOTICE级别日志便于运维人员发现恶意尝试该检查位于mosquitto_acl_check_default()内部因此仅约束内置 ACL插件侧仍需插件自身处理MOSQ_ERR_PLUGIN_DEFER/MOSQ_ERR_PLUGIN_IGNORE语义详见 src/plugin_acl_check.c。需要说明的是当前仓库实现中以#作为危险字符集合而 1.4.12 公告中同时提及将/列入禁用列表——两处表述存在差异若你的部署依赖旧版行为请以对应版本的实际源码为准。无论采用哪个字符集合核心原则一致任何可能被替换进 pattern 并充当通配符的字符都必须从客户端可控字段中剔除。4.3 插件侧的修复义务公告特别强调同一问题可能存在于第三方认证/访问控制插件。从调用链看src/plugin_acl_check.c 中插件回调先于内置 ACL 执行且插件返回的非IGNORE/DEFER结果会直接作为最终裁决。因此若你的插件自行实现了%c/%u替换与通配匹配必须同样校验 username / client id 中的危险字符若插件只是转发给内置 ACL返回MOSQ_ERR_PLUGIN_IGNORE或MOSQ_ERR_PLUGIN_DEFER则 1.4.12 的内置修复已足够覆盖。五、1.4.12 版本完整修复清单除 CVE-2017-7650 外公告还列出了 1.4.12 在 Broker 侧修复的其它问题供升级决策参考修复因客户端消息在无存储消息的情况下被持久化导致mosquitto.db损坏的问题修复 bridge 无法正确重启的问题修复 Windows 平台gets_quiet中的未初始化内存问题修复非 glibc 系统上WITH_ADNSno的构建问题修正 README 文档修复 OpenSSL 1.1 的弃用警告修复重复 bridge 名称导致的段错误segfault问题修复 CVE-2017-7650。六、安全建议与缓解措施结合公告与源码给出如下实操建议立即升级若使用 0.15–1.4.11 且启用了 Pattern ACL 或第三方 ACL 插件应升级至 1.4.12 或更高版本无法升级的旧版本部署可获取官方为旧版提供的补丁。检查配置面确认acl_file中是否使用了pattern关键字mosquitto.conf 提供了完整的 pattern 语法与示例并审视第三方插件的 ACL 实现是否直接拼接%c/%u后做通配匹配。启用日志监控升级后针对dangerous username/client id的NOTICE日志src/security_default.c可帮助识别正在尝试注入通配符的恶意客户端建议接入日志告警。纵深防御Pattern 规则本身遵循deny 优先于 allow的链表排序src/security_default.c建议在敏感主题上显式添加deny规则作为字符校验之外的兜底。遵循占位符规范编写 pattern 时务必让%c/%u独占一个主题层级如sensor/%u/data避免任何可能导致通配符与字面量混淆的拼接写法。七、总结CVE-2017-7650 是 MQTT 通配符语义与 ACL 模式替换机制相互作用下产生的典型注入类漏洞#/既可以是合法的客户端标识字符也可以在 pattern 匹配时被解释为主题通配符。Mosquitto 的修复通过禁止危险字符出现在 username / client id 中从根上消除了注入面而当前仓库 src/security_default.c 中保留的防护代码正是这一安全决策在长期演进中的延续。理解这一漏洞对自行开发 MQTT 访问控制插件、或审计 Broker ACL 配置的工程师都具有直接的参考价值。赞分享物联网消息队列后端网络/通信【免费下载链接】mosquittoEclipse Mosquitto - An open source MQTT broker项目地址https://gitcode.com/gh_mirrors/mo/mosquitto点击查看免费下载相关推荐Eclipse Mosquitto CVE-2017-7650 安全公告解读pattern ACL 绕过漏洞的成因与修复方案Eclipse Mosquitto CVE 2017 7650 安全公告解读pattern ACL 绕过漏洞的成因与修复方案 导读 本文围绕 Mosquitt后端消息队列消息路由Eclipse Mosquitto 安全公告解读CVE-2017-7651 与 CVE-2017-7652 的漏洞原理、修复机制与 1.4.15 加固实践Eclipse Mosquitto 安全公告解读CVE 2017 7651 与 CVE 2017 7652 的漏洞原理、修复机制与 1.4.15 加固实践 本后端消息队列消息路由Paddle 安全公告深度解析paddle.topk 浮点异常漏洞CVE-2023-52305的原理与修复Paddle 安全公告深度解析paddle.topk 浮点异常漏洞CVE 2023 52305的原理与修复 导读 本文基于 Paddle飞桨核心框架安人工智能深度学习机器学习大模型分布式训练预训练上一篇快速录制 macOS 系统声音QuickRecorder 从权限到成片 5 步搞定下一篇gmaps性能优化处理大规模地理数据集的10个技巧创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考