[<prev] [next>] [day] [month] [year] [list]
Date: Mon, 11 May 2020 12:21:35 +0200
From: Matthias Gerstner <mgerstner@...e.de>
To: oss-security@...ts.openwall.com
Subject: oddjob: mkhomedir: CVE-2020-10737: race condition when copying
skeleton tree
Hello,
during a review [1] of oddjob [2] for inclusion in openSUSE Tumbleweed
I found a security issue in an accompanying utility called "mkhomedir".
Oddjob is a kind of D-Bus meta service to simplify the implementation of
specific D-Bus services. It allows to use simple command line utilities
to supply a D-Bus interface while all the D-Bus implementation details
are kept within the oddjob daemon and its configuration files.
A simple implementation of such a utility is shipped as part of oddjob
and is called "mkhomedir". It allows to create a user's home directory
if it doesn't exist yet. This logic can either be triggered via D-Bus or
via a simple pam_oddjob_mkhomedir PAM module. The D-Bus interface is by
default only accessible to the root user. If the PAM module is
configured then the logic can also be triggered by regular users
logging in, if they don't have an existing home directory yet.
This "mkhomedir" utility contains a race condition. The problem is found
in the copying of /etc/skel to a newly created home directory. The home
directory itself is created as a first step and ownership of it is
passed to the respective user. In a second step the skel directory is
recursively copied into the new home directory.
If the target user has the ability to run code during this operation
then he can setup a symlink attack. The following symlink, for example:
```
user $ ln -s /etc /home/user/bin
```
when created at the right time will cause the mkhomedir service to give
ownership of the /etc directory to the unpriviliged user, should
/etc/skel/bin exist. The reason is found in the call to `chown()` in
`oddjob_selinux_mkdir()` called in mkhomedir.c:157.
A potential attacker could try and login in parallel e.g. via SSH to win
this race condition. The probability to actually exploit this is low,
however, because once the home directory is created, there is no way to
repeat the attack. Chances could be higher in specialized setups where
new users without home directories can be repeatedly created without
special authentication requirements.
There can also be other symlink attack vectors when more deeply nested
/etc/skel directory structures are involved.
I reported this privately to upstream on 2020-04-24. The issue was
handled by the Red Hat Security team. They assigned CVE-2020-10737
for this issue. The upstream fix [3] for the issue is based on a
suggested patch that I included in my initial report to upstream. A
new minor release 0.34.5 has been created by upstream that includes this
fix. Coordinated disclosure of the issue took place around 2020-05-08.
[1]: https://bugzilla.suse.com/show_bug.cgi?id=1170459
[2]: https://pagure.io/oddjob
[3]: https://pagure.io/oddjob/c/10b8aaa1564b723a005b53acc069df71313f4cac?branch=master
Best regards
Matthias
--
Matthias Gerstner <matthias.gerstner@...e.de>
Dipl.-Wirtsch.-Inf. (FH), Security Engineer
https://www.suse.com/security
Phone: +49 911 740 53 290
GPG Key ID: 0x14C405C971923553
SUSE Software Solutions Germany GmbH
HRB 36809, AG Nürnberg
Geschäftsführer: Felix Imendörffer
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
