-
Notifications
You must be signed in to change notification settings - Fork 39.8k
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-2017-1002101 - subpath volume mount handling allows arbitrary file access in host filesystem #60813
Comments
@liggitt: There are no sig labels on this issue. Please add a sig label. A sig label can be added by either:
Note: Method 1 will trigger an email to the group. See the group list. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
[MILESTONENOTIFIER] Milestone Issue: Up-to-date for process Note: This issue is marked as Example update:
Issue Labels
|
Automatic merge from submit-queue. If you want to cherry-pick this change to another branch, please follow the instructions <a href="https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md">here</a>. subpath fixes fixes #60813 for master / 1.10 ```release-note Fixes CVE-2017-1002101 - See https://issue.k8s.io/60813 for details ```
This article states that: Does this mean all versions between 1.7.0 and 1.17.13 are vulnerable? For example, is 1.17.6 vulnerable? |
anything between 1.7.0 and 1.7.13 are vulnerable, including 1.7.6 |
/label official-cve-feed (Related to kubernetes/sig-security#1) |
CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
This vulnerability allows containers using subpath volume mounts with any volume type (including non-privileged pods, subject to file permissions) to access files/directories outside of the volume, including the host’s filesystem.
Thanks to Maxim Ivanov for reporting this problem.
Vulnerable versions:
Vulnerable configurations:
Vulnerability impact:
A specially crafted pod spec combined with malicious container behavior can allow read/write access to arbitrary files outside volumes specified in the pod, including the host’s filesystem. This can be accomplished with any volume type, including emptyDir, and can be accomplished with a non-privileged pod (subject to file permissions).
Mitigations prior to upgrading:
Prevent untrusted users from creating pods (and pod-creating objects like deployments, replicasets, etc), or disable all volume types with PodSecurityPolicy (note that this prevents use of service account tokens in pods, and requires use of
automountServiceAccountToken: false
)Fixed versions:
Action Required:
In addition to upgrading, PodSecurityPolicy objects designed to limit container permissions must completely disable hostPath volumes, as the allowedHostPaths feature does not restrict symlink creation and traversal. Future enhancements (tracked in issue #61043) are required to limit hostPath use to read only volumes or exact path matches before a PodSecurityPolicy can effectively restrict hostPath usage to a given subpath.
Known issues:
The text was updated successfully, but these errors were encountered: