GHSA-39g5-644c-qwcg

#### Product Name: container Github Link: https://github.com/apple/container Version: <= 0.12.2 #### Summary The `container system dns create --localhost` command accepts a `domainName` argument and passes it unsanitized into the pf anchor file (`/etc/pf.anchors/com.apple.container`) as a comment in a rule line. A domain name containing a newline character breaks out of the comment context and injects an arbitrary pf rule into the anchor file. When `pfctl -f` subsequently loads the configuration, the attacker-controlled rule is loaded into the macOS kernel packet filter. A `isValidDomainName()` function exists in `Parser.swift:892` but is **never called** from `DNSCreate`. **The core harm caused by this vulnerability is the bypassing of sudo privileges. An administrator may have only granted a user or an automation tool such as CI/CD the ability to execute `container system dns create` with root privileges, expecting that the user or automation tool could only add redirects from other IPs to localhost in the firewall rules file via `--localhost`. However, an attacker can exploit this vulnerability to write arbitrary rules into the firewall rules file: the target address is no longer restricted to localhost, and the rules are no longer limited to redirects.** #### Impact **What a legitimate invocation can write** `--localhost` is an optional parameter. Its presence or absence determines whether any pf rule is written at all: - **Without `--localhost`**: only a resolver config file is written; no pf rule is produced. - **With `--localhost <IP>`**: exactly one rule is written to the pf anchor file: ``` rdr inet from any to <IP> -> 127.0.0.1 # <domain> ``` The redirect destination is hard-coded to `127.0.0.1`. The rule type is always `rdr inet`. There is no legitimate way to produce a rule that redirects traffic to any IP other than `127.0.0.1`, nor to produce `pass`, `block`, or `nat` rules, through normal command usage. **What injection additionally en