kaxil commented on issue #74601:
URL: https://github.com/apache/airflow/issues/74601#issuecomment-6201334256
The quoting bug is real, and it bites even without an attacker: the export
lines end up inside the single-quoted `job_script` literal, so a value's own
opening quote closes it, and `{"INPUT_FILE": "two words"}` already fails with
`words: command not found`. I've opened #74810 to fix it, close to your
proposal (`shlex.quote` per value, then one more escape for the outer literal),
with a test that runs the real wrapper under bash.
We won't treat this as a vulnerability, though. The Dag in the repro hands
`dag_run.conf` to an operator without validating it, and the security model
puts that on the Dag author ([this
section](https://airflow.apache.org/docs/apache-airflow/stable/security/security_model.html#dag-author-code-passing-unsanitized-input-to-operators-and-hooks)).
The operator docs never say `environment` is safe for untrusted input, so the
documented-pattern exception doesn't apply. That's also why it's fine to handle
in public rather than via security@
([hardening](https://airflow.apache.org/docs/apache-airflow/stable/security/security_model.html#hardening-opportunities-with-no-demonstrated-exploitation-path)).
Heads-up for anyone relying on it: after the fix, values are passed
literally, so `{"PATH": "$PATH:/opt/tools/bin"}` (which only worked because of
this bug) has to move into `command`.
Windows isn't affected by the double splice since its child script is
base64-encoded. If you want to pursue the curly-quote case, #73352 is rewriting
that wrapper and would be the place.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
