Bugzilla – Bug 1170459
AUDIT-FIND: CVE-2020-10737: oddjob-mkhomedir: race condition when copying skeleton tree
Last modified: 2020-05-13 09:31:07 UTC
+++ This bug was initially created as a clone of Bug #1169494
The problem is found in the copying of /etc/skel to a newly created home
directory. There is a race condition since the home directory itself is
created as a first step and ownership passed to the respective user. In
a second step the skel directory is recursively copied into the new home
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 `chown()` in
`oddjob_selinux_mkdir()` called in mkhomedir.c:157.
Since there is also the PAM module for mkhomedir there is the
theoretical possibility for an attacker that does not have a home
directory yet to try and login in parallel e.g. via SSH and win this
race condition. The probability to actually exploit this is surely low,
because after the home directory is created, there is no way to reach
the code in question again. But the issue should be fixed nonetheless.
There can also be other symlink attack vectors when more deeply nested
/etc/skel directory structures are involved.
To fix this I'm seeing two possibilities:
- the hard one would be to only very carefully create new files in the
target home directory by using openat() starting from the home
directory using O_PATH, fstatat() & friends to make sure that no
symlinks are involved in the further path components.
- an easier approach would probably be to create the home directory but
have it only accessible to the root user until the /etc/skel tree is
completely copied over. Only then the home directory should be given
to the target user.
So this is the finding from bug 1169494. It's actually not that severe I think
but let's try to get it fixed before adding the package to Factory. I will
report the issue to upstream. I also have a suggested patch available.
However we shouldn't publish the patch and any other related information
before upstream had a chance to react. Maybe they want to make use of the
This is an embargoed bug. This means that this information is not public. Please
- do not talk to other people about this unless they're involved in fixing the issue
- do not submit this into OBS (e.g. fix Leap) until this is public
- do not make this bug public
In doubt please talk to us on IRC (#security), RocketChat (#security) or send us a mail.
CRD: 2020-07-23 14:00 UTC
The upstream developer replied to me by now. He will assign a CVE and involve
RedHat security. He also wants to follow the approach of the patch I supplied
So hopefully we can deal with this quickly.
RedHat security took a while to react. They now confirmed the issue and we're
discussing the rest of the process. They'll assign a CVE on their side. It
looks like we're agreeing to make it public right away once the CVE is there.
Upstream assigned a CVE and the bugfix is published now at .
There should also be a new release. When you package this new version I can
whitelist the items from bug 1169494.
(In reply to Matthias Gerstner from comment #6)
> There should also be a new release. When you package this new version I can
> whitelist the items from bug 1169494.
Package was updated and resubmitted to openSUSE:Leap:15.2 and openSUSE:Factory
The disclosure process with upstream is finished now.
The newly packaged version 0.34.5 contains the necessary fix.
NOTE to reactive security: this package and the related bug have never been in
Factory, therefore SUSE products aren't affected.
Closing as FIXED.
I've also posted a summary about this finding on oss-sec: