OpenStack Object Storage (swift)

Authentication using tempAuth writes token to log file

Bug #1655703 reported by Rahul U Nair
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Object Storage (swift)
Confirmed
Undecided
Unassigned
OpenStack Security Advisory
Won't Fix
Undecided
Unassigned

Bug Description

When using a token to do an AUTH_test, the swift proxy logs the token used if successful, this can lead to possible security issue by granting access to a swift cluster to a person who just has access to the logs. This issue is present when tempAuth authentication flow is used.

The steps to recreate the issue:

1. Install a swift all in one Instance (SAIO).
2. Retrieve admin token from cli using the command inside of an SAIO cluster,

```
swift -A http://saio:8080/auth/v1.0 -U admin:admin -K admin stat -v``
```

3. Retrieve the auth token from CLI and issue the command,

```
curl -i http://saio:8080/v1/AUTH_test -I -H "X-Auth-Token: AUTH_tk44d4f00971ed412396b602e46aeef57c"
```

The log written to disk when this command is executed has the token AUTH_tk44d4f00971ed412396b602e46aeef57c written to it as well.

```
Jan 10 21:31:58 ubuntu-xenial proxy-server: STDERR: (28655) accepted ('127.0.0.1', 48506)
Jan 10 21:31:58 ubuntu-xenial proxy-server: User: admin uses token AUTH_tk44d4f00971ed412396b602e46aeef57c (trans_id tx77daa27b44374e688cb82-00587552ce)
Jan 10 21:31:58 ubuntu-xenial proxy-server: User admin:admin has reseller admin authorizing. (txn: tx77daa27b44374e688cb82-00587552ce) (client_ip: 127.0.0.1)
Jan 10 21:31:58 ubuntu-xenial account-6012: STDERR: (28635) accepted ('127.0.0.1', 46292)
Jan 10 21:31:58 ubuntu-xenial account-6012: 127.0.0.1 - - [10/Jan/2017:21:31:58 +0000] "HEAD /sdb1/802/AUTH_test" 204 - "HEAD http://saio:8080/v1/AUTH_test" "tx77daa27b44374e688cb82-00587552ce" "proxy-server 28655" 0.0011 "-" 28635 -
Jan 10 21:31:58 ubuntu-xenial account-6012: STDERR: 127.0.0.1 - - [10/Jan/2017 21:31:58] "HEAD /sdb1/802/AUTH_test HTTP/1.1" 204 442 0.002273 (txn: tx77daa27b44374e688cb82-00587552ce)
Jan 10 21:31:58 ubuntu-xenial proxy-server: removed response headers: [('X-Backend-Recheck-Account-Existence', '60')] (txn: tx77daa27b44374e688cb82-00587552ce) (client_ip: 127.0.0.1)
Jan 10 21:31:58 ubuntu-xenial proxy-server: 127.0.0.1 127.0.0.1 10/Jan/2017/21/31/58 HEAD /v1/AUTH_test HTTP/1.0 204 - curl/7.47.0 AUTH_tk44d4f0097... - - - tx77daa27b44374e688cb82-00587552ce - 0.0267 - - 1484083918.178980112 1484083918.205643892 -
Jan 10
```

This is part of the swift security testing done as part of OSIC. Kindly comment if this is considered as a security issue in swift. From our perspective, under no circumstance the Auth Token be written to log files as then it can be accessed by a possible third party.

See original description
Revision history for this message
Jeremy Stanley (fungi) wrote :

Since this report concerns a possible security risk, an incomplete security advisory task has been added while the core security reviewers for the affected project or projects confirm the bug and discuss the scope of any vulnerability along with potential solutions.

description: updated
Changed in ossa:
status: New → Incomplete
Revision history for this message
Donagh McCabe (donagh-mccabe) wrote :

Since this is an SAIO environment, it means that tempauth is being used. Hence, not a security issue for OpenStack (where Keystone is used).

Tempauth is only used for test purposes and is specifically not recommended for production use (see first paragraph of http://docs.openstack.org/developer/swift/overview_auth.html#tempauth). Having said this, since tempauth may be used as a basis for developing custom code, it would be worth obscuring the token in the logs. A utility function is used elsewhere in Swift to avoid the token appearing in the logs.

In summary: is not a threat to production systems, but worth fixing for it's own sake.

Revision history for this message
John Dickinson (notmyname) wrote :

I agree with everything Donagh said: not a security issue, but something that needs to be fixed.

The debug log line at https://github.com/openstack/swift/blob/master/swift/common/middleware/tempauth.py#L250 is emitting this.

For non-debug (ie expected prod) usage, we've got the https://github.com/openstack/swift/blob/master/etc/proxy-server.conf-sample#L634-L644 setting for the "normal" log lines. We should still suppress this. I'd be a fan of just removing that debug log line.

Revision history for this message
Rahul U Nair (rahulunair) wrote :

Thank you all for the comments.

I agree with Donagh that this shouldn't be a security issue in production systems of OpenStack where keystone is used, but as tempAuth is suggested as a model to create custom middleware and the implementation is `fully functional`, it is good to get this out of the logs and treat it as a security issue till then.

Revision history for this message
Jeremy Stanley (fungi) wrote :

Based on the above comments, this is clearly Class B3 (A vulnerability in experimental or debugging features not intended for production use) in the VMT's report taxonomy, and so does not require further embargo nor any coordinated advisory. I'm switching the bug to public and marking our OSSA task "won't fix" to indicate the lack of need for formal vulnerability handling process.

Changed in ossa:
status: Incomplete → Won't Fix
information type: Private Security → Public
Revision history for this message
Jeremy Stanley (fungi) wrote :

I forgot to link to our taxonomy in comment #5, but it can be found here: https://security.openstack.org/vmt-process.html#incident-report-taxonomy

Revision history for this message
John Dickinson (notmyname) wrote :

Here's a quick-and-dirty couple of patches that clean this up. The first is just removing the auth token and synk key from logs. The second removes other stuff which doesn't seem too helpful and can fill up logs.

I'm curious what others think.

https://gist.github.com/notmyname/ab4712e51945e7a2a0cd5fb0363f0b61

Revision history for this message
Rahul U Nair (rahulunair) wrote :

The gist looks good to me, thanks John for the quick patch.

Can I request a CVE for this bug as this issue is a vulnerability (Even though not in a production environment), thus it would be good to have a CVE associated with it. What do you all think?

Revision history for this message
John Dickinson (notmyname) wrote :

I don't support having a CVE for it.

Rahul U Nair (rahulunair)
Changed in swift:
status: New → Confirmed
Jeremy Stanley (fungi)
description: updated
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.