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-2019-11250: TOB-K8S-001: Bearer tokens are revealed in logs #81114
Comments
|
/sig auth |
|
/remove-kind feature |
|
Should remote the "Authorization" header here? https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/client-go/transport/round_trippers.go#L424 |
for authorization headers, everything after the type should be masked (and potentially, only recognized auth types should be logged). Something like: knownAuthTypes := map[string]bool{
"bearer": true,
"basic": true,
"negotiate": true,
}
...
// Mask credential content from authorization headers
// https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Authorization
if strings.EqualFold(key, "Authorization") {
var authType string
if i := strings.Index(value, " "); i > 0 {
authType = value[0:i]
} else {
authType = value
}
if knownAuthTypes[strings.ToLower(authType)] {
if len(value) > len(authType) {
value = authType + " <masked>"
} else {
value = authType
}
} else {
value = "<masked>"
}
} |
|
I think people would be unpleasantly surprised to see credentials in a logfile after turning up logging to debug an issue. |
|
@wanghaoran1988 @liggitt |
|
@joelsmith This issue seems CVE-worthy to me: loss of confidentiality (bearer tokens) + cross of privilege boundary (debug log level could be set by admin, then logs read later by low privileged user). My draft cvss would be: CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N (5.3) |
|
Two potential vectors:
CVE-2019-11250 has been assigned to this issue. |
If you want to, go ahead |
|
@liggitt - should this have the official CVE feed label (added retrospectively, I mean)? |
probably? I have no idea how that label is supposed to get applied, but there appear to be several CVE issues that don't have it - https://github.com/kubernetes/kubernetes/issues?q=is%3Aissue+in%3Atitle+CVE+-label%3Aofficial-cve-feed+label%3Aarea%2Fsecurity |
|
@PushkarJ I think you're likely to know who to highlight this to. Sorry to mention you individually; please feel free to point out docs if there are any. |
|
/label official-cve-feed @sftim thanks for the tag, added the label now! |
|
@liggitt thanks for the useful filter. Currently in-scope issues are issues that were closed as fixed by code changes to k/k. So with that in mind, I have added the labels to some of the closed issues too that conform to the scope defined here: https://github.com/kubernetes/enhancements/tree/master/keps/sig-security/3203-auto-refreshing-official-cve-feed#summary |
This issue was reported in the Kubernetes Security Audit Report
Description
Kubernetes requires an authentication mechanism to enforce users’ privileges. One method of authentication, bearer tokens, are opaque strings used to associate a user with their having successfully authenticated previously. Any user with possession of this token may masquerade as the original user (the “bearer”) without further authentication.
Within Kubernetes, the bearer token is captured within the hyperkube kube-apiserver system logs at high verbosity levels (--v 10). A malicious user with access to the system logs on such a system could masquerade as any user who has previously logged into the system.
Exploit Scenario
Alice logs into a Kubernetes cluster and is issued a Bearer token. The system logs her token. Eve, who has access to the logs but not the production Kubernetes cluster, replays Alice’s Bearer token, and can masquerade as Alice to the cluster.
Recommendation
Short term, remove the Bearer token from the log. Do not log any authentication credentials within the system, including tokens, private keys, or passwords that may be used to authenticate to the production Kubernetes cluster, regardless of the logging level.
Long term, either implement policies that enforce code review to ensure that sensitive data is not exposed in logs, or implement logging filters that check for sensitive data and remove it prior to outputting the log. In either case, ensure that sensitive data cannot be trivially stored in logs.
Anything else we need to know?:
See #81146 for current status of all issues created from these findings.
The vendor gave this issue an ID of TOB-K8S-001 and it was finding 6 of the report.
The vendor considers this issue Medium Severity.
To view the original finding, begin on page 31 of the Kubernetes Security Review Report
Environment:
The text was updated successfully, but these errors were encountered: