GmsCore: GmsCore leaking Google account password on login

Thanks @flawedworld for pointing out that this has been around for 7 years.

https://github.com/microg/GmsCore/blob/96cfe2bd9b1798511ea6eb31434049c08b47584a/play-services-core/src/main/java/org/microg/gms/auth/login/LoginActivity.java#L445

amogus sus

Hey guys, I have a workaround for everyone: don’t give adb access to anyone you don’t trust! adb lets you do all kinds of bad things.

Also, if you think leaking the password to adb log is bad, I have even worse news for you. MicroG also sends your password over the internet, to a company known for making money off of users’ data: Google!

But seriously: yes, it’s a bug, but it’s not the end of the world. @dimaryaz

This is a highly nonsensical and unproductive comment. You’re comparing something all protected by TLS to a password being stored and logged in plain text, not hashed or anything. ADB is not required to get logs from logcat either. Selecting the bug report option in Developer Options will dump logs.

Edit: There is also a READ_LOGS permission for apps to read logs. This is not strictly an ADB issue.

Pretty sus

NSA connection confirmed.

Lol they were joking becuase they said but seriously @SoupSucker

This isn’t the place for jokes. Not productive at all.

… as they said at Chernobyl: “Whoopski.”

Hey guys, I have a workaround for everyone: don’t give adb access to anyone you don’t trust! adb lets you do all kinds of bad things.

Also, if you think leaking the password to adb log is bad, I have even worse news for you. MicroG also sends your password over the internet, to a company known for making money off of users’ data: Google!

But seriously: yes, it’s a bug, but it’s not the end of the world.

Apps aren’t supposed to log sensitive data to the system logs primarily due to them often being shared as part of OS bug reports. Many operating systems have a feature for submitting bug report zips which include the system logs. It’s a minor issue especially relative to much more serious problems that are present. Should worry about properly enforcing the Play services API security model and transport security rather than this.

READ_LOGS is signature|privileged|development meaning that it can be granted based on having at least one of those 3 things. It’s not solely a privileged permission. The development tag means it can be granted dynamically via persistent state normally set via adb shell. It’s also relevant in the verified boot threat model since it’s stored as persistent state. Platform signature is also another option. The reason for the privileged system requiring explicit whitelisting now is because those may be third party apps and it’s undesirable for them to be able to simply add more privileged permissions in updates based on them being a priv-app without explicit approval by the OS.

Regarding the READ_LOGS permission, as this has also recently been a topic regarding Exposure Notification’s RPIs, Marvin posted this information to the CCTG chatroom:

I think there is a lot of misconception how privileged permissions work on Android.

1. Apps must put the permission request directly in a manifest file. Google does not allow apps in Play Store to request privileged permissions without explanation.
2. Privileged permissions are only granted to apps that are part of the system image and have the permission request in the app version that is on the system image (= updates to system image apps cannot get access to more privileged permissions).
3. Since Android 4.4, apps that want to get a privileged permission must not only be part of the system image (ROM), but also need to reside in a special folder “priv-app”. Manufacturers should not put third-party apps in this folder except if there is a very good reason.
4. Since Android 8.0, even if a manufacturer would accidentally put an untrusted third-party app in “priv-app”, privileged permissions would not be granted as long as the manufacturer does not explicitly allowlist the specific privileged permission to that app through a configuration file in the system image.

The only risk that I personally can see here is that the password is accidentally sent to a vendor through a custom bug report feature, or using the system Bug Report feature to whomever the report is sent.

Hey guys, I have a workaround for everyone: don’t give adb access to anyone you don’t trust! adb lets you do all kinds of bad things.

Also, if you think leaking the password to adb log is bad, I have even worse news for you. MicroG also sends your password over the internet, to a company known for making money off of users’ data: Google!

But seriously: yes, it’s a bug, but it’s not the end of the world.

I am not sure what you are saying. You are literally using a Google account, Google has control over your Google account. It’s not “bad” or “good”. It’s just how it is. It doesn’t matter if MicroG sends your Google account password to Google or not, so long as its encrypted during transport.

Storing passwords in plain text in any form, waiting to be extracted, is a big issue however.

So… just to confirm, does it only post the account credentials to the log during the activity of actually adding a new google account to the device? That’s the only time I saw it doing that. It doesn’t just repeatedly print it even if you’re not modifying/adding more Google accounts, correct? In which case, until microG is updated with the logging removed, the practical security measure for most folks is “format userdata, flash your rom & preferred (minimal!) microG package, factory reset, make sure you’re not plugged into the computer, reboot to system for first boot setup, connect to wifi/mobile data and log in to any/all Google accounts you plan to have on the device, reboot so the logcat buffer gets cleared, and THEN you can go about installing things like magisk for root if desired or any 3rd party apps… and then don’t add any more Google accounts so it never invokes the microG gmscore account authentication activity again, unless you factory reset and wipe userdata first.” … right?

Thanks @flawedworld for pointing out that this has been around for 7 years.

https://github.com/microg/GmsCore/blob/96cfe2bd9b1798511ea6eb31434049c08b47584a/play-services-core/src/main/java/org/microg/gms/auth/login/LoginActivity.java#L445

Doesn’t fix the root of the problem, but it works (kinda)…

Hey guys, I have a workaround for everyone: don’t give adb access to anyone you don’t trust! adb lets you do all kinds of bad things. Also, if you think leaking the password to adb log is bad, I have even worse news for you. MicroG also sends your password over the internet, to a company known for making money off of users’ data: Google! But seriously: yes, it’s a bug, but it’s not the end of the world.

I am not sure what you are saying. You are literally using a Google account, Google has control over your Google account. It’s not “bad” or “good”. It’s just how it is. It doesn’t matter if MicroG sends your Google account password to Google or not, so long as its encrypted during transport.

Storing passwords in plain text in any form, waiting to be extracted, is a big issue however.

Lol they were joking becuase they said but seriously

Just confirmed this for myself. This is a pretty serious bug, might want to get on this soon.