Private action arguments can be set by user input in Ash

Improperly Controlled Modification of Dynamically-Determined Object Attributes vulnerability in ash-project ash allows a user to set the value of a private action argument that is intended to be controlled only by trusted server-side code.

Action arguments declared with public?: false are meant to be set internally (for example via Ash.Changeset.set_private_argument/3) and must not be settable from end-user input. When a changeset is built from a parameter map, Ash filters out private arguments, but the filtering is incomplete.

In the regular changeset path (for_create, for_update, for_destroy), private arguments are stripped only when the parameter key is an atom. When the key is a binary (string), as is the case for user-supplied parameters, the private argument is kept and the user controls its value. In the atomic path (Ash.Changeset.fully_atomic_changeset/4, also reached through atomic and bulk updates), private arguments are not stripped at all, regardless of whether the key is an atom or a binary.

An attacker who can submit parameters to an action that defines a private argument can therefore inject a value for that argument. Depending on how the application uses the argument (for example an acting_user_id driving authorization or record ownership), this can lead to an integrity violation or privilege escalation.

This issue affects ash: from 3.0.0 before 3.29.3.

An action must declare a private argument (one defined with public?: false) whose value is meant to be set only by trusted server-side code, and the application must build the changeset from untrusted user-supplied parameters, passing them straight into Ash.Changeset.for_create/3, for_update/3, for_destroy/3, or into an atomic or bulk update.