fix(security): stop curl_command from carrying the bearer token across a redirect

[carlosmmatos-cs]

Fixes #523.

curl_command() in the four bash scripts passed -L, so a redirect was followed with the OAuth bearer token still sitting on curl's configuration input. curl fixed the cross-host case in 7.58.0 as CVE-2018-1000007, which leaves roughly 7.30 through 7.57 exposed.

I measured every endpoint curl_command touches against the live API. All of them answer in a single hop on the correct region — including sensors/entities/download-installer/v3, which I had assumed redirected to a CDN, and the registry tags list on registry.crowdstrike.com. So on a correct-region run -L never fired at all.

The one case where it did something was a wrong region, because the API answers a wrong region with a 308 to the right one. That path never actually worked on a curl that strips the header, which is every version anyone still runs: on both curl 7.29.0 and 8.5.0 the redirect was followed, the header was dropped, the call came back 401, and the run died with a misleading No sensor found for OS: Ubuntu, Version: 24. The only curl versions where -L produced a working request are the same ones that leak the token.

So -L is gone, and --proto-redir with it, keeping the convention from #520/#521 that --proto-redir only appears next to -L. In its place curl_command reads x-cs-region off the un-followed redirect and re-issues against that region, resolved through cs_cloud(). The retry host therefore always comes from a closed allowlist and never from Location, which is the part an attacker would control. This is the same shape as the OAuth token retry in #521, and it means region correction now covers every request carrying the token rather than only the ones made after get_oauth_token had corrected the cloud. That matters for FALCON_ACCESS_TOKEN: there is no token POST on that path, so there is no x-cs-region to read up front, and on main every API call went to the wrong region and failed.

There is no way to discover the region up front without picking a scope. The 308 only comes back on a real routable path — an unknown path answers 404 with no x-cs-region — and it is emitted after authentication, so an unauthenticated probe just gets 401. Riding on the caller's own request avoids assuming any particular scope, and costs nothing when the region is already right.

Two details worth flagging in review. The body is buffered to a temp file because the redirect body is 107 bytes rather than empty, so letting it through would corrupt the value the caller captures; that is safe for the -o callers because curl writes their file itself and stdout stays empty. And the status is taken from the last HTTP/ line in the dump, because a proxy CONNECT writes one of its own first.

get_oauth_token also now adopts the hint when FALCON_CLOUD disagrees with it, instead of warning and then continuing to the wrong region. That is not needed for correctness any more, but it saves a redirect round trip on every subsequent call and it makes the existing warning mean something. falcon-container-sensor-pull.sh already did this; install, uninstall and migrate only warned.

Verified against the live tenant on curl 7.29.0 and 8.5.0, with client credentials and with FALCON_ACCESS_TOKEN, for us-1, us-2 and eu-1: GET, GET with -o, PATCH with a JSON body, and the query holding a literal | all reach the correct region, and the same wrong-region runs fail on main. The argument rewrite was checked separately under dash, bash and macOS sh. Exit codes are unchanged: an unresolvable proxy still yields 5 through the function, both under set +e and through a command substitution, so #526's call-site guards receive the real code. shfmt (-i 4 -ci, bash and posix) and shellcheck (bash and dash) are clean on all four files.

#522 also edits curl_command and needs rebasing against main before it goes in.