Bug 16140 - PSO apply and unapply commands use unescaped account names in LDAP filters before mutating msDS-PSOAppliesTo
Summary: PSO apply and unapply commands use unescaped account names in LDAP filters be...
Status: NEW
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: Python (show other bugs)
Version: unspecified
Hardware: All All
: P5 normal (vote)
Target Milestone: ---
Assignee: Douglas Bagnall
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2026-06-15 01:34 UTC by Douglas Bagnall
Modified: 2026-09-10 08:47 UTC (History)
0 users

See Also:


Attachments
patch for master (2.08 KB, patch)
2026-07-16 03:46 UTC, Douglas Bagnall
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Douglas Bagnall 2026-06-15 01:34:28 UTC
Tridge writes:

A delegated PSO tooling caller can inject LDAP filter syntax into user_or_group, influence the first sAMAccountName search result, and make the tool link or unlink the PSO to an unintended DN.

- python/samba/netcmd/pso.py:680-695 accepts user_or_group and builds search_filter = "(sAMAccountName=%s)" % user_or_group.
- python/samba/netcmd/pso.py:701-709 adds res[0].dn to msDS-PSOAppliesTo.
- python/samba/netcmd/pso.py:740-755 repeats the unescaped lookup in unapply.
- python/samba/netcmd/pso.py:761-769 deletes res[0].dn from msDS-PSOAppliesTo.

Remaining uncertainty: No LDAP runtime proof was run. Practical abuse is bounded by the credentials used to run samba-tool and PSO modification ACLs; an unrestricted administrator can already target arbitrary accounts by exact name.

#### Dataflow

Attacker role: samba-tool PSO apply/unapply caller, delegated operator, or automation input source controlling the user_or_group argument while the command runs with credentials that can modify the PSO.

Entrypoint: cmd_domain_pwdsettings_pso_apply.run() and cmd_domain_pwdsettings_pso_unapply.run() accept positional user_or_group input.

Trust boundary: Management CLI or wrapper input crosses into an LDAP search whose first result controls a mutating msDS-PSOAppliesTo update.

Controls and counterevidence:
- check_pso_valid() verifies the selected PSO exists and is accessible.
- LDAP ACLs gate the final samdb.modify() operation.
- An unrestricted administrator can already choose arbitrary exact targets.
- The account value is not escaped with ldb.binary_encode() before filter construction.

Exploit steps:
1. Supply LDAP filter metacharacters in the user_or_group argument to a PSO apply or unapply operation.
2. The command builds (sAMAccountName=%s) directly from the argument and performs a subtree search.
3. The first returned DN is selected as target_dn.

Attacker outcome: A delegated PSO tooling caller can inject LDAP filter syntax into user_or_group, influence the first sAMAccountName search result, and make the tool link or unlink the PSO to an unintended DN.

#### Severity

Final severity is **low**. This is a real control gap with constrained impact, narrow deployment exposure, or incomplete proof of security consequence.

Counterevidence: The mutation is ACL-bound and requires credentials allowed to modify the PSO; fully privileged administrators can intentionally target arbitrary objects without injection.


#### Remediation

Escape user_or_group with ldb.binary_encode() or perform an exact, parameter-safe lookup before mutating msDS-PSOAppliesTo. Add regression coverage that exercises the attacker-controlled input at the listed entry point and asserts the validation, authorization, containment, or size check occurs before the dangerous sink.


| Severity | low |
| Confidence | medium |
Comment 1 Douglas Bagnall 2026-07-16 03:46:53 UTC
Created attachment 19112 [details]
patch for master
Comment 2 Andrew Bartlett 2026-08-08 09:07:57 UTC
Our command-line tools are not built to be a security boundary, there must be so many other ways they could be abused even if wrapped very carefully under sudoers rules.  

I don't think we should treat this as a security bug.
Comment 3 Andrew Bartlett 2026-09-10 08:47:39 UTC
Removing embargo so patch can be put into a public MR.  

Our command line tools are run locally by privileged users, this is not a security boundary, anyone executing this via (eg) sudo should have a strong regular expression on the command line options.