SECURITY: Logging to /tmp/sasl_oauth.log leaks credentials to other accounts

[ivucica]

Aside from having to store credentials in ${HOME}/.xoauthrc which the documentation does not recommend to be secured (for example, via chmod 0600 "${HOME}"/.xoauthrc), the default implementation also prints everything out into debugfp at /tmp/sasl_oauth.log. This file is not secured in any way.

Among information printed into this debug log is the access token and the authentication string.

If this sasl2 plugin is deployed on a multitenant system, where every user and service has access to /tmp, this leaks sufficient information for unexpected users and services to access current user's email account.

While one option might be securing the log file (perhaps by storing it somewhere in ${HOME} and chmoding it), the correct behavior is actually not to use debugfp at all.

[simmel]

How do you suggest that one would do debug logging then? printf to STDERR won't work since it's loaded by a client?

umask(2) and a file per user (id) gives the same guarantees as storing it in $HOME AFAICT.

[ivucica]

I'd say that debug logging should not be turned on by default, in the first place :-)

If one needs the debug output, they should only turn it on manually, for example via an environment variable. (Thinking about it, passing credentials via environment might be a good option that takes storage considerations, such as the use of ${HOME}/.xoauthrc, out of the hands of the plugin; what do you think?)

Even if there should be debug output by default, I don't see that there is, indeed, one file per user, nor that there is a call to umask(). But perhaps I am missing something? :-)

[simmel]

On Sun, 2016-05-15 at 17:30:44 -0700, Ivan Vučica wrote:

If one needs the debug output, they should only turn it on manually[…]

Since the config parsing is already there, it's probably a good idea to
put it in the config file.

(Thinking about it, passing credentials via environment might be a good option that takes storage considerations, such as the use of ${HOME}/.xoauthrc, out of the hands of the plugin; what do you think?)

I don't really understand. Storing the token and token_secret in ENV
instead of the config file or what credentials are you talking about?

Putting secrets in ENV is not a good idea, people will get sloppy and
it will end up in their ~/.history.

Even if there should be debug output by default, I don't see that there is, indeed, one file per user, nor that there is a call to umask(). But perhaps I am missing something? :-)

It was merely a suggestion of how to solve it.

This is not a whitewash, but an statement of facts: This started as a
personal project of Chaos Eternal to get it working for them. I forked
it to make it work for me. Now, apparently, others use it = ) I've even
seen a fork where someone commited in their tokens to get XOAUTH2
working ಠ_ಠ

[simmel]

While trying to fix this a while ago I couldn't register an XOAUTH app for GMail. Do you know if it's still possible?

[ivucica]

I used this: https://github.com/google/gmail-oauth2-tools/blob/master/python/oauth2.py to produce OAUTH2 tokens.

Unfortunately I cannot recall which type of credentials I created on https://console.cloud.google.com/ to use with oauth2.py. I believe it may have been "native client".

If my memory serves me well, I used the OAUTH2 tokens with this XOAUTH SASL plugin, and it just worked.

[ivucica]

And also, yes, I was originally talking about putting the tokens into environment -- however, you are right, it's a bad idea for the reason you outlined.

As a side note, thank you for your work on this.

[simmel]

On Mon, 2016-09-26 at 09:30:17 -0700, Ivan Vučica wrote:

And also, yes, I was originally talking about putting the tokens into environment -- however, you are right, it's a bad idea for the reason you outlined.

Thank you for confirming this.

As a side note, thank you for your work on this.

No worries, I'm on parental leave now so finally I've got time ; )

[simmel]

On Mon, 2016-09-26 at 09:28:44 -0700, Ivan Vučica wrote:

I used this: https://github.com/google/gmail-oauth2-tools/blob/master/python/oauth2.py to produce OAUTH2 tokens.

Unfortunately I cannot recall which type of credentials I created on https://console.cloud.google.com/ to use with oauth2.py. I believe it may have been "native client".

If my memory serves me well, I used the OAUTH2 tokens with this XOAUTH SASL plugin, and it just worked.

Thank you for this, I'll try again soon.

[simmel]

On Mon, 2016-09-26 at 09:28:44 -0700, Ivan Vučica wrote:

I used this: https://github.com/google/gmail-oauth2-tools/blob/master/python/oauth2.py to produce OAUTH2 tokens.

Unfortunately I cannot recall which type of credentials I created on https://console.cloud.google.com/ to use with oauth2.py. I believe it may have been "native client".

If my memory serves me well, I used the OAUTH2 tokens with this XOAUTH SASL plugin, and it just worked.

I tried it now. I'm pretty sure I've generated them correctly but since
OAUTH 1 and OAUTH 2 uses different terminology I'm not sure which I'm
supposed to use for token and token_secret.

Since I have my old credentials left in my ~/.xoauthrc but they are
revoked I'm guessing on the format that the OAUTH2 Refresh token is
what's supposed to be used as token?

And the length makes me guess that OAUTH2 Client secret is
token_secret?

I've tried this but it didn't work, can you verify that this is what you
did?

I tried the OAUTH2 Access token now as token_secret but that is only
valid for 3600 seconds.

So basically this lib needs to be rewritten for OAUTH2?

[zmughal]

I just used this with the output of oauth2.py. I am using the "Access Token" for token and "OAuth2 argument" as token_secret. Seems to work. :-/

I'm assuming that the refresh token could be used to regenerate a new "Access Token" and "OAuth2 argument" every hour?

[zmughal]

I created this small shell-script to update the tokens in .xoauthrc

#!/bin/sh

CLIENT_ID="..."
CLIENT_SECRET="..."

REFRESH_TOKEN="..."
USER_EMAIL="..."


AT=$(python oauth2.py --user="$USER_EMAIL" --client_id="$CLIENT_ID" --client_secret="$CLIENT_SECRET" --refresh_token="$REFRESH_TOKEN" | head -1 | sed 's/Access Token: //')
OA=$(python oauth2.py --generate_oauth2_string --access_token="$AT" --user="$REFRESH_TOKEN" | tail -1 )

echo | tee ~/.xoauthrc <<EOF
# The last oauth_token output of xoauth.py
token = $AT
# The last oauth_token_secret output of xoauth.py
token_secret = $OA
EOF
chmod 600 ~/.xoauthrc

[simmel]

Thanks @zmughal!

I would have done that as:

umask 077
cat > ~/.xoauthrc <<EOF
# The last oauth_token output of xoauth.py
token = $AT
# The last oauth_token_secret output of xoauth.py
token_secret = $OA
EOF

to avoid the race condition of it being readable to everyone.

[simmel]

@ivucica I've decided not to implement logging as configureable. It now uses umask and appends uid to the filename.

Since XOAUTH is deprecated I really should create an XOAUTH2 lib but at first glance I didn't find any suitable C lib for it. As I said before, the quality for this code base is questionable at best.