Security: install stale-sweep executes candidate binaries from user-writable dirs #274
Labels
No labels
breaking
bug
documentation
enhancement
epic
good first issue
help wanted
refactoring
resolution/duplicate
resolution/invalid
resolution/wontfix
security
severity/critical
severity/high
severity/low
severity/medium
status/abandoned
status/blocked
status/needs-decision
status/needs-info
status/needs-verification
testing
upstream
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
sixfold-space/madtea#274
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The
madtea installstale-copy sweep probes each candidate's version by executing it:getInstalledVersionrunsexec.Command(candidate, "--version")(internal/cmd/install/install.go:942). The candidate directory list includes user-writable locations -~/.local/binand$GOBIN/$GOPATH/bin(staleCandidates,internal/cmd/install/install.go:754-761).So
madtea installexecutes any binary namedmadtea/mad-teafound in those dirs. Scenario: a local attacker or a malicious package drops a trojanmadteainto~/.local/binor$GOPATH/bin; the nextmadtea installruns it.Severity: low. It runs as the invoking user before any sudo elevation, and anyone who can write those dirs already controls an early-PATH
madteabinary - so the marginal escalation is small. Worth hardening anyway.Fix: skip the
--versionprobe for candidates located in user-writable dirs, or stat-and-check-owner before executing (only probe root-owned / trusted-dir candidates).Acceptance: the sweep no longer executes a
madteabinary from a user-writable directory to determine its version; a test covers the skip.