GHSA-7pjr-qpvh-m339 Fission builder accepts arbitrary buildcmd strings from Environment.spec.builder.command, allowing the builder pod to invoke arbitrary executables

• Go github.com/fission/fission: < 1.23.0 → fixed in 1.23.0

Summary Before the round-1 security sweep, `pkg/builder/builder.go` passed `Environment.spec.builder.command` directly into `exec.Command(...)` after a `strings.Fields` split, with no validation of the executable path or its arguments. A user who could create or update `Environment` CRDs in a namespace observed by the buildermgr could thereby point the builder pod at any executable inside the builder image (e.g. `/bin/sh -c '...'`) and execute arbitrary code in the builder pod context. Affected component • `pkg/builder/builder.go:254` — call site (`exec.Command(buildCmd, buildArgs...)`). • `pkg/builder/builder.go:106` — input source: `buildCmd, buildArgs = strings.Fields(req.BuildCommand)[0], strings.Fields(req.BuildCommand)[1:]`. Impact A subject with `create` / `update` privilege on `Environment` objects could: 1. Cause the builder pod for any package using that environment to execute arbitrary code. 2. Read whatever files the builder pod has access to inside its `/packages` shared volume (deployment archive payloads for that package). 3. Write arbitrary content into the `/packages` shared volume, which the fetcher subsequently uploads as the package deployment archive. The builder pod runs in the user's namespace with the `fission-builder` SA (not the more-privileged executor SA), so the impact is bounded to that namespace's package contents and the builder pod's own filesystem. `PR:H` reflects that creating / modifying `Environment` CRDs is typically restricted to cluster admins or platform operators. Root cause `pkg/builder/builder.go`'s build-command parser did not validate the resulting executable path. Although `exec.Command` does not invoke a shell, it does locate the executable via `$PATH`, and `strings.Fields` splitting allowed multiple flags / sub-arguments to be passed. Fix Released in v1.23.0: • PR #3364 (commit `0f45c911`) introduces `Builder.resolveBuildCommand` in `pkg/builder/builder.go`, which: 1. Accepts an empty string (treated as the default `/build`). 2. Accepts the literal `/build`. 3. Accepts any absolute path that survives `filepath.Clean` and contains no `..` segments. 4. Rejects anything containing whitespace metacharacters or relative paths. • `exec.Command` still receives only the validated absolute path; sub-arguments continue to come from `strings.Fields` of the original string but are now passed positionally with no shell expansion. Mitigation (until upgrade) 1. Restrict who can create / update `Environment` CRDs to trusted operators only. 2. Audit `Environment.spec.builder.command` values for any non-`/build` paths. 3. Run the buildermgr with a tightened ServiceAccount that has no secret access in the builder namespace.