(RHEL-18776) CVE-2022-4415 systemd: local information leak due to systemd-coredump not respecting fs.suid_dumpable kernel setting #423
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
(cherry picked from commit 2c5d05b3cd986568105d67891e4010b868dea24f) Related: RHEL-18776
github-actions
bot
added
tracker/missing
Commit validationTracker - RHEL-18776 The following commits meet all requirements
Tracker validationSuccess🟢 Tracker RHEL-18776 has set desired product: Pull Request validationSuccess🟢 CI - All checks have passed Auto MergeFailed🔴 Pull Request has unsupported target branch Success🟢 Pull Request is not marked as draft and it's not blocked by |
…capabilities When the user starts a program which elevates its permissions via setuid, setgid, or capabilities set on the file, it may access additional information which would then be visible in the coredump. We shouldn't make the the coredump visible to the user in such cases. Reported-by: Matthias Gerstner <[email protected]> This reads the /proc/<pid>/auxv file and attaches it to the process metadata as PROC_AUXV. Before the coredump is submitted, it is parsed and if either at_secure was set (which the kernel will do for processes that are setuid, setgid, or setcap), or if the effective uid/gid don't match uid/gid, the file is not made accessible to the user. If we can't access this data, we assume the file should not be made accessible either. In principle we could also access the auxv data from a note in the core file, but that is much more complex and it seems better to use the stand-alone file that is provided by the kernel. Attaching auxv is both convient for this patch (because this way it's passed between the stages along with other fields), but I think it makes sense to save it in general. We use the information early in the core file to figure out if the program was 32-bit or 64-bit and its endianness. This way we don't need heuristics to guess whether the format of the auxv structure. This test might reject some cases on fringe architecutes. But the impact would be limited: we just won't grant the user permissions to view the coredump file. If people report that we're missing some cases, we can always enhance this to support more architectures. I tested auxv parsing on amd64, 32-bit program on amd64, arm64, arm32, and ppc64el, but not the whole coredump handling. (cherry picked from commit 3e4d0f6cf99f8677edd6a237382a65bfe758de03) Resolves: RHEL-18776
github-actions
bot
added
rhel-8.6.0
pr/changes-requested
and removed
tracker/missing
github-actions
bot
added
pr/needs-review
github-actions
bot
added
pr/needs-manual-merge
and removed
pr/needs-review
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I have cherry-picked three existing commits from the
rhel-8.7.0branch:Related prerequisities for 9fa7f77:
84a8245
e256e03
And the fix itself:
9fa7f77
Resolves: RHEL-18776