Protect Application Script Files from Tampering

Many macOS applications bundle interpreters and scripts within their app bundles. These embedded scripts often run with the application's privileges and code signing doesn't always validate them after installation. This creates an opportunity for attackers to modify these scripts to add malicious functionality.

A particularly concerning example is Python IDLE (the Python IDE included with macOS Python installations). As documented by Csaba Fitzl, you can modify IDLE's embedded Python scripts to inject malicious code:

sudo vi './Python 3.12/IDLE.app/Contents/Resources/idlemain.py'
# Add: os.system("osascript -e 'Tell application \"System Events\" to display dialog \"Backdoor\"'")

When IDLE launches, it executes the modified idlemain.py, running your injected code with the user's privileges. This bypasses code signing because the modified file is a resource, not part of the signed binary.

Similar vulnerabilities exist in:

• Applications with embedded Python scripts
• Apps with embedded Ruby scripts
• Applications using shell scripts in their Resources
• Electron apps with JavaScript files (covered separately in Day 1)
• Any app with interpreted code in its bundle

This is a form of "living off the land" attack - using legitimate applications as execution vehicles by modifying their supporting files.

The fix is to use file access rules to make these embedded script directories read-only, allowing only the owning application (and system update processes) to modify them.

This rule protects embedded scripts in application bundles from unauthorized modification. It's particularly important for:

• Developer tools (Python IDLE, Ruby tools)
• Applications with embedded interpreters
• System utilities that use scripts
• Any app with script-based plugins

Deployment considerations:

1. This rule may be too broad if many applications need to modify their own scripts
2. Consider targeting specific high-value applications instead of all apps
3. Allow application updaters and installers to modify their own scripts
4. System updates need write access (Apple installer and softwareupdated)

Recommended approach:

• Start with audit mode to understand which apps modify their scripts
• Add specific rules for high-value targets (Python, developer tools)
• Gradually expand coverage based on risk assessment

The comprehensive rule uses wildcards which may impact performance on systems with many applications. Consider targeting specific apps if this is a concern.

Legitimate scenarios where application scripts are modified:

• Application self-updates that modify resource files
• Plugin installation that adds scripts to app bundles
• Development tools that dynamically generate scripts
• User customization of scriptable applications

Specific applications to consider:

• Python IDLE: Usually doesn't self-modify, safe to protect
• MacVim: Users may customize configuration scripts
• Emacs: Highly customizable, users add scripts
• Other developer tools with plugin systems

Mitigation:

• Allow specific signing IDs for application updaters
• Exempt plugin managers by their signing ID
• Use Workshop tags to exempt developer machines
• Start in audit mode to identify legitimate patterns

1. Try to modify a Python IDLE script:

   sudo vi '/Applications/Python 3.12/IDLE.app/Contents/Resources/idlemain.py'
   # Try to save changes
   

   (should be blocked)

2. Verify the application still launches: open -a IDLE (should work normally)

3. Test that system updates can still modify (if using approved signing IDs): Install a Python update from python.org (should work)

4. Check that user scripts outside app bundles work:

   echo "print('test')" > ~/test.py
   python3 ~/test.py
   

   (should work)

Monitor FAA events for attempts to modify application script files. Focus on:

Suspicious patterns:

• Modifications from unexpected processes (text editors, shells)
• Changes to Python IDLE or other developer tools
• Modifications from user-launched processes (not installers)
• Bulk modifications to multiple app bundles

Investigation steps:

1. Identify which script was targeted
2. Determine what application owns the script
3. Check the process attempting modification
4. Review if this is part of software installation or malicious tampering
5. Examine the file contents if possible (may need backup/snapshot)

Legitimate modifications typically:

• Come from signed installers or updaters
• Target the application's own files
• Happen during known update windows
• Use expected update mechanisms