accountsservice drop privileges denial of service (GHSL-2020-187, GHSL-2020-188)
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
accountsservice (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
# GitHub Security Lab (GHSL) Vulnerability Report: `GHSL-2020-187`, `GHSL-2020-188`
The [GitHub Security Lab](https:/
We are committed to working with you to help resolve these issues. In this report you will find everything you need to effectively coordinate a resolution of these issues with the GHSL team.
If at any point you have concerns or questions about this process, please do not hesitate to reach out to us at `<email address hidden>` (please include `GHSL-2020-187` or `GHSL-2020-188` as a reference).
If you are _NOT_ the correct point of contact for this report, please let us know!
## Summary
The accountsservice daemon drops privileges to perform certain operations. For example while performing the `org.freedeskto
## Product
[accountsservice](https:/
## Tested Version
* accountsservice, version 0.6.55-
* Tested on Ubuntu 20.04.1 LTS
Note: I believe these issues only exist in Ubuntu's version of accountsservice. I couldn't find the vulnerable functions in the git repos maintained by [freedesktop](https:/
## Details
### Issue 1: accountsservice drop privileges `SIGSTOP` denial of service (`GHSL-2020-187`)
A [source code patch](https:/
```c
static gboolean
user_drop_
{
if (setresgid (user->gid, user->gid, -1) != 0) {
}
if (setresuid (accounts_
}
return TRUE;
}
```
This function is used to drop privileges while doing operations on behalf of an unprivileged user. Dropping the [EUID](https:/
The vulnerability can be triggered via multiple different D-Bus methods. Many of them involve precise timing to send the `SIGSTOP` signal at just the right moment. But there is a much simpler and more reliable way to reproduce the vulnerability by combining the privilege dropping vulnerability (`GHSL-2020-187`) with the infinite loop vulnerability (`GHSL-2020-188`), which is described next. So please see the description of `GHSL-2020-188`, below, for a proof-of-concept that triggers both vulnerabilities.
#### Impact
An unprivileged local user can cause a local denial of service that affects all users of the system. Stopping the accountsservice daemon prevents the login screen from working, because `gdm3` needs to talk to accounts-daemon (via D-Bus).
Unfortunately, the impact is worse than just local denial of service, because this vulnerability can be chained with a separate vulnerability in gdm3 to achieve privilege escalation. Please see the description of `GHSL-2020-188`, below, for a proof-of-concept of the privilege escalation vulnerability.
#### Remediation
When dropping privileges, only drop the EUID and not the RUID.
### Issue 2: accountsservice `.pam_environment` infinite loop (GHSL-2020-188)
A [source code patch](https:/
```c
static gboolean
is_in_pam_
{
gboolean ret = FALSE;
const gchar *prefix;
FILE *fp;
g_autofree gchar *pam_env = NULL;
if (g_strcmp0 (property, "Language") == 0)
else if (g_strcmp0 (property, "FormatsLocale") == 0)
else
pam_env = g_build_path ("/", accounts_
if (!user_
if ((fp = fopen (pam_env, "r"))) {
}
}
return ret;
}
```
This function parses the contents of a file named `.pam_environment` in the (unprivileged) user's home directory. The user can trigger an infinite loop by creating a symlink to `/dev/zero`:
```bash
ln -s /dev/zero ~/.pam_environment
```
The infinite loop can then be triggered by sending a D-Bus message to the accountsservice daemon:
```bash
dbus-send --system --dest=
```
Because the accountsservice daemon is now stuck in an infinite loop, and has dropped privileges, it is now easy to also demonstrate `GHSL-2020-187`:
```bash
kill -SIGSTOP `pidof accounts-daemon`
```
The accountsservice daemon is now unresponsive, which means that the GNOME login screen no longer works. Unfortunately, this vulnerability can be chained with a separate vulnerability in gdm3 (which I have reported simultaneously to GNOME) to get privilege escalation. The steps (tested on Ubuntu Desktop 20.04.1 LTS) are as follows:
* An unprivileged user logs into their account.
* They send a `SIGSTOP` to accountsservice, using the instructions above.
* They log out of their account.
* They open a text console (usually with a key combination such as Ctrl-Alt-F3).
* They login to the text console.
* They send accounts-daemon a `SIGSEGV`, followed by a `SIGCONT`, which causes accounts-daemon to crash.
* Because the accountsservice daemon was unresponsive, gdm3 is under the mistaken impression that there are zero user accounts on the system. So it triggers `gnome-
* The user clicks through the `gnome-
I have made a video of this proof-of-concept, which you can see [here](https:/
#### Impact
An unprivileged local user can cause a local denial of service that affects all users of the system. Making the accountsservice daemon unresponsive prevents the login screen from working, because `gdm3` needs to talk to accounts-daemon (via D-Bus).
Unfortunately, the impact is worse than just local denial of service, because this vulnerability can be chained with a separate vulnerability in gdm3 to achieve privilege escalation, as explained in the proof-of-concept above.
#### Remediation
I would recommend using `fstat` to check that the file is a regular file before reading it.
## Credit
These issues were discovered and reported by GHSL team member [@kevinbackhouse (Kevin Backhouse)](https:/
## Contact
You can contact the GHSL team at `<email address hidden>`, please include a reference to `GHSL-2020-187` or `GHSL-2020-188`in any communication regarding this issue.
## Disclosure Policy
This report is subject to our [coordinated disclosure policy](https:/
CVE References
information type: | Private Security → Public Security |
Thanks for reporting these issues, we are currently investigating them and will be assigning CVEs shortly.