CVE-2015-7529 - predictable tmp files usage

[bmr-cymru]

Mateusz Guzik reports that sos-3.x is vulnerable to symbolic link attacks since it uses predictable temporary file names in the configured --tmp-dir location. If this location is shared with other users (the default on most distributions) then it is possible for a malicious user to obtain content from the archive and in some circumstances to execute arbitrary commands with administrative privileges.

There are two recommended mitigations for these attacks:

• Use a private temporary directory (all versions, all kernels)

Instead of using the default system temporary directory (/tmp, /var/tmp) use a private directory that excludes non-administrative users from searching or reading the directory contents, e.g.:

# mkdir /var/tmp/sos
# chmod 700 /var/tmp/sos
# sosreport --tmp-dir /var/tmp/sos

Note that the chmod is not strictly necessary assuming the root user's umask is set appropriately.

• Enable kernel link protection (partial mitigation, requires kernel support)

Recent kernels support the protected_symlinks feature that can be used to mitigate this class of attack and this is enable by default by most distributions that support the feature:

   /proc/sys/fs/protected_symlinks (since Linux 3.6)
      When the value in this file is 0, no restrictions are placed on following
      symbolic links (i.e., this is the historical behavior before Linux 3.6). 
      When  the value in this file is 1, symbolic links are followed only in
      the following circumstances:

       *  the  filesystem UID of the process following the link matches the
          owner (UID) of the symbolic link (as described in credentials(7),
          a process's filesystem UID is normally the same as its effective UID);

      *  the link is not in a sticky world-writable directory; or

      *  the symbolic link and its parent directory have the same owner (UID)
       A system call that fails to follow a symbolic link because of the above
       restrictions returns the error EACCES in errno.

      The default value in this file is 0.  Setting the value to 1 avoids a
      longstanding class of security issues based on time-of-check,  time-of-use
      races  when accessing symbolic links.

Note that relying on the protect_symlinks feature does not entirely eliminate risk: an attacker could create a regular file that they own (in place of the output file sos expects to create) and use this to obtain archive content that would not normally be exposed to their user and group ID.

Users of sosreport are recommended to use an alternate --tmp-dir setting whenever possible.

A fix for this problem is currently in master and will be included in the next sos release. This may be backported to earlier releases carried by distributions. Concerned users should contact their distribution's normal support channels for information regarding updated packages to fix this flaw.

[bmr-cymru]

The following sequence of commits addresses this problem in master:

4a9b919 [sosreport] prepare report in a private subdirectory
19e2bbc [sosreport] move archive checksumming to sosreport
7f27277 [policies] refactor Policy.display_results() args
6038fdf [policies] move hash determination to policies

I'll leave this issue open for now until we've had time to coordinate with distributions and users to incorporate these changes.

[karibou]

Assigning myself to track Ubuntu & Debian packaging

[karibou]

FYI, upon normal completion, the private tmpdir is left empty in /tmp and not removed. Is this something we should worry about ?

[bmr-cymru]

Urgh. This regressed when I did some 'safe' refactoring before pushing to master - now fixed in commit 08121d8, thanks!

[bmr-cymru]

Updated packages with the fix for CVE-2015-7529 have been submitted to the Fedora updates system:

F23
F22
rawhide

Please test & comment or give karma in bhodi.

[bmr-cymru]

Huh, thought GitHub allowed multiple assignments but apparently not; let's leave this unassigned for now. If particular distro maintainers need another place to track issues (other than the respective distro bugzilla) then we can open up new issues that reference this one.

[bmr-cymru]

Please post links to other updated distro packages here - once we have things in motion for all the major ones we can close this tracker out.

[karibou]

CVE uploaded to all Ubuntu supported releases : http://people.canonical.com/~ubuntu-security/cve/2015/CVE-2015-7529.html
Uploaded to Debian testing & unstable. Need to research how to get stable fixed

[karibou]

Turns out that Debian stable does not require the fix so all ends covered for Debian/Ubuntu

[bmr-cymru]

Thanks @karibou! I think we have pretty much all the supported distros covered now - RHEL errata are on the way, Fedora 22, 23 and rawhide have the fix so I think we can close this out now unless there's something I've missed?

Alternately we can keep this open until 3.3 is released - I put this back on hold over the break as I didn't think it was a good idea to drop a new upstream release when everyone was heading out for the break. If we have no other issues this week we should be in shape to make 3.3 final mid next week.