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 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 `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 embargo.
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 to him. 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 [1]. [1]: https://pagure.io/oddjob/c/10b8aaa1564b723a005b53acc069df71313f4cac 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 https://build.opensuse.org/package/show/security:idm/oddjob
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: https://www.openwall.com/lists/oss-security/2020/05/11/1