curl_command() follows redirects with the OAuth bearer token attached

[carlosmmatos-cs]

curl_command() in the four deployment scripts passes -L, so a redirect is followed with the OAuth bearer token still on curl's configuration input.

Whether the token actually crosses to the redirect target depends on the curl version. curl 7.58.0 fixed this as CVE-2018-1000007, so anything up to 7.57 is suspect. It is not uniform across older versions, though: measured against a local capture server in this repo's test harness, curl 7.29.0 does drop the raw Authorization header on a cross-host redirect, and 7.76.1 drops it too. A datapoint recorded earlier in this project has 7.51.0 keeping it. So the exposed band is roughly 7.30 through 7.57 — all end of life — with the 7.29.0 and 7.76.1 ends confirmed directly.

The exposure is limited to the bearer token, not the client secret. The secret only travels in the OAuth token POST body, and after #521 that call no longer follows redirects. Sensor downloads are also checked by verify_sha256, so a redirected download cannot quietly substitute a different file.

For contrast, the calls that no longer pass -L were measured end to end while #521 was being reviewed: on the --list-tags path every request answers 200 in a single hop, including the registry token request, so nothing on that path wanted a redirect. That was on registry.crowdstrike.com only — the gov registries were not reachable from the test environment.

Worth deciding whether to keep -L on curl_command() or handle the redirect explicitly, the way the OAuth path now does.

• bash/install/falcon-linux-install.sh — curl_command() at 707, verify_sha256 at 422
• bash/install/falcon-linux-uninstall.sh — curl_command() at 253
• bash/migrate/falcon-linux-migrate.sh — curl_command() at 229, verify_sha256 at 718
• bash/containers/falcon-container-sensor-pull/falcon-container-sensor-pull.sh — curl_command() at 287