哪个函数不能导致远程命令执行漏洞

printf。个函这玩意儿要是致远能直接RCE，那全世界写C语言教材的程命都得连夜改稿。你想想，令执printf("hello world")，行漏除了往屏幕上吐几个字符，个函它能干嘛？致远它连个系统调用都懒得碰，更别说execve了。程命远程命令执行漏洞的令执核心是——用户输入的东西被当成代码或者命令给执行了。而printf只负责格式化输出，行漏参数里的个函%s、%d就是致远占位符，它不会把字符串解析成命令。程命除非你硬要抬杠说“格式化字符串漏洞可以读写内存”，令执那确实，行漏printf(user_input)这种写法能泄露栈数据甚至写内存。但那是内存破坏漏洞，不是远程命令执行。RCE的门槛是攻击者能让你服务器跑rm -rf /或者下载个木马。格式化字符串漏洞顶多让你读点敏感信息或者崩溃进程，想稳定执行任意命令？差着十万八千里。

有人可能不服气：那system呢？system当然能RCE，这是常识。popen、exec家族、shell_exec、passthru，这些名字一听就是干脏活的。但你要问“哪个函数不能”，答案得从反面找。我见过一些刚入行的兄弟，一提到RCE就紧张兮兮，觉得所有跟字符串处理沾边的函数都有嫌疑。比如strlen，它返回字符串长度，能执行命令？除非你编译器被下了蛊。再比如strcpy，缓冲区溢出倒是常客，可溢出之后要构造ROP链才能RCE，那是利用链的事，不是strcpy本身“导致”的。函数本身没有执行命令的语义，漏洞是程序员用错了地方。

说个具体案例。几年前审过一个PHP项目，里面有个功能是“导出日志”。代码大概长这样：

$file = $_GET['log']; $content = file_get_contents('/var/log/' . $file); echo $content;

有人看到file_get_contents就喊“任意文件读取”。对，但这能RCE吗？如果$file是../../../../etc/passwd，读到了密码文件，然后呢？你得有地方写文件、或者配合其他漏洞。单靠file_get_contents，它只读不写，更不执行。file_get_contents不能导致RCE——除非你读的是/proc/self/environ然后往里面塞了代码，那又是另一条利用链了。函数本身只是工具，不是凶器。

再往深了想，到底怎么判断一个函数能不能导致RCE？标准很简单：这个函数有没有能力把外部输入转化为系统命令或者可执行代码。有，就是危险函数；没有，就是安全函数。eval、assert（老版本PHP）、include（配合伪协议）、create_function，这些是语言层面的代码执行入口。system、exec、shell_exec、passthru、popen、proc_open，这些是系统命令执行入口。还有call_user_func这种间接调用的，如果回调函数可控，也能RCE。但htmlspecialchars呢？它把特殊字符转义成HTML实体，输出到页面上防XSS。它能RCE？除非你把转义后的字符串又拿去eval了，那是你代码逻辑有问题，关htmlspecialchars什么事。

我自己的经验是，很多开发者把“危险”和“漏洞”混为一谈。mysql_query危险吗？拼接SQL会导致注入，但注入能RCE吗？得看数据库权限和配置，比如INTO OUTFILE写WebShell，或者sys_exec（需要UDF提权）。但mysql_query本身不执行系统命令。它只是把SQL发给数据库。数据库返回结果。就这么简单。你不能说mysql_query能导致RCE，那太抬举它了。

所以回到标题：哪个函数不能导致远程命令执行漏洞？严格来说，任何不涉及命令执行或代码执行语义的函数都不能。printf、strlen、strcpy、file_get_contents、htmlspecialchars、json_encode、md5、sha1……这些函数本身没有执行命令的能力。它们可能参与漏洞利用链，比如strcpy导致溢出然后劫持控制流，但那是利用方式，不是函数的设计目的。printf更典型，格式化字符串漏洞能读写内存，但想RCE？你得先找到能写GOT表或者返回地址的写操作，那又是另一回事了。函数只是砖头，漏洞是房子塌了。你不能怪砖头。

最后说句实在的，与其纠结哪个函数不能RCE，不如盯紧那些能RCE的函数。输入过滤、参数化查询、最小权限原则，这些才是正经事。printf不会害你，害你的是把用户输入直接当格式字符串用的那个程序员。