Conversation
compileFilterSet skipped the byte at pos as the closing parenthesis of an
AND/OR filter set, and compileFilter's '(' case skipped the byte after a
nested filter, both without looking at it. A filter truncated after a child
and padded with any character, or one with a typo in place of its closing
parenthesis, was therefore accepted and compiled as a different filter.
Reject those with "unexpected end of filter" instead.
A condition of two or more '*' and nothing else (for example (sn=**)) is not the present filter, but contains '*', so compileFilter built a Substrings packet whose SEQUENCE had every empty part skipped. RFC 4511 4.5.1.7.2 requires substrings ::= SEQUENCE SIZE (1..MAX), and DecompileFilter turned the result back into (sn=), an equality match with the empty value. Reject a substring filter with no substrings instead.
RFC 4515 defines dnattrs = COLON "dn", and ABNF string literals are case-insensitive (RFC 5234 2.3), but compileFilter compared the bytes with strings.HasPrefix literally. Filters such as (o:DN:=x) were compiled as a matching rule named "DN" and sent to the server as a request for an unknown matching rule. Compare with strings.EqualFold instead.
Detecting invalid UTF-8 by comparing the decoded rune with utf8.RuneError ignores the width returned by DecodeRuneInString: a genuine U+FFFD (bytes EF BF BD, a valid UTFMB under RFC 4515) is reported as "error reading rune at position N". The escaped form (cn=a\ef\bf\bdb) compiled, so the round trip only worked one way. Check for a width of 1 as well, in compileFilter and decodeEscapedSymbols.
compileFilter accumulated every rune up to the operator as the attribute, so (=v), (a b=v) and (a\2ab=v) compiled and went on the wire. Since the attribute is not unescaped, CompileFilter and DecompileFilter disagreed about it: (a\2ab=v) compiled with the literal attribute a\2ab and decompiled as (a\5c2ab=v), which compiles to yet another attribute. Validate the attribute description against RFC 4512 (descr or numericoid, with optional ";" options) before building the packet, for both regular and extensible filters that carry an attribute.
RFC 4515 requires a matching rule when the attribute is absent from an extensible match, but compileFilter's ":=" and ":dn:=" cases never checked that anything preceded them. (:=a) compiled to a MatchingRuleAssertion with only a matchValue, and (:dn:=a) to one that adds dnAttributes; with both the type and matchingRule absent the assertion is meaningless. Reject an extensible filter that has neither.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #633.