Bug 40041 - no escaping of DN when composing DN for newly created objects
no escaping of DN when composing DN for newly created objects
Product: UCS
Classification: Unclassified
Component: UDM (Generic)
UCS 4.1
Other Linux
: P5 normal (vote)
: UCS 4.1-2-errata
Assigned To: Florian Best
Philipp Hahn
: 17848 32317 34749 41032 41235 (view as bug list)
Depends on:
  Show dependency treegraph
Reported: 2015-11-19 17:33 CET by Florian Best
Modified: 2016-09-21 18:10 CEST (History)
4 users (show)

See Also:
What kind of report is it?: Security Issue
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional): Cleanup, Security, Troubleshooting
Max CVSS v3 score:
best: Patch_Available+

patch (113.62 KB, patch)
2015-11-19 17:33 CET, Florian Best
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Florian Best univentionstaff 2015-11-19 17:33:18 CET
Created attachment 7314 [details]

All handlers aren't sanitizing the values. Users can enter e.g. "foo,cn=bar" (resulting that the objects gets created in the subcontainer bar) or "foo+bar" (resulting in LDAP errors).
Most handlers are protected by their syntax classes which doesn't allow e.g. '+' in their name but not all. At least mail/*.py and container/cn.py is broken.

All handlers are infected if one sets the syntaxclass to "string".

sed -i "s/self.dn='/self.dn = '/g; /self.dn = / s/mapping.mapValue([^)]*)/ldap.dn.escape_dn_chars(\0)/; s/^# <http:\/\/www.gnu.org\/licenses\/>.$/\0\n\nimport ldap/" $(rgrep -l 'self.dn\s*=' )

Plus the changes in the handlers:

Everything together in the attached patch.
Comment 1 Florian Best univentionstaff 2015-11-19 17:34:03 CET
*** Bug 17848 has been marked as a duplicate of this bug. ***
Comment 2 Florian Best univentionstaff 2016-06-23 19:57:16 CEST
The DN generation has been moved to the simpleLDAP class. It uses by default all properties which has identifies==True to generate the name (so it is also able to create multivalued RDN's).

univention-directory-manager-modules (11.0.3-17):
r70588 | Bug #40041: escape special chars in DN's when creating objects
Comment 3 Florian Best univentionstaff 2016-06-28 17:46:29 CEST
Also fixed uldap.py to be able to work with multi valued RDN's:

univention-directory-manager-modules (11.0.3-23):
r70680 | Bug #40041: autopep8
r70679 | Bug #40041: handle multivalued RDN's
Comment 4 Philipp Hahn univentionstaff 2016-06-29 19:20:52 CEST
FYI: ldap.AVA_STRING := 1, ldap.AVA_BINARY := 2
OK: r70588, r70685
OK: 40041-test
OK: r70588 r70596 r70598 r70599 r70679 r70680 r70685 r70686

OK: udm container/cn create --set name=foo,ou=bar
OK: udm container/cn create --set name=foo+ou=bar
OK: kerberos/kdcentry.py
OK: mail/folder.py
OK: settings/directory
OK: settings/xconfig_choices
OK: users/user
OK: container/dc
 creating it was not possible previously, not it works. It was disabled on purpose as something broke with multiple Domain-Component objects.
OK: rename multi-valued

FIXED: TypeError: %d format: a number is required, not str
OK: r70716, r70727

FIXED: univention-directory-manager-modules.yaml
 r70691 r70729
OK: errata-announce -V --only univention-directory-manager-modules.yaml

FIXED: univention-python.yaml
 r70691 r70729
OK: errata-announce -V --only univention-python.yaml

FYI: There are some cases, where DNs are compared for equality. They are broken as only the LDAP schema on the server has the information which RDNs are case-sensitive and which aren't for example.
Further multi-valued RDNs are not handled correctly, as "a=1+b=2" and "b=2+a=1" are the same.
Ignoring those issues for now (uldap.py

r70728 | Bug #41580 test: Test uldap.py

Package: ucs-test
Version: 6.0.33-82.1494.201606291918
Branch: ucs_4.1-0
Scope: errata4.1-2
Comment 6 Philipp Hahn univentionstaff 2016-07-20 10:37:07 CEST
*** Bug 32317 has been marked as a duplicate of this bug. ***
Comment 7 Florian Best univentionstaff 2016-07-26 15:16:23 CEST
*** Bug 34749 has been marked as a duplicate of this bug. ***
Comment 8 Florian Best univentionstaff 2016-08-17 14:52:26 CEST
*** Bug 41032 has been marked as a duplicate of this bug. ***
Comment 9 Florian Best univentionstaff 2016-09-15 12:52:05 CEST
*** Bug 41235 has been marked as a duplicate of this bug. ***