本文探讨python `exec()`函数在尝试构建受控执行环境时面临的安全挑战。通过一个示例函数，我们展示了即使在严格限制全局变量和内置函数的情况下，执行代码仍能直接访问并修改外部闭包变量。这揭示了`exec()`固有的不安全性，强调了在生产环境中避免执行不可信代码的重要性，并详细分析了绕过变量保护的机制。
引言：exec()与受控执行环境的尝试
Python的exec()函数允许动态执行字符串形式的Python代码，这在某些场景下提供了极大的灵活性。然而，这种灵活性也带来了潜在的安全风险，尤其是在执行不可信代码时。为了解决这一问题，开发者有时会尝试构建“沙箱”环境，以限制被执行代码的能力。
考虑以下controlled_exec函数，它旨在提供一个受控的代码执行API。其设计目标是：
- 隔离执行环境，移除所有全局变量和内置函数。
- 仅暴露一个名为increment_x的函数，该函数用于递增一个内部变量x。
- 通过返回x的值，期望能够统计increment_x的调用次数。
def controlled_exec(code):
x = 0
def increment_x():
nonlocal x
x += 1
# 尝试移除所有全局变量和内置函数
globals = {"__builtins__": {}}
# 仅暴露 increment_x 函数
locals = {"increment_x": increment_x}
exec(code, globals, locals)
return x
# 预期行为示例
# print(controlled_exec("""\
# increment_x()
# increment_x()
# """)) # 应该返回 2这个设计看起来似乎能有效限制被执行代码的行为，使其只能通过increment_x()间接影响x的值。然而，Python的动态特性使得这种沙箱机制远比想象中脆弱。
突破沙箱：直接操纵闭包变量
尽管controlled_exec函数试图通过限制globals和locals来隔离执行代码，但它无法阻止被执行代码直接访问和修改闭包（closure）中的变量。increment_x是一个嵌套函数，它通过nonlocal x声明来引用外部函数controlled_exec中的x变量。在Python中，这种非局部变量是通过“cell”对象实现的，这些cell对象存储在闭包的__closure__属性中。
立即学习“Python免费学习笔记（深入）”；
攻击者可以利用这一特性，直接访问increment_x函数的__closure__属性，进而修改其内部的cell对象内容，从而绕过increment_x函数本身，直接修改x的值。
以下代码演示了如何实现这一攻击：
def controlled_exec(code):
x = 0
def increment_x():
nonlocal x
x += 1
print(f"当前 x 的值: {x}") # 添加打印以便观察
globals = {"__builtins__": {}}
locals = {"increment_x": increment_x}
exec(code, globals, locals)
return x
# 攻击示例：在执行代码中直接修改 x
print("--- 执行攻击代码 ---")
result = controlled_exec("""\
increment_x() # x 变为 1
# 直接访问闭包，修改 x 的值
increment_x.__closure__[0].cell_contents = -100
increment_x() # x 从 -100 变为 -99
""")
print(f"最终 x 的值: {result}")
# 预期输出：
# 当前 x 的值: 1
# 当前 x 的值: -99
# 最终 x 的值: -99原理分析：
- increment_x是一个内部函数，它捕获了外部函数controlled_exec的局部变量x。
- 在Python中，当一个内部函数引用外部函数的非局部变量时，这些变量会被封装在一个cell对象中。
- 这个cell对象可以通过内部函数的__closure__属性访问。__closure__是一个元组，包含所有捕获的cell对象。
- 在本例中，increment_x.__closure__[0]就是包含x变量的那个cell对象。
- cell对象有一个cell_contents属性，可以直接读写其封装的值。
通过这种方式，被执行的代码完全绕过了increment_x的逻辑，直接操纵了x变量，将其设置为任意值（例如-100）。
exec()的固有不安全性与沙箱的局限
上述的变量操纵只是exec()固有不安全性的一个温和示例。事实上，无论你如何尝试限制exec()的执行环境，它都极难被真正地“沙箱化”。被执行的任意Python代码拥有与编写它的代码相同的访问和修改Python解释器状态的能力。
即使你尝试从globals中移除__builtins__，攻击者仍然有办法重新获取它们。例如，通过已暴露的increment_x函数，可以访问其__globals__属性，进而找到原始的__builtins__：
# 攻击者在 exec() 中可以执行的代码片段
# 重新获取内置函数
original_builtins = increment_x.__globals__['__builtins__']
# 现在可以使用任何内置函数，例如 open()
# file = original_builtins['open']('/etc/passwd', 'r')
# print(file.read())这仅仅是数十种潜在利用方式中的一种。exec()函数的设计初衷并非用于执行不可信代码，因此不提供任何内建的安全机制来限制其能力。
更严重的后果： 能够修改一个整数变量x只是冰山一角。被传递给controlled_exec的代码可以执行远比这更具破坏性的操作，例如：
- 文件系统操作： 删除、修改、读取任何文件（如果Python进程有相应权限）。
- 网络通信： 下载恶意软件、向外部服务器发送敏感数据。
- 系统命令执行： 调用os.system()或subprocess模块执行任意操作系统命令。
- 内存篡改： 访问和修改其他对象的内部状态。
总结与注意事项
通过上述分析，我们可以得出以下结论：
- exec()是高度危险的： 永远不要使用exec()来执行来自不可信来源的Python代码。它无法被有效沙箱化，即使是看似严格的限制也容易被绕过。
- 闭包的内部机制： Python的闭包通过cell对象实现非局部变量的共享，这些cell对象可以直接通过函数的__closure__属性访问和修改。这是Python语言设计的一部分，而非缺陷。
- 沙箱的复杂性： 构建一个真正安全的Python沙箱是一个极其复杂且几乎不可能完成的任务。因为它需要限制Python解释器本身的能力，这通常需要修改解释器核心或使用更高级的虚拟化技术。
建议：
-
避免使用exec()： 在处理用户输入或外部代码时，应优先考虑使用更安全的替代方案，例如：
- 配置解析器： 如果只是需要配置，使用json、yaml、ini等格式。
- 模板引擎： 如果是生成内容，使用Jinja2等模板引擎。
- 有限的DSL（领域特定语言）： 设计一个非常有限的自定义语言，并通过解释器安全地执行。
- 权限最小化： 如果确实需要执行动态代码（例如在受控的开发环境中），确保运行Python进程的用户拥有最小化的系统权限。
- 考虑第三方沙箱库： 某些第三方库（如RestrictedPython）尝试提供更安全的exec()环境，但它们通常也有自己的限制和潜在漏洞，并且不能提供绝对的安全保证。
总之，对于任何涉及执行不可信代码的场景，exec()都应被视为一个巨大的安全隐患。理解其工作原理和限制，是编写安全、健壮Python应用程序的关键。
