CVE-2021-22571: setting file permissions on datastore directory by KatTraxler · Pull Request #15 · google/sa360-webquery-bigquery

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

setting file permissions on datastore directory #15

Conversation 6 Commits 1 Checks 1 Files changed

Conversation

You are using the File API to create a directory (‘datastore’) which ultimately stores OAuth2 credentials. Utilizing methods on the File API, I was able to set the read and write permission on that directory to restrict the permission to the owner of the directory. This change doesn’t really fix the issue.

It appears as though the creation of the file which stores the credentials (‘StoredCredentials’) is being handled by the [com.google.auth.oauth2.UserCredentials](https://googleapis.dev/java/google-auth-library/0.23.0/index.html) Class. I don’t see any native capability to set file permissions in this library.

You might need to migrate to a different method of creating the ‘StoredCredentials’ file, one that allows more control of the StoredCredentials File or request an upgrade to the underlying library.

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you’ll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you’ve signed (or fixed any issues), please reply here with @googlebot I signed it! and we’ll verify it.

What to do if you already signed the CLA****Individual signers

• It’s possible we don’t have your GitHub username or you’re using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.

Corporate signers

• Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don’t know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot (Public version).
• The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
• The email used to register you as an authorized contributor must also be attached to your GitHub account.

ℹ️ Googlers: Go here for more info.

anantdamle linked an issue that may be closed by this pull request

Feb 17, 2021

@KatTraxler Thanks for this PR. Can you sign the CLA and update this conversation.
I am curious to learn if this approach will allow running the JAR file through cron

Thanks @KatTraxler for the PR.
This solution does not solve the issue completely.

Do you think one of the following may be a better solution:

1. accepting datastore folder as an input parameter. Allows the user to setup protections outside of the code.
2. Removing the stored credentials. Use service account credentials to access all services including SA360.

Hi @anantdamle
I don’t imagine either of the options would address the underlying issue:

Option 1: accepting datastore folder as an input parameter. Allows the user to setup protections outside of the code.
The users OAuth credentials are contained in the ‘StoredCredentials’ file, in the ‘datastore’ directory. If instead of creating the ‘datastore’ directory in code, the user was asked to provide a directory, the resultant file where the OAuth credentials are stored is still created by com.google.auth.oauth2.UserCredentials Class and is still the same ‘StoredCredentials’ file with insecure permissions.
Option 2: Removing the stored credentials. Use service account credentials to access all services including SA360.
I’m assuming proposal entails generating a private key for a service account? If that’s the case, this solution would likely be worse than the current state. Today, the credentials that are stored insecurely are considered 'short-term’. They will always have an expiration.
Changing this application to have the ability to run as a service account would result in durable credentials being stored on a local file system where if not explicitly set, the default and insecure set of file permissions are -rw-r--r--

Recommendation:
Open an issue with the maintainers of the Java google-auth-library asking if there is a Method on the Class com.google.auth.oauth2.UserCredentials allowing you configure the permissions on the file which is created when OAuth2 credentials are generated.

@KatTraxler Thanks for notifying of the bug and proposing a PR. This is a temporary solution. Long term solution is fixing Issue#8. Will work on building that solution.
Directory level permissions would not fix the file permissions.

anantdamle linked an issue that may be closed by this pull request

Feb 23, 2021

2 participants