New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CVE-2015-7529 - predictable tmp files usage #696

Closed
bmr-cymru opened this Issue Dec 4, 2015 · 10 comments

Comments

Projects
None yet
2 participants
@bmr-cymru
Member

bmr-cymru commented Dec 4, 2015

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

This comment has been minimized.

Show comment
Hide comment
@bmr-cymru

bmr-cymru Dec 4, 2015

Member

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.

Member

bmr-cymru commented Dec 4, 2015

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 karibou self-assigned this Dec 9, 2015

@karibou

This comment has been minimized.

Show comment
Hide comment
@karibou

karibou Dec 9, 2015

Contributor

Assigning myself to track Ubuntu & Debian packaging

Contributor

karibou commented Dec 9, 2015

Assigning myself to track Ubuntu & Debian packaging

@karibou

This comment has been minimized.

Show comment
Hide comment
@karibou

karibou Dec 10, 2015

Contributor

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

Contributor

karibou commented Dec 10, 2015

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

@bmr-cymru

This comment has been minimized.

Show comment
Hide comment
@bmr-cymru

bmr-cymru Dec 10, 2015

Member

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

Member

bmr-cymru commented Dec 10, 2015

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

@bmr-cymru

This comment has been minimized.

Show comment
Hide comment
@bmr-cymru

bmr-cymru Dec 18, 2015

Member

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.

Member

bmr-cymru commented Dec 18, 2015

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 bmr-cymru assigned bmr-cymru and unassigned karibou and bmr-cymru Dec 21, 2015

@bmr-cymru

This comment has been minimized.

Show comment
Hide comment
@bmr-cymru

bmr-cymru Dec 21, 2015

Member

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.

Member

bmr-cymru commented Dec 21, 2015

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

This comment has been minimized.

Show comment
Hide comment
@bmr-cymru

bmr-cymru Dec 21, 2015

Member

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.

Member

bmr-cymru commented Dec 21, 2015

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

This comment has been minimized.

Show comment
Hide comment
@karibou

karibou Jan 4, 2016

Contributor

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

Contributor

karibou commented Jan 4, 2016

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

This comment has been minimized.

Show comment
Hide comment
@karibou

karibou Jan 5, 2016

Contributor

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

Contributor

karibou commented Jan 5, 2016

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

@bmr-cymru

This comment has been minimized.

Show comment
Hide comment
@bmr-cymru

bmr-cymru Jan 12, 2016

Member

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.

Member

bmr-cymru commented Jan 12, 2016

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.

@bmr-cymru bmr-cymru closed this Sep 7, 2016

@bmr-cymru bmr-cymru self-assigned this Sep 9, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment