Summary
Froxlor contains a newline injection vulnerability in the additional_members parameter of the Ftps.add API. An authenticated customer may inject forged group entries that are later written by a privileged cron job, potentially enabling local privilege escalation.
Froxlor contains a newline injection vulnerability in the additional_members parameter of the Ftps.add API. An authenticated customer may inject forged group entries that are later written by a privileged cron job, potentially enabling local privilege escalation.
Affected context
The issue may affect Froxlor installations where:
- Authenticated customers can submit values through the
Ftps.addAPI - The
additional_membersparameter is accepted without strict validation - The
REBUILD_NSSUSERScron process consumes the resulting data - The cron process writes to a root-owned NSS group database
Risk depends on the deployment's customer permissions, filesystem controls, and group-management configuration.
The issue may affect Froxlor installations where:
- Authenticated customers can submit values through the
Ftps.addAPI - The
additional_membersparameter is accepted without strict validation - The
REBUILD_NSSUSERScron process consumes the resulting data - The cron process writes to a root-owned NSS group database
Risk depends on the deployment's customer permissions, filesystem controls, and group-management configuration.
Exploit preconditions
- Attack surface: Authenticated Froxlor API access
- Required access: A customer account permitted to invoke the affected
Ftps.addoperation - Trigger point: Processing of the
additional_membersvalue by the NSS user/group rebuild workflow - Why exploitation is possible: Newline characters are accepted as data and later interpreted as record separators when written to a privileged group database
- Attack surface: Authenticated Froxlor API access
- Required access: A customer account permitted to invoke the affected
Ftps.addoperation - Trigger point: Processing of the
additional_membersvalue by the NSS user/group rebuild workflow - Why exploitation is possible: Newline characters are accepted as data and later interpreted as record separators when written to a privileged group database
Why this happens
The underlying bug is improper neutralization of control characters in a value that is later serialized into a line-oriented system database. The application accepts newline characters in additional_members without enforcing an appropriate field format, allowing attacker-controlled input to create additional records when consumed by REBUILD_NSSUSERS.
This behavior maps to CWE-74: Improper Neutralization of Special Elements in Output Used by a Downstream Component, because input that is valid at the API boundary is unsafe in the downstream NSS group-file format.
The underlying bug is improper neutralization of control characters in a value that is later serialized into a line-oriented system database. The application accepts newline characters in additional_members without enforcing an appropriate field format, allowing attacker-controlled input to create additional records when consumed by REBUILD_NSSUSERS.
This behavior maps to CWE-74: Improper Neutralization of Special Elements in Output Used by a Downstream Component, because input that is valid at the API boundary is unsafe in the downstream NSS group-file format.
Potential impact
- An attacker could create unauthorized group entries
- Local privilege escalation may occur if forged groups grant access to privileged resources
- System account and group-management integrity could be compromised
- The affected host may be used as a foothold for further local compromise
- Security monitoring and authorization decisions could be bypassed or altered
- An attacker could create unauthorized group entries
- Local privilege escalation may occur if forged groups grant access to privileged resources
- System account and group-management integrity could be compromised
- The affected host may be used as a foothold for further local compromise
- Security monitoring and authorization decisions could be bypassed or altered
General mitigation guidance
Mitigation generally focuses on validating structured membership data before it reaches system-facing files.
Common defensive patterns include:
- Allowing only the documented character set and member format for group names
- Rejecting control characters, including newline and carriage-return characters
- Treating each member as a structured value rather than concatenated text
- Encoding or safely serializing data according to the target file format
- Applying validation both at the API boundary and immediately before privileged file generation
- Running rebuild processes with the minimum filesystem and operating-system privileges required
- Protecting generated NSS files with restrictive ownership, permissions, and monitoring
Mitigation generally focuses on validating structured membership data before it reaches system-facing files.
Common defensive patterns include:
- Allowing only the documented character set and member format for group names
- Rejecting control characters, including newline and carriage-return characters
- Treating each member as a structured value rather than concatenated text
- Encoding or safely serializing data according to the target file format
- Applying validation both at the API boundary and immediately before privileged file generation
- Running rebuild processes with the minimum filesystem and operating-system privileges required
- Protecting generated NSS files with restrictive ownership, permissions, and monitoring
How teams detect issues like this
Detection approaches may include:
- Static analysis rules for unvalidated user input written to line-oriented system files
- Code review checks for string concatenation involving newline-sensitive formats
- Tests that submit control characters and verify rejection or safe encoding
- Monitoring for unexpected modifications to
/var/lib/extrausers/group - Auditing API activity and cron-generated changes to NSS account databases
- Policy enforcement requiring allowlists and canonical serializers for privileged configuration files
Automated application-security and code-review tools may help identify tainted data flows from API parameters into privileged file-generation routines.
Detection approaches may include:
- Static analysis rules for unvalidated user input written to line-oriented system files
- Code review checks for string concatenation involving newline-sensitive formats
- Tests that submit control characters and verify rejection or safe encoding
- Monitoring for unexpected modifications to
/var/lib/extrausers/group - Auditing API activity and cron-generated changes to NSS account databases
- Policy enforcement requiring allowlists and canonical serializers for privileged configuration files
Automated application-security and code-review tools may help identify tainted data flows from API parameters into privileged file-generation routines.
