禁用GITHUB_TOKEN权限并限制网络后，GitHub Actions执行用户代码是否安全？

一、禁用GITHUB_TOKEN权限后的剩余安全风险 #

即便完全禁用GITHUB_TOKEN的所有权限，直接运行用户从Issue提交的代码仍存在以下风险：

• 运行器资源滥用：攻击者可执行消耗CPU、内存、磁盘的代码（如无限循环、大文件填充），导致运行器崩溃，或占用平台资源影响其他工作流执行，甚至触发GitHub的资源限制政策。
• 本地恶意操作：虽然GitHub Actions运行器是临时隔离环境，但攻击者可执行破坏运行器本地环境的命令，如删除系统文件、篡改配置，导致工作流异常终止。
• 合规风险：若攻击者执行违反GitHub服务条款的代码（如挖矿、恶意脚本），仓库可能被平台封禁。
• 潜在漏洞利用：针对运行器系统的未公开漏洞，攻击者可尝试提权或绕过隔离限制，获取更多权限。

二、注入攻击的危害与首个工作流的安全性 #

你提供的第一个工作流完全不安全，属于典型的命令注入场景：

on: issues
jobs:
  test:
    permissions:
      contents: read
    timeout-minutes: 5
    runs-on: ubuntu-latest
    steps:
      - run: ${{ github.event.issue.body }}

攻击者只需在Issue正文中写入恶意命令（如rm -rf /tmp/* && 执行挖矿脚本），即可直接在运行器上执行，达成以下目的：

• 发起DDoS攻击：利用运行器的网络带宽攻击第三方目标，导致GitHub的IP地址被拉黑。
• 执行挖矿代码：占用运行器CPU资源进行加密货币挖矿，浪费平台资源。
• 窃取运行器本地临时数据：虽然运行器是临时的，但可能包含其他工作流遗留的敏感信息（如环境变量中的非授权数据）。

三、添加网络限制后的工作流安全性分析 #

第二个工作流通过防火墙规则限制了网络访问，安全性有所提升，但仍存在不可忽视的风险：

on: issues
jobs:
  test:
    permissions:
      contents: read
    timeout-minutes: 5
    runs-on: ${{ matrix.os }}
    strategy:
      matrix:
        os: [ubuntu-latest, windows-latest, macos-latest]
    steps:
      - name: Block outgoing traffic on Ubuntu
        if: runner.os == 'Linux'
        run: |
          sudo iptables -A OUTPUT -d 0.0.0.0/0 -j DROP
          sudo iptables -A OUTPUT -d 127.0.0.1 -j ACCEPT
      - name: Block outgoing traffic on Windows
        if: runner.os == 'Windows'
        run: |
          New-NetFirewallRule -DisplayName "Block All Outgoing Traffic" -Direction Outbound -Action Block -Enabled True
          New-NetFirewallRule -DisplayName "Allow Loopback Traffic" -Direction Outbound -Action Allow -RemoteAddress 127.0.0.1 -Enabled True
      - name: Block outgoing traffic on macOS
        if: runner.os == 'macOS'
        run: |
          sudo pfctl -E
          echo "block all" | sudo pfctl -f - 
          echo "pass on lo0" | sudo pfctl -f -
          sudo pfctl -sr
      - run: ${{ github.event.issue.body }}

潜在风险点： #

1. 网络规则配置疏漏：
   • Ubuntu的iptables仅阻断了IPv4流量，未处理IPv6，攻击者可通过IPv6地址绕过限制。同时-A是追加规则，若运行器预存允许外部访问的规则，会优先生效。
   • Windows防火墙新规则优先级可能低于系统默认允许规则，无法完全阻断所有出站流量。
   • macOS的pf规则存在逻辑问题：第二次pfctl -f -会覆盖第一次的规则，实际仅保留pass on lo0，但未明确允许IPv6回环流量，可能导致本地测试代码异常，同时仍可能存在规则绕过空间。
2. 本地资源滥用：攻击者仍可执行消耗CPU、内存、磁盘的代码，比如通过无限循环占用CPU，或生成大文件填充磁盘，导致运行器崩溃。
3. 沙箱绕过可能性：若运行器系统存在未修复的本地漏洞，攻击者可尝试提权或突破隔离，获取更多操作权限。

优化建议： #

• 避免直接执行用户提交的任意代码，改用沙箱化环境（如Docker容器、受限的代码执行沙箱）隔离运行。
• 对用户提交的代码进行静态扫描，过滤危险命令（如rm、curl、wget等）。
• 限制运行器的资源配额（如CPU核心数、内存上限、磁盘使用量），避免资源被恶意耗尽。
• 添加审核机制：仅允许信任用户提交的Issue触发工作流，或需维护者手动批准后再执行代码。

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