Skip to content
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

ATR-K8S-002: Non-constant time password comparison #81126

Closed
cji opened this issue Aug 8, 2019 · 2 comments

Comments

@cji
Copy link
Member

commented Aug 8, 2019

This issue was reported in the Kubernetes Security Audit Report

Description
The kube-apiserver includes multiple authentication backends for client request processing. These range in strength from client certificate authentication to simple HTTP Basic Authentication. When using a password (Basic Authentication), the kube-apiserver does not perform a secure comparison of secret values. In theory, this could allow an attacker to perform a timing attack on the comparison. For example, the AuthenticatePassword function simply performs string comparison to authenticate a user’s password (Figure 9.1).

func ( a* PasswordAuthenticator ) AuthenticatePassword ( ctx context . Context , username , password string ) (* authenticator . Response , bool , error ) {
	user, ok := a.users[username]
	if !ok {
		return nil , false , nil
	}
	if user.password != password {
		return nil , false , nil
	}
	return &authenticator.Response{User: user.info}, true , nil
}

Figure 9.1: Username and password authentication handling in passwordfile.go

Exploit Scenario
Alice runs a Kubernetes cluster in production. In order to support multiple organizational “customers,” she configures the cluster with HTTP Basic Authentication. Eve has a large number of username and password pairs for the organization, and uses the side-channel information from string comparison to tune her credential-stuffing attacks.

Recommendation
Short term, use a safe, constant-time comparison function such as crypto.subtle.ConstantTimeCompare. The comparison function should take the same amount of time regardless of matching prefix data within the password.

Long term, deprecate Basic Authentication in favor of more robust and secure options. Add documentation noting that any Basic Authentication is for use only in development scenarios, and not appropriate for production deployments. This will help users create a robust and secure default stance for all deployments.

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 ATR-K8S-002 and it was finding 18 of the report.

The vendor considers this issue Medium Severity.

To view the original finding, begin on page 55 of the Kubernetes Security Review Report

Environment:

  • Kubernetes version: 1.13.4

Fixed in v1.16.0 by #81152

@liggitt

This comment has been minimized.

Copy link
Member

commented Aug 8, 2019

/sig auth

@joelsmith

This comment has been minimized.

Copy link
Contributor

commented Aug 8, 2019

/area security
/kind bug
/remove-kind feature

@liggitt liggitt changed the title Non-constant time password comparison ATR-K8S-002: Non-constant time password comparison Aug 8, 2019

@liggitt liggitt added this to the v1.16 milestone Aug 9, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.