[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: ssf Security Question
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,
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