Summary
Reachy Mini Wireless OS images before 0.2.4 included an overly broad sudoers rule that allowed the pollen daemon user to run systemctl as root without a password or argument restrictions. Any process already running as pollen could use this permission to escalate to full root access on the device without requiring another vulnerability or user interaction.
Affected context
The issue occurs in Reachy Mini Wireless Raspberry Pi OS images that include a sudoers entry for the pollen daemon user. Risk exists when an attacker, malicious process, or compromised component can execute code under that account and the sudo policy permits unrestricted passwordless execution of /usr/bin/systemctl.
Exploit preconditions
- Attack surface: Local command execution on the Reachy Mini Wireless device
- Required access: Ability to run a process as the
pollendaemon user - Trigger point: Invocation of the permitted system-management command through sudo
- Why exploitation is possible: The sudoers rule grants passwordless root execution without restricting subcommands or arguments, allowing the account to cross the intended privilege boundary
Why this happens
The underlying flaw is excessive privilege granted through an overly broad sudoers rule. A non-root service account was authorized to execute a powerful system-management utility as root without limiting the operations it could perform.
This maps primarily to CWE-269: Improper Privilege Management and is also consistent with CWE-250: Execution with Unnecessary Privileges, because the service account received more authority than required for its intended function.
Potential impact
- An attacker may obtain full root access on the robot
- System services and security controls could be modified or disabled
- Local data and credentials could be accessed or altered
- The device could be used to affect connected robotic, network, or cloud systems
- Persistence or additional malicious software could be installed
General mitigation guidance
Mitigation generally focuses on applying least privilege to service accounts and narrowly defining administrative command access.
Common defensive patterns include:
- Removing broad sudo permissions from daemon accounts where they are not essential
- Allowing only specific, non-ambiguous administrative operations rather than an unrestricted system-management binary
- Restricting permitted commands, subcommands, arguments, environment variables, and execution context
- Using dedicated narrowly scoped service interfaces instead of delegating general root-capable utilities
- Running the daemon with the minimum operating-system permissions and filesystem access required
- Reviewing image build policies to ensure privileged defaults are not inherited into production devices
- Monitoring and protecting sudoers files and related system configuration from unauthorized changes
How teams detect issues like this
Detection can combine image inspection, configuration review, and runtime monitoring:
- Search sudoers files and included policy fragments for daemon users granted passwordless access to powerful utilities
- Flag rules that permit unrestricted execution of system-management commands or omit command arguments
- Review service accounts for unnecessary membership in administrative groups or access to privileged helpers
- Use static analysis and image-scanning policies to identify excessive privilege grants during OS image builds
- Monitor sudo activity by service accounts and investigate unexpected administrative command execution
- Add code-review and CI checks requiring explicit justification for new privileged service permissions
