Skip Menu |

This queue is for tickets about the Catalyst-Authentication-Store-LDAP CPAN distribution.

Report information
The Basics
Id: 81908
Status: resolved
Priority: 0/
Queue: Catalyst-Authentication-Store-LDAP

People
Owner: karman [...] cpan.org
Requestors: crosswhi [...] gmail.com
Cc:
AdminCc:

Bug Information
Severity: Normal
Broken in: 1.012
Fixed in: (no value)



Subject: User able to authenticate with null password
I'm not sure if this is a bug or intended behavior. I've setup a small Catalyst project with CatalystX::SimpleLogin, and I'm authenticating against an AD server. Here's the store information: store => { class => 'LDAP', ldap_server => '<server_name>', ldap_server_options => { timeout => 30 }, binddn => 'CN=<user_name>,OU=Users,OU=Domain Users,DC=dev,DC=my_org,DC=com', bindpw => '<password>', user_basedn => 'dc=dev,dc=my_org,dc=com', user_filter => '(sAMAccountName=%s)', user_scope => 'sub', user_field => 'samaccountname', }, The authentication works fine; the issue comes up when I use the same username that's given in the 'binddn' field. I set the index page to requiring a login, browse to it, put in the correct username in the username box and leave the password blank, hit submit, and I'm taken to the index page. It appears that line 218 in Backend.pm will set the bindpw to the password given above if the password is null, and since I'm using the same username as the bind account, the re-bind succeeds. Like I said, I'm not sure if this is a bug or intended behavior since I should be using a service type account for the initial bind.
That does seem like a security hole. I will try and patch it.
1.013 just uploaded to CPAN. Please reply here as to whether it fixes the problem.
Subject: [rt.cpan.org #81908] PATCH: Fix security hole introduced by initial fix
Date: Fri, 26 Apr 2013 19:37:51 +0100
To: <bug-Catalyst-Authentication-Store-LDAP [...] rt.cpan.org>
From: "D. Ilmari Mannsåker" <Ilmari.Mannsaker [...] net-a-porter.com>
Hi, The fix for this bug introduced a much worse security hole: passing a false password ("0" or "") does an unauthenticated bind as the user, which can succeed without granting any access, thus shouldn't be considered a successful auth. Please find a patch attached. Cheers, -- ilmari NET-A-PORTER.COM Irresistible fashion at your fingertips CONFIDENTIALITY NOTICE The information in this email is confidential and is intended solely for the addressee. Access to this email by anyone else is unauthorised. If you are not the intended recipient, you must not read, use or disseminate the information. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Net-A-Porter Group Limited. The Net-A-Porter Group Limited is a company registered in England & Wales Number: 3820604 Registered Office: 1 The Village Offices, Westfield, Ariel Way, London, W12 7GF

Message body is not shown because sender requested not to inline it.

I have uploaded a security fixed release including this patch. I've also issued an advisory / upgrade warning to the Catalyst list, in the hope that people who accidentally have this will upgrade. On Fri Apr 26 14:38:16 2013, Ilmari.Mannsaker@net-a-porter.com wrote: Show quoted text
> Hi, > > The fix for this bug introduced a much worse security hole: passing a > false password ("0" or "") does an unauthenticated bind as the user, > which can succeed without granting any access, thus shouldn't be > considered a successful auth. > > Please find a patch attached. > > Cheers, >
I tried this new patch patch earlier today and it worked for me. I tried with the binddn user and no password, and I got a login failure. On Fri Apr 26 16:05:52 2013, BOBTFISH wrote: Show quoted text
> I have uploaded a security fixed release including this patch. > > I've also issued an advisory / upgrade warning to the Catalyst list, > in the hope that people who accidentally have this will upgrade. > > On Fri Apr 26 14:38:16 2013, Ilmari.Mannsaker@net-a-porter.com wrote:
> > Hi, > > > > The fix for this bug introduced a much worse security hole: passing
> a
> > false password ("0" or "") does an unauthenticated bind as the user, > > which can succeed without granting any access, thus shouldn't be > > considered a successful auth. > > > > Please find a patch attached. > > > > Cheers, > >
> >
I think the answer is "this is intended behavior" and use a dedicated service account for bind.