Document a sudoers caveat for madtea update in SECURITY.md (as-root arbitrary read via --apply) #269

New issue

Closed

opened 2026-07-19 03:34:10 +00:00 by hexajon · 0 comments

hexajon commented

2026-07-19 03:34:10 +00:00

(Migrated from codeberg.org)

madtea update --apply <path> --sha256 <hex> (internal/cmd/update/update.go around L538) reads an arbitrary path and writes attacker-chosen bytes to the resolved binary path if the sha256 matches the supplied hex. Under general sudo this is no escalation (the caller is already root). It only becomes an escalation under a NARROW NOPASSWD sudoers rule scoped to madtea update:

replace the binary -> code execution as whoever next runs it, and
a mismatch error surfaces the sha256 of a root-readable file (e.g. the got %s path in verify.go:58), leaking hashes of files like /etc/shadow.

gosec G304 (file inclusion) is intentionally excluded (gosec.sh:53) because CLI file-path args are by design, so SAST won't flag this. The privilege-split itself is sound - root never fetches or resolves credentials, and --apply re-verifies the staged sha256 fail-closed before the swap. The only gap is the deployment footgun.

Fix: add a one-line hardening caveat to SECURITY.md (or the install/update docs) warning operators NOT to whitelist madtea update in a NOPASSWD sudoers rule - the update flow already prompts for sudo interactively when it needs it, so a NOPASSWD carve-out is never required.

Acceptance: SECURITY.md (or update docs) carries the sudoers caveat.

`madtea update --apply <path> --sha256 <hex>` (`internal/cmd/update/update.go` around L538) reads an arbitrary path and writes attacker-chosen bytes to the resolved binary path if the sha256 matches the supplied hex. Under general `sudo` this is no escalation (the caller is already root). It only becomes an escalation under a NARROW `NOPASSWD` sudoers rule scoped to `madtea update`: - replace the binary -> code execution as whoever next runs it, and - a mismatch error surfaces the sha256 of a root-readable file (e.g. the `got %s` path in `verify.go:58`), leaking hashes of files like `/etc/shadow`. gosec `G304` (file inclusion) is intentionally excluded (`gosec.sh:53`) because CLI file-path args are by design, so SAST won't flag this. The privilege-split itself is sound - root never fetches or resolves credentials, and `--apply` re-verifies the staged sha256 fail-closed before the swap. The only gap is the deployment footgun. Fix: add a one-line hardening caveat to SECURITY.md (or the install/update docs) warning operators NOT to whitelist `madtea update` in a NOPASSWD sudoers rule - the update flow already prompts for sudo interactively when it needs it, so a NOPASSWD carve-out is never required. Acceptance: SECURITY.md (or update docs) carries the sudoers caveat.

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

sixfold-space/madtea#269

No description provided.

Rows
Columns