Windows下用Boost Interprocess实现服务与用户程序安全通信

先直接回应你最关心的代码执行问题：哪怕你只存offset_ptr和普通数据类型、不存原生指针，也完全可能被攻击者利用实现权限提升甚至任意代码执行，你现在给所有用户开放GENERIC_READ和GENERIC_WRITE的实现风险非常高，远不止中断通信这一种后果。

具体存在的安全风险 #

• 首先是你已经意识到的拒绝服务风险：任意用户都可以随意篡改共享内存里的结构体、长度、状态位，直接让服务解析出错崩溃，或者卡住无法响应合法客户端请求，这是最容易被触发的风险。
• 高概率的本地权限提升风险：这是比DoS严重得多的问题。你的服务运行在LOCAL SYSTEM权限，是Windows本机最高权限上下文，低权限攻击者只要能找到一个服务端解析共享内存数据的逻辑缺陷，直接就能拿到系统权限。哪怕你没有存原生指针，这类缺陷也非常常见：
  • 如果你在共享内存里存了消息长度字段，服务端按这个长度做内存拷贝，攻击者把长度改得远大于目标缓冲区大小，就会触发栈/堆缓冲区溢出，直接可以构造利用链执行任意代码
  • 如果你用offset_ptr指向共享内存内的消息体、结构体，攻击者篡改偏移值让指针指向共享内存内的伪造数据，会触发类型混淆，让服务把攻击者构造的恶意数据当成合法结构体解析，一样能造成内存破坏
  • 如果共享内存里存了文件路径、DLL加载路径、命令参数、注册表键这类内容，服务端读取后直接调用对应API执行操作（比如LoadLibrary、CreateProcess、RegSetValueEx），攻击者根本不需要挖内存破坏漏洞，直接把路径改成自己控制的恶意程序路径，就能让SYSTEM权限的服务执行恶意代码，瞬间完成权限提升
• 敏感信息泄露风险：因为所有用户都有GENERIC_READ权限，共享内存里存储的任何敏感内容——比如服务缓存的用户凭证、进程间通信传递的隐私数据、内部使用的密钥——所有低权限进程都能直接读取，没有任何访问边界。
• 通信欺骗风险：攻击者可以随意篡改客户端发往服务的请求内容，也能篡改服务返回给客户端的响应，既可以冒充合法客户端给服务发高权限操作指令，也可以冒充服务给客户端下发恶意内容，你当前的实现完全没有校验数据来源和完整性的能力。

安全加固方案 #

• 第一优先级：收紧共享内存访问控制：立刻停止给所有用户开放全量读写权限。Windows创建内存映射文件时可以自定义安全描述符，你可以构造SECURITY_ATTRIBUTES结构，只给确实需要访问的用户/用户组授予最小必要权限：如果客户端只需要读取服务下发的消息，就不要给写权限；如果客户端需要提交请求，只授予FILE_MAP_READ、FILE_MAP_WRITE对应的最小访问权，完全拒绝无关用户的访问请求。boost::interprocess支持在创建共享内存时传入自定义的权限配置，不要用默认的宽松权限配置。
• 永远不要信任共享内存内的任何数据，哪怕做了权限控制也要做全链路合法性校验：
  • 所有长度字段必须做边界检查，数值不能超过预定义的最大值，也不能超过对应接收缓冲区的实际大小
  • 所有offset_ptr必须做范围校验，确保指向的地址完全落在共享内存的合法地址区间内，偏移符合结构体对齐要求，不能指向共享内存外的任意地址
  • 所有命令码、枚举值、配置项必须走白名单校验，不在白名单内的非法值直接丢弃，不要做默认兼容处理
  • 所有从共享内存读取的字符串、路径、参数，在传入系统API执行敏感操作前必须做严格校验：比如路径要检查是否存在跨目录遍历字符、是否落在允许的目录范围内，命令参数要做特殊字符转义，绝对不要直接把共享内存读出的内容拼接到命令行、DLL加载路径、文件操作路径中直接使用
• 增加消息完整性校验：每个写入共享内存的消息块都附加HMAC消息认证码，密钥不要硬编码在程序里，可以由服务端在合法客户端启动时，通过权限严格受控的命名管道/ALPC通道给对应客户端进程下发临时会话密钥，收到消息后先校验MAC，校验不通过直接丢弃，防止数据被第三方篡改。
• 不要在共享内存里存放任何敏感数据，如果必须传递敏感内容，先做对称加密再写入共享内存。
• 优化IPC通信模型：如果业务场景允许，建议把通信模型改成共享内存只用来做服务端向客户端下发只读的公开数据，客户端发请求的通道改用权限控制粒度更细的命名管道或者ALPC端口——这两种IPC机制原生支持获取调用方的进程PID、用户SID，可以针对每个客户端做细粒度的权限校验，比共享内存的访问控制能力强很多。

你提到的用offset_ptr替代原生指针的做法，确实防御了直接篡改指针实现任意地址写的最原始利用方式，但这完全不能替代访问控制和输入校验，只要高权限服务会解析低权限用户可控的数据，就必须按照不可信输入的标准做全链路防护。

内容的提问来源于stack exchange，提问作者Aaron