[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Antw: Re: ssf Security Question
>>> William Brown <wibrown@redhat.com> schrieb am 17.11.2017 um 06:31 in Nachricht
<1510896691.4395.140.camel@redhat.com>:
> On Thu, 2017-11-16 at 21:25 -0800, Quanah Gibson-Mount wrote:
>> --On Friday, November 17, 2017 12:53 PM +1000 William Brown
>> <wibrown@redhat.com> wrote:
>>
>> Hi William,
>>
>> > Hey mate,
>> >
>> > Just want to point out there are some security risks with ssf
>> > settings.
>> > I have documented these here:
>> >
>> > https://fy.blackhats.net.au/blog/html/2016/11/23/the_minssf_trap.ht
>> > ml
>> >
>> > This is a flaw in the ldap protocol and can never be resolved
>> > without
>> > breaking the standard. The issue is that by the time the ssf check
>> > is
>> > done, you have already cleartexted sensitive material.
>>
>> I think what you mean is: There is no way with startTLS to prevent
>> possible
>> leakage of credentials when using simple binds. ;) Your blog
>> certainly
>> covers this concept well, but just wanted to be very clear on what
>> the
>> actual issue is. ;) I've been rather unhappy about this for a long
>> time as
>> well, and have had a discussion going on the openldap-devel list
>> about
>> LDAPv4 and breaking backwards compatibility to fix this protocol bug.
>
> Absolutely. I think it's just better to say look, expect leakage. Do it
> right, once, and guarantee your behaviours. It's not just simple bind
> though,
>
> An example here though, is because of how minssf works, we have to
> accept anonymous binds on ssf=0, because we expect starttls next - even
> then, you can leak things like "search mail=secret@secret". If they
> don't want to leak phone numbers, mail etc. So we have a dataleak in
> the form of the query, before the ssf check can reject our request.
>
> Sure, we aren't leaking entries, but we shouldn't leak *anything* if we
> are in this kind of environment,
Hi!
BTW: Does anyone know the backgraound of SUSE Linux Enterprise Server (SLES) moving from OpenLDAP to Redhat's directory server in ist next release?
Regards,
Ulrich
>
> Again coming back to LDAPS is the only way to really guarantee this
> connection is truly encrypted from the first byte to the last :)
>
>>
>> Another note -- The reason GSSAPI shows up as an SSF of 56 is because
>> it
>> has been hard coded that way in cyrus-sasl. Starting with cyrus-
>> sasl
>> version 2.1.27, which is near release, the actual SASL SSF is
>> finally
>> passed back into the caller. It may be worthwhile noting this in
>> your blog
>> post. ;)
>
> Yeah, the krb devs told me about this change recently, I should go and
> update this :) I've just been busy lately :)
>
> Thanks mate,
>
>>
>> Warm regards,
>> Quanah
>>
>>
>> --
>>
>> Quanah Gibson-Mount
>> Product Architect
>> Symas Corporation
>> Packaged, certified, and supported LDAP solutions powered by
>> OpenLDAP:
>> <http://www.symas.com>
>>
> --
> Sincerely,
>
> William Brown
> Software Engineer
> Red Hat, Australia/Brisbane