[Security] Harden Calculator eval() environment to prevent code injection

[markknoffler]

Summary

This PR enhances the security of the Calculator tool by implementing a hardened eval() environment that prevents remote code execution vulnerabilities.

Problem

The current implementation uses eval(expression, _OPS) with a limited set of mathematical operations. However, this approach is vulnerable to code injection attacks (CWE-94) because the restricted namespace can still be bypassed through various Python introspection techniques. Even with a limited _OPS dictionary, an attacker could potentially access built-in functions through object introspection, method resolution order manipulation, or other Python internals, leading to arbitrary code execution.

The vulnerability exists because the second parameter to eval() only restricts the global namespace but doesn't completely isolate the execution environment. Python's dynamic nature allows access to dangerous built-ins through various indirect paths, making this a critical security concern for any system that processes untrusted mathematical expressions.

Solution

This PR implements a comprehensive security-hardened approach by explicitly setting __builtins__ to an empty dictionary, which blocks all built-in functions at their source. The solution includes several layers of defense:

The implementation creates a _safe_globals dictionary during initialization that contains only explicitly whitelisted mathematical functions from the math module and safe built-in operations. By setting '__builtins__': {}, the code prevents access to dangerous functions like __import__, exec, compile, and other potential attack vectors. The safe environment includes an expanded set of mathematical operations (trigonometric functions, logarithms, constants) while maintaining strict isolation from system-level functionality.

Testing

The calculator has been tested with various mathematical expressions including basic arithmetic, advanced functions, and malicious payloads attempting code injection. All legitimate mathematical operations function correctly while potentially dangerous expressions are safely rejected without executing arbitrary code.

References

Fixes #441

This fix addresses the eval() security vulnerability pattern documented in CWE-94 (Code Injection).

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.