公开java.lang.Runtime.exec的安全风险及Native exe调用方案安全性问询

直接使用单字符串参数的Runtime.exec(String)存在以下核心安全风险：

• 命令注入攻击：若命令字符串包含用户可控内容，攻击者可通过插入分号、管道符（|）、重定向符（>/<）等shell元字符，拼接执行恶意命令。比如类Unix系统中输入app.exe; rm -rf /，会先执行目标程序再删除系统文件；Windows下用&/&&也能实现类似多命令执行。
• 参数解析歧义：该方法会将整个字符串交给系统shell解析，空格等分隔符可能被错误识别，导致程序执行不符合预期，同时给攻击者留下篡改参数、插入恶意指令的空间。
• 权限继承问题：子进程会继承当前Java进程的权限。如果Java程序以高权限（如Windows管理员、Linux root）运行，被注入的恶意命令也会拥有同等权限，可能造成系统级破坏。
• 环境变量篡改风险：攻击者可通过控制环境变量影响子进程执行逻辑，比如替换PATH让系统执行恶意替代程序。

你的方案虽做了基础校验，但仍存在大量未覆盖的安全风险，目前无法直接安全实施，具体风险点如下：

未覆盖的注入类风险 #

• Windows特殊字符绕过：仅检查空格无效，Windows cmd支持制表符（\t）、逗号（,）作为参数分隔符，还支持^转义特殊字符。攻击者可通过app.exe^&calc.exe这类构造，绕过检查同时执行目标程序和恶意命令。
• URL参数注入：将整个URL作为参数传递时，攻击者可在查询参数中插入cmd特殊字符。比如URL为https://xxx/app-one/legit.exe?param=^&del c:\*.*，拼接后命令会被解析为执行legit.exe后删除C盘文件。
• 文件名恶意构造：若parseNativeApplicationNameFromUrl未严格限制文件名，攻击者输入legit.exe;calc.exe这类文件名，路径校验通过后，cmd会将分号后的内容当作新命令执行。

权限与资源风险 #

• 子进程权限过高：若Web Servlet以高权限账户（如Windows LocalSystem）运行，Native exe会继承该权限，一旦exe被替换或存在漏洞，攻击者可直接获取系统级权限。
• 资源耗尽攻击：无并发进程限制和超时机制，攻击者可频繁发送请求创建大量子进程，耗尽系统CPU、内存，导致服务拒绝。

文件与路径相关风险 #

• exe文件被篡改：若C:\nativeApplicationsFolder目录权限设置不当，攻击者可替换合法exe为恶意程序，Web服务会直接执行恶意代码。
• 路径校验绕过：Windows下Path.startsWith可能被短路径（如C:\native~1\mal.exe）绕过，导致访问目标目录外的文件。

其他潜在风险 #

• 敏感信息泄露：fetchReply若未正确处理子进程的标准错误流，可能泄露系统路径、exe内部错误等敏感信息，辅助攻击者后续攻击。
• 非exe文件执行：未校验被调用文件是否为合法Native exe，攻击者可诱导服务执行.bat/.cmd等脚本文件，触发恶意逻辑。

方案改进建议 #

要实现安全实施，需做以下调整：

• 改用Runtime.exec(String[])重载方法：将exe路径作为数组第一个元素，参数作为后续元素，避免shell解析命令字符串，从根源上防止命令注入：

  String[] command = {nativeApplicationFile.toString(), url};
  Process p = Runtime.getRuntime().exec(command);
  

• 严格校验文件名：仅允许文件名包含字母、数字、下划线和点号，禁止任何特殊字符，并确保对应真实存在的exe文件。
• 限制子进程资源：添加并发进程数限制，给子进程设置超时时间，超时后强制销毁；通过Windows Job对象限制子进程的CPU、内存使用。
• 强化目录与文件权限：C:\nativeApplicationsFolder仅允许管理员写入，Web服务账户仅拥有读和执行权限；对每个exe文件添加数字签名校验，确保未被篡改。
• 完善输入校验：禁止URL中包含&, |, ^, >, <, %等Windows cmd特殊字符，对查询参数做严格白名单校验。
• 隔离执行环境：用Windows沙盒、Docker容器等技术隔离Native exe的执行环境，降低攻击影响范围。

综上，原方案存在较多安全漏洞，完成上述改进后，才可考虑安全实施。

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