Full_Name: Lukas Slebodnik Version: 2.4.38 OS: Fedora URL: ftp://ftp.openldap.org/incoming/Lukas-Slebodnik-131205.tar.gz Submission from: (NULL) (209.132.186.34) We(sssd) have an upstream ticket with crash. https://fedorahosted.org/sssd/ticket/2134 But after investigation, it was not problem in sssd, but in ldap library. sssd_be: ../../../libraries/liblber/io.c:108: ber_write: Assertion `buf != ((void *)0)' failed. I think that problem is partially in user LDAP server, because server send wrong response for user binding with password policy. But on the other hand ldap_parse_result should not return LDAP_SUCCESS if incoming message is malformed, because it was a reason why 2nd ldap function ldap_parse_passwordpolicy_control crashed with abort. Reporter uses old ldap library on Centos 6.4, but I was able to reproduce with libraries from the latest version from git repo(master branch) I uploaded tarball Lukas-Slebodnik-131205.tar.gz with patch and two files with client-server communication (hexdump from wireshark). 1st with enabled password policy on server and 2nd with disabled PP. Problem occurs only with enabled password policy.
changed state Open to Test moved from Incoming to Software Bugs
lslebodn@redhat.com wrote: > Full_Name: Lukas Slebodnik > Version: 2.4.38 > OS: Fedora > URL: ftp://ftp.openldap.org/incoming/Lukas-Slebodnik-131205.tar.gz > Submission from: (NULL) (209.132.186.34) > > > We(sssd) have an upstream ticket with crash. > https://fedorahosted.org/sssd/ticket/2134 > But after investigation, it was not problem in sssd, but in ldap library. > > sssd_be: ../../../libraries/liblber/io.c:108: ber_write: Assertion `buf != > ((void *)0)' failed. > > I think that problem is partially in user LDAP server, because server send wrong > response for user binding with password policy. But on the other hand > ldap_parse_result should not return LDAP_SUCCESS if incoming message is > malformed, because it was a reason why 2nd ldap function > ldap_parse_passwordpolicy_control crashed with abort. Thanks for the report, but your patch is wrong, it rejects any control with a NULL value. Not all controls are required to have a value, so your patch would reject otherwise valid controls. > Reporter uses old ldap library on Centos 6.4, but I was able to reproduce with > libraries from the latest version from git repo(master branch) > > I uploaded tarball Lukas-Slebodnik-131205.tar.gz with patch and two files with > client-server communication (hexdump from wireshark). 1st with enabled password > policy on server and 2nd with disabled PP. Problem occurs only with enabled > password policy. > > > > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
lslebodn@redhat.com wrote: > Full_Name: Lukas Slebodnik > Version: 2.4.38 > OS: Fedora > URL: ftp://ftp.openldap.org/incoming/Lukas-Slebodnik-131205.tar.gz > Submission from: (NULL) (209.132.186.34) Fixed now in git master. > > We(sssd) have an upstream ticket with crash. > https://fedorahosted.org/sssd/ticket/2134 > But after investigation, it was not problem in sssd, but in ldap library. > > sssd_be: ../../../libraries/liblber/io.c:108: ber_write: Assertion `buf != > ((void *)0)' failed. > > I think that problem is partially in user LDAP server, because server send wrong > response for user binding with password policy. But on the other hand > ldap_parse_result should not return LDAP_SUCCESS if incoming message is > malformed, because it was a reason why 2nd ldap function > ldap_parse_passwordpolicy_control crashed with abort. > > Reporter uses old ldap library on Centos 6.4, but I was able to reproduce with > libraries from the latest version from git repo(master branch) > > I uploaded tarball Lukas-Slebodnik-131205.tar.gz with patch and two files with > client-server communication (hexdump from wireshark). 1st with enabled password > policy on server and 2nd with disabled PP. Problem occurs only with enabled > password policy. > > > > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Lukas Slebodnik wrote: > On (07/12/13 08:37), Howard Chu wrote: >> lslebodn@redhat.com wrote: >>> Full_Name: Lukas Slebodnik >>> Version: 2.4.38 >>> OS: Fedora >>> URL: ftp://ftp.openldap.org/incoming/Lukas-Slebodnik-131205.tar.gz >>> Submission from: (NULL) (209.132.186.34) >> >> Fixed now in git master. > > Thank you. > > According commit 80e6316d37dd024bf32ed6db024f195c1b51ef7f, it seems to me > I was right that ApacheDS send wrong response. > Could you confirm this statement? because I am not expert in ldap protocol > and I would like to file a bug to ApacheDS upstream. The hex dumps you included were a bit difficult to read. I couldn't tell what was sent from the server vs the client and what the message boundaries were. If you can reproduce the behavior using e.g. ldapwhoami -d7 that would be more legible. Meanwhile you can refer to draft-behera-ldap-password-policy for the specification of the response control. The control value is mandatory for this control. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Lukas Slebodnik wrote: > On (09/12/13 00:59), Howard Chu wrote: >> Lukas Slebodnik wrote: >>> On (07/12/13 08:37), Howard Chu wrote: >>>> lslebodn@redhat.com wrote: >>>>> Full_Name: Lukas Slebodnik >>>>> Version: 2.4.38 >>>>> OS: Fedora >>>>> URL: ftp://ftp.openldap.org/incoming/Lukas-Slebodnik-131205.tar.gz >>>>> Submission from: (NULL) (209.132.186.34) >>>> >>>> Fixed now in git master. >>> >>> Thank you. >>> >>> According commit 80e6316d37dd024bf32ed6db024f195c1b51ef7f, it seems to me >>> I was right that ApacheDS send wrong response. >>> Could you confirm this statement? because I am not expert in ldap protocol >>> and I would like to file a bug to ApacheDS upstream. >> >> The hex dumps you included were a bit difficult to read. I couldn't >> tell what was sent from the server vs the client and what the message >> boundaries were. > It is output directly from wireshark. Indented lines represent response > from server. > > ldap_communication_without_PP.hexdump > ---------------------------------------------------------------------------- > 00000000 30 5f 02 01 01 60 3b 02 01 03 04 2a 63 6e 3d 57 0_...`;. ...*cn=W > 00000010 69 6c 6c 69 61 6d 20 42 75 73 68 2c 6f 75 3d 70 illiam B ush,ou=p > 00000020 65 6f 70 6c 65 2c 64 63 3d 65 78 61 6d 70 6c 65 eople,dc =example > 00000030 2c 64 63 3d 73 6b 80 0a 6a 61 68 6f 64 61 2e 31 ,dc=sk.. jahoda.1 > 00000040 32 33 a0 1d 30 1b 04 19 31 2e 33 2e 36 2e 31 2e 23..0... 1.3.6.1. > 00000050 34 2e 31 2e 34 32 2e 32 2e 32 37 2e 38 2e 35 2e 4.1.42.2 .27.8.5. > 00000060 31 1 > ^^^^^^^^ > client > > 00000000 30 0c 02 01 01 61 07 0a 01 00 04 00 04 00 0....a.. ...... > ^^^^^^^^ > server > > 00000061 30 05 02 01 02 42 00 0....B. > ^^^^^^^^ > client > ---------------------------------------------------------------------------- > >> If you can reproduce the behavior using e.g. >> ldapwhoami -d7 that would be more legible. > output from command ldapwhoami is in the attached file screenlog.2 > but it loks like ApacheDS does not support LDAP_EXOP_WHO_AM_I. The point was to show a Bind request using the ppolicy control. The actual WhoAmI operation was irrelevant. But you didn't specify ppolicy in your invocation. Please read the ldapwhoami manpage. Use -E ppolicy to use the ppolicy control, the screenlog you attached has nothing interesting without the ppolicy traffic. >> Meanwhile you can refer to draft-behera-ldap-password-policy for the >> specification of the response control. The control value is mandatory >> for this control. > If I read draft "6.2. Response Control" correctly, > http://tools.ietf.org/html/draft-behera-ldap-password-policy-10#section-6.2 > response can be sequence of "PasswordPolicyResponseValue". > I think that sequence means "0 or more values" The sequence is required to begin with a Sequence marker. > In theory, there needn't be any password policy response value after control > type. In this case, either my patch or your patch are wrong. > Did I miss something? > > The controlType is 1.3.6.1.4.1.42.2.27.8.5.1 and the controlValue is > the BER encoding of the following type: "the controlValue is the BER encoding of a Sequence." - even if the sequence has zero members, it cannot be omitted. > PasswordPolicyResponseValue ::= SEQUENCE { > warning [0] CHOICE { > ...snip... } OPTIONAL, > error [1] ENUMERATED { > ...snip... } OPTIONAL > } > > Thank you very much for response. > > LS > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Lukas Slebodnik wrote: > On (09/12/13 04:01), Howard Chu wrote: >>>> Meanwhile you can refer to draft-behera-ldap-password-policy for the >>>> specification of the response control. The control value is mandatory >>>> for this control. >>> If I read draft "6.2. Response Control" correctly, >>> http://tools.ietf.org/html/draft-behera-ldap-password-policy-10#section-6.2 >>> response can be sequence of "PasswordPolicyResponseValue". >>> I think that sequence means "0 or more values" >> >> The sequence is required to begin with a Sequence marker. >> >>> In theory, there needn't be any password policy response value after control >>> type. In this case, either my patch or your patch are wrong. >>> Did I miss something? >>> >>> The controlType is 1.3.6.1.4.1.42.2.27.8.5.1 and the controlValue is >>> the BER encoding of the following type: >> >> "the controlValue is the BER encoding of a Sequence." - even if the >> sequence has zero members, it cannot be omitted. >> > Thank you for your explanation. > > I am attaching output from ldapwhoami with enabled ppolicy, > but I am sure that problem is in the server apacheds, because there is nothing > after controlType 1.3.6.1.4.1.42.2.27.8.5.1 > (at least Sequence marker should be after controlType) Agreed, that looks like an ApacheDS bug. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
changed notes
changed state Test to Release
changed notes changed state Release to Closed
Fixed in head fixed in RE25 fixed in RE24