288924 - LDAP searches do not properly escape LDAP meta-characters

Status: NEW

(MailNews Core :: LDAP Integration, defect)

Description

[Andrew Sciberras]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050317 Firefox/1.0.2
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050317 Firefox/1.0.2

I find that if I search an LDAP Directory for the single character value '*', an
invalid LDAP Search Request will be sent.

For some reason, this search request is being encoded as a substrings search
without any 'initial', 'any' or 'final' data. 
To get a little bit more technical, the following is the ASN.1 for a
SubstringFilter:

SubstringFilter ::= SEQUENCE {
        type            AttributeDescription,
        -- at least one must be present
        substrings      SEQUENCE OF CHOICE {
                initial [0] LDAPString,
                any     [1] LDAPString,
                final   [2] LDAPString } }

The address book will send a SubstringFilter with 'type' filled out, and with
'substrings' as an empty sequence. Which is invalid for LDAP. 


Reproducible: Always

Steps to Reproduce:
1. Configure an LDAP Directory source
2. Get ready to capture packets going to the LDAP Directory
3. Execute a search for *
4. First packet will be the bind
5. Second packet will be the search request.
6. Inspecting the BER will show the invalid encoding

Actual Results:  
LDAP Directory vendor specific. 
If the vendor is purely LDAP and follows the rules strictly, you'll get no
results back.
If the vendor is lax, or X.500 based (where such a filter is valid), you may see
results that equate to a presence match.

Expected Results:  
The search request should have been encoded as a PRESENT match instead.

Comment 1

[Andrew Sciberras]

Actually, ignore that statement of a single *. It happens for any number of
asterisks, as long as the entire filter is made up of '*' characters.

Comment 2

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 3

[deepblue]

I have the same problem on Mozilla-1.7.12, both Linux and Windows version.

Mozilla build up the query as:

Filter: (|(mail=)(cn=)(ginvenname=)(sn=))

as is showned on the output of Ethereal.

With openldap > 2.0, this query can't work.

Comment 4

[Peter Schober]

I posted this to the openldap-software list over a year ago, see Kurt Zeilenga's take on what presumedly is happening: http://www.openldap.org/lists/openldap-software/200408/msg00243.html
so yes, the problem still persists.

Comment 5

[Tom Weichmann]

When using the Address Book in Mozilla Thunderbird 1.5 (20051201) connected to a lotus notes directory server looking up certin names does not work. Here is an example:

If I type in 'Jim Smith' I get a listing for I get:
Jim Smith | [e-mail]

I can also type in 'jsmith' and get the same information.

However if I type in 'lopserv' I get the following:
*A&T Low Pressure C&M_EA_AG | [e-mail]

but if I search for '*A&T Low Pressure C&M_EA_AG' I do not get anything

If I type in '*A&T' I get a few returns, but only addresses that contain A&T in the email address, but not in the name field.

I should be able to search for either the name or the e-mail address and achieve the same results.

Comment 6

[Dan Mosedale (:dmosedale, :dmose)]

Kurt's analysis is correct.