ldap driver returns hashed passwords
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Identity (keystone) |
Fix Released
|
High
|
Adam Young |
Bug Description
If I'm using the LDAP identity backend, listing group users includes the users' passwords (sha-encoded, but that probably depends on LDAP server configuration).
Keystone shouldn't be handing out users' passwords.
The fix is probably to just remove the password attribute. If Keystone is just returning all attributes, then it should be changed to only return the attributes that are known to be safe.
Steps to recreate:
1) start with devstack configured to use LDAP
# set LDAP options in localrc
./stack.sh ...
2) add the default domain since it doesn't exist by default for some reason.
$ ldapadd -x -D dc=Manager,
dn: cn=default,
objectclass: groupOfNames
member: cn=dummy
3) Create a couple users
(set environment variables so you're admin)
$ keystone user-create --name user1 --pass user1pwd
(example id is 1db4a4d16ba1458
$ keystone user-create --name user2 --pass user2pwd
(example id is 4091d11924f5498
4) Create a group
$ ldapadd -x -D dc=Manager,
dn: ou=UserGroups,
objectclass: organizationalUnit
dn: cn=group1,
objectclass: groupOfNames
member: cn=1db4a4d16ba1
member: cn=4091d11924f5
5) List the group members:
$ curl -H "X-Auth-Token: admintoken" http://
{
"links": {
"next": null,
"previous": null,
"self": "http://
},
"users": [
{
"id": "1db4a4d16ba145
},
"name": "user1",
},
{
"id": "4091d11924f549
},
"name": "user2",
}
]
}
information type: | Private Security → Public |
tags: | added: security |
Changed in keystone: | |
assignee: | nobody → Adam Young (ayoung) |
summary: |
- ldap list members returns passwords + ldap driver returns hashed passwords |
Changed in keystone: | |
milestone: | none → havana-3 |
status: | Fix Committed → Fix Released |
Changed in keystone: | |
milestone: | havana-3 → 2013.2 |
Adding keystone-core for opinion...
Not totally convinced this is a Keystone vulnerability. Should the attributes be filtered on Keystone side, or rather not be handed out by the LDAP server itself ? Who can list those users ? Doesn't that role already involve modifying the group members password ? I agree that this should be fixed, but I'm not sure there is an exploitable attack scenario here.