Issue 8294 - slappasswd can use SHA256 for hash but not SHA384 or SHA512...segfault
Summary: slappasswd can use SHA256 for hash but not SHA384 or SHA512...segfault
Status: VERIFIED FIXED
Alias: None
Product: OpenLDAP
Classification: Unclassified
Component: contrib (show other issues)
Version: 2.4.42
Hardware: All All
: --- normal
Target Milestone: ---
Assignee: OpenLDAP project
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-10-27 20:11 UTC by ktmdms@gmail.com
Modified: 2015-11-30 18:20 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description ktmdms@gmail.com 2015-10-27 20:11:55 UTC
Full_Name: Kevin Martin
Version: 2.4.42
OS: 3.8.13-55.1.6.el7uek.x86_64
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (137.254.4.10)


Compiled 2.4.42 from source with the following configure options:

./configure --enable-ppolicy --enable-crypt --with-tls --enable-bdb
--enable-ldap --enable-slapd  --enable-slapi --enable-syslog --enable-modules

compiles and installs fine.  Built the pw-sha2 contrib module and installed with
no problems.

The following works fine:

   /usr/local/sbin/slappasswd -v -v -v -h '{SHA256}' -o
module-path=/usr/local/libexec/openldap -o module-load=pw-sha2 -s secret
{SHA256}K7gNU3sdo+OL0wNhqoVWhr3g6s1xYv72ol/pe/Unols=

 /usr/local/sbin/slappasswd -v -v -v -h '{CRYPT}' -c '$6$!4&&.'  -s secret
{CRYPT}$6$!4&&.$oINsiq8QMkQheQrdy0.qk7qKr7tNVNCX387QMrp8Y/w2y7JcazTvfKhG0mSGIAB1jWZ4xsDbsehH/4yPIns6I.


The following create segfaults:

   /usr/local/sbin/slappasswd -v -v -v -h '{SHA384}' -o
module-path=/usr/local/libexec/openldap -o module-load=pw-sha2 -s secret
Segmentation fault (core dumped)

/usr/local/sbin/slappasswd -v -v -v -h '{SHA512}' -o
module-path=/usr/local/libexec/openldap -o module-load=pw-sha2 -s secret
Segmentation fault (core dumped)


I shouldn't need to use CRYPT with a salt to create a SHA512 hashed password. 
Bug or something on my machine?

Regards,

Kevin Martin
Comment 1 ktmdms@gmail.com 2015-10-28 14:12:01 UTC
To add fuel to the fire, if I use pw-sha2 libraries that were built on a
2.6 kernel (specifically 2.6.32-358.el6.x86_64) on the 3.18 machine I can
generate SHA512/384 hashed passwords with no issues.  What should I be
looking for between the two platforms that might cause the core?

Thanks.

Kevin Martin

---


Regards,

Kevin Martin

On Tue, Oct 27, 2015 at 3:11 PM, <openldap-its@openldap.org> wrote:

>
> *** THIS IS AN AUTOMATICALLY GENERATED REPLY ***
>
> Thanks for your report to the OpenLDAP Issue Tracking System.  Your
> report has been assigned the tracking number ITS#8294.
>
> One of our support engineers will look at your report in due course.
> Note that this may take some time because our support engineers
> are volunteers.  They only work on OpenLDAP when they have spare
> time.
>
> If you need to provide additional information in regards to your
> issue report, you may do so by replying to this message.  Note that
> any mail sent to openldap-its@openldap.org with (ITS#8294)
> in the subject will automatically be attached to the issue report.
>
>         mailto:openldap-its@openldap.org?subject=(ITS#8294)
>
> You may follow the progress of this report by loading the following
> URL in a web browser:
>     http://www.OpenLDAP.org/its/index.cgi?findid=8294
>
> Please remember to retain your issue tracking number (ITS#8294)
> on any further messages you send to us regarding this report.  If
> you don't then you'll just waste our time and yours because we
> won't be able to properly track the report.
>
> Please note that the Issue Tracking System is not intended to
> be used to seek help in the proper use of OpenLDAP Software.
> Such requests will be closed.
>
> OpenLDAP Software is user supported.
>         http://www.OpenLDAP.org/support/
>
> --------------
> Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved.
>
>
Comment 2 Howard Chu 2015-10-28 14:55:39 UTC
ktmdms@gmail.com wrote:
> --089e0115ec1091312605232ac99f
> Content-Type: text/plain; charset=UTF-8
>
> To add fuel to the fire, if I use pw-sha2 libraries that were built on a
> 2.6 kernel (specifically 2.6.32-358.el6.x86_64) on the 3.18 machine I can
> generate SHA512/384 hashed passwords with no issues.  What should I be
> looking for between the two platforms that might cause the core?

Strange that the kernel would make any difference - more likely it's your C 
compiler making the difference.

I ran a test on one machine and got an abort in glibc saying there was a stack 
overrun. On a different machine I got no such error, and running on the 
problem system under valgrind produced no errors.

On the machine that aborted, when I compiled with gcc -fstack-protector-all, 
the glibc abort disappeared as well. So, this hasn't helped me identify the 
problem yet. (gcc 4.8.4-2ubuntu1~14.04)

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/

Comment 3 Howard Chu 2015-10-28 14:58:02 UTC
Howard Chu wrote:
> ktmdms@gmail.com wrote:
>> --089e0115ec1091312605232ac99f
>> Content-Type: text/plain; charset=UTF-8
>>
>> To add fuel to the fire, if I use pw-sha2 libraries that were built on a
>> 2.6 kernel (specifically 2.6.32-358.el6.x86_64) on the 3.18 machine I can
>> generate SHA512/384 hashed passwords with no issues.  What should I be
>> looking for between the two platforms that might cause the core?
>
> Strange that the kernel would make any difference - more likely it's your C
> compiler making the difference.

I may have misread your message. If the same binary works on a newer system, 
that tends to imply something weird in the runtime environment. Perhaps a 
problem with ASLR.

> I ran a test on one machine and got an abort in glibc saying there was a stack
> overrun. On a different machine I got no such error, and running on the
> problem system under valgrind produced no errors.
>
> On the machine that aborted, when I compiled with gcc -fstack-protector-all,
> the glibc abort disappeared as well. So, this hasn't helped me identify the
> problem yet. (gcc 4.8.4-2ubuntu1~14.04)
>


-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/

Comment 4 ktmdms@gmail.com 2015-10-28 17:12:45 UTC
adding the -fstack-protector-all option to the compile of the pw-sha2 on
the 3.18 machine and recompiling just the pw-sha2 appears to have fixed the
issue.

Regards,

Kevin Martin



---


Regards,

Kevin Martin

On Wed, Oct 28, 2015 at 9:58 AM, Howard Chu <hyc@symas.com> wrote:

> Howard Chu wrote:
>
>> ktmdms@gmail.com wrote:
>>
>>> --089e0115ec1091312605232ac99f
>>> Content-Type: text/plain; charset=UTF-8
>>>
>>> To add fuel to the fire, if I use pw-sha2 libraries that were built on a
>>> 2.6 kernel (specifically 2.6.32-358.el6.x86_64) on the 3.18 machine I can
>>> generate SHA512/384 hashed passwords with no issues.  What should I be
>>> looking for between the two platforms that might cause the core?
>>>
>>
>> Strange that the kernel would make any difference - more likely it's your
>> C
>> compiler making the difference.
>>
>
> I may have misread your message. If the same binary works on a newer
> system, that tends to imply something weird in the runtime environment.
> Perhaps a problem with ASLR.
>
>
> I ran a test on one machine and got an abort in glibc saying there was a
>> stack
>> overrun. On a different machine I got no such error, and running on the
>> problem system under valgrind produced no errors.
>>
>> On the machine that aborted, when I compiled with gcc
>> -fstack-protector-all,
>> the glibc abort disappeared as well. So, this hasn't helped me identify
>> the
>> problem yet. (gcc 4.8.4-2ubuntu1~14.04)
>>
>>
>
> --
>   -- Howard Chu
>   CTO, Symas Corp.           http://www.symas.com
>   Director, Highland Sun     http://highlandsun.com/hyc/
>   Chief Architect, OpenLDAP  http://www.openldap.org/project/
>
Comment 5 Howard Chu 2015-10-29 02:07:37 UTC
ktmdms@gmail.com wrote:
> --001a11c39c4eeea62d05232d4fc9
> Content-Type: text/plain; charset=UTF-8
>
> adding the -fstack-protector-all option to the compile of the pw-sha2 on
> the 3.18 machine and recompiling just the pw-sha2 appears to have fixed the
> issue.

Using -fstack-protector-all wasn't intended to fix the issue, it was intended 
to make the cause more visible. Instead it has hidden it. Needless to say, 
that's not an acceptable resolution for us.
>
> Regards,
>
> Kevin Martin
>
>
>
> ---
>
>
> Regards,
>
> Kevin Martin
>
> On Wed, Oct 28, 2015 at 9:58 AM, Howard Chu <hyc@symas.com> wrote:
>
>> Howard Chu wrote:
>>
>>> ktmdms@gmail.com wrote:
>>>
>>>> --089e0115ec1091312605232ac99f
>>>> Content-Type: text/plain; charset=UTF-8
>>>>
>>>> To add fuel to the fire, if I use pw-sha2 libraries that were built on a
>>>> 2.6 kernel (specifically 2.6.32-358.el6.x86_64) on the 3.18 machine I can
>>>> generate SHA512/384 hashed passwords with no issues.  What should I be
>>>> looking for between the two platforms that might cause the core?
>>>>
>>>
>>> Strange that the kernel would make any difference - more likely it's your
>>> C
>>> compiler making the difference.
>>>
>>
>> I may have misread your message. If the same binary works on a newer
>> system, that tends to imply something weird in the runtime environment.
>> Perhaps a problem with ASLR.
>>
>>
>> I ran a test on one machine and got an abort in glibc saying there was a
>>> stack
>>> overrun. On a different machine I got no such error, and running on the
>>> problem system under valgrind produced no errors.
>>>
>>> On the machine that aborted, when I compiled with gcc
>>> -fstack-protector-all,
>>> the glibc abort disappeared as well. So, this hasn't helped me identify
>>> the
>>> problem yet. (gcc 4.8.4-2ubuntu1~14.04)
>>>
>>>
>>
>> --
>>    -- Howard Chu
>>    CTO, Symas Corp.           http://www.symas.com
>>    Director, Highland Sun     http://highlandsun.com/hyc/
>>    Chief Architect, OpenLDAP  http://www.openldap.org/project/
>>
>
> --001a11c39c4eeea62d05232d4fc9
> Content-Type: text/html; charset=UTF-8
> Content-Transfer-Encoding: quoted-printable
>
> <div dir=3D"ltr">adding the -fstack-protector-all option to the compile of =
> the pw-sha2 on the 3.18 machine and recompiling just the pw-sha2 appears to=
>   have fixed the issue.<div><br></div><div>Regards,</div><div><br></div><div=
>> Kevin Martin<br><div><br></div><div><br></div></div></div><div class=3D"gm=
> ail_extra"><br clear=3D"all"><div><div class=3D"gmail_signature"><div dir=
> =3D"ltr">---<div><span style=3D"font-size:12.8px"><br></span></div><div><sp=
> an style=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-siz=
> e:12.8px">Regards,</span></div><div><div><br></div><div>Kevin Martin</div><=
> /div></div></div></div>
> <br><div class=3D"gmail_quote">On Wed, Oct 28, 2015 at 9:58 AM, Howard Chu =
> <span dir=3D"ltr">&lt;<a href=3D"mailto:hyc@symas.com" target=3D"_blank">hy=
> c@symas.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" styl=
> e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span c=
> lass=3D"">Howard Chu wrote:<br>
> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
> x #ccc solid;padding-left:1ex">
> <a href=3D"mailto:ktmdms@gmail.com" target=3D"_blank">ktmdms@gmail.com</a> =
> wrote:<br>
> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
> x #ccc solid;padding-left:1ex">
> --089e0115ec1091312605232ac99f<br>
> Content-Type: text/plain; charset=3DUTF-8<br>
> <br>
> To add fuel to the fire, if I use pw-sha2 libraries that were built on a<br=
>>
> 2.6 kernel (specifically 2.6.32-358.el6.x86_64) on the 3.18 machine I can<b=
> r>
> generate SHA512/384 hashed passwords with no issues.=C2=A0 What should I be=
> <br>
> looking for between the two platforms that might cause the core?<br>
> </blockquote>
> <br>
> Strange that the kernel would make any difference - more likely it&#39;s yo=
> ur C<br>
> compiler making the difference.<br>
> </blockquote>
> <br></span>
> I may have misread your message. If the same binary works on a newer system=
> , that tends to imply something weird in the runtime environment. Perhaps a=
>   problem with ASLR.<div class=3D"HOEnZb"><div class=3D"h5"><br>
> <br>
> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
> x #ccc solid;padding-left:1ex">
> I ran a test on one machine and got an abort in glibc saying there was a st=
> ack<br>
> overrun. On a different machine I got no such error, and running on the<br>
> problem system under valgrind produced no errors.<br>
> <br>
> On the machine that aborted, when I compiled with gcc -fstack-protector-all=
> ,<br>
> the glibc abort disappeared as well. So, this hasn&#39;t helped me identify=
>   the<br>
> problem yet. (gcc 4.8.4-2ubuntu1~14.04)<br>
> <br>
> </blockquote>
> <br>
> <br>
> -- <br>
> =C2=A0 -- Howard Chu<br>
> =C2=A0 CTO, Symas Corp.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<a href=3D"=
> http://www.symas.com" rel=3D"noreferrer" target=3D"_blank">http://www.symas=
> .com</a><br>
> =C2=A0 Director, Highland Sun=C2=A0 =C2=A0 =C2=A0<a href=3D"http://highland=
> sun.com/hyc/" rel=3D"noreferrer" target=3D"_blank">http://highlandsun.com/h=
> yc/</a><br>
> =C2=A0 Chief Architect, OpenLDAP=C2=A0 <a href=3D"http://www.openldap.org/p=
> roject/" rel=3D"noreferrer" target=3D"_blank">http://www.openldap.org/proje=
> ct/</a><br>
> </div></div></blockquote></div><br></div>
>
> --001a11c39c4eeea62d05232d4fc9--
>
>
>
>


-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/

Comment 6 Quanah Gibson-Mount 2015-10-29 20:53:19 UTC
changed notes
changed state Open to Release
moved from Incoming to Contrib
Comment 7 OpenLDAP project 2015-11-30 18:20:28 UTC
Fixed in master
Fixed in RE25
Fixed in RE24 (2.4.43)
Comment 8 Quanah Gibson-Mount 2015-11-30 18:20:28 UTC
changed notes
changed state Release to Closed