Bug 1170459 - (CVE-2020-10737) AUDIT-FIND: CVE-2020-10737: oddjob-mkhomedir: race condition when copying skeleton tree
(CVE-2020-10737)
AUDIT-FIND: CVE-2020-10737: oddjob-mkhomedir: race condition when copying ske...
Status: RESOLVED FIXED
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Security
Current
Other Other
: P5 - None : Normal (vote)
: ---
Assigned To: Sasi Olin
E-mail List
:
Depends on:
Blocks: 1169494
  Show dependency treegraph
 
Reported: 2020-04-24 13:41 UTC by Matthias Gerstner
Modified: 2020-05-13 09:31 UTC (History)
4 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Matthias Gerstner 2020-04-24 13:41:04 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.
Comment 1 Matthias Gerstner 2020-04-24 13:43:04 UTC
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.
Comment 2 Matthias Gerstner 2020-04-24 13:48:34 UTC
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.
Comment 3 Matthias Gerstner 2020-04-24 13:49:44 UTC
CRD: 2020-07-23 14:00 UTC
Comment 4 Matthias Gerstner 2020-04-27 11:31:34 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.
Comment 5 Matthias Gerstner 2020-05-07 11:23:12 UTC
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.
Comment 6 Matthias Gerstner 2020-05-08 08:39:37 UTC
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.
Comment 7 Sasi Olin 2020-05-10 13:42:02 UTC
(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
Comment 8 Matthias Gerstner 2020-05-11 09:41:19 UTC
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.
Comment 9 Matthias Gerstner 2020-05-11 11:40:26 UTC
I've also posted a summary about this finding on oss-sec:

https://www.openwall.com/lists/oss-security/2020/05/11/1