Open justledbetter opened 3 years ago
Was wondering how long this would take to break someone. Thanks for reporting and doing the investigation!
As mentioned in #590 we are relying on the k3s install.sh capture of k3s-related environment variables and that processing does not currently support whitespace nor shell-relevant special characters (such as !
) in tokens. Until a fix lands with k3s the work-around will be to use dashes as separators instead of spaces.
Version (k3OS / kernel)
k3os version v0.20.6-k3s1r0 5.4.0-72-generic #80 SMP Tue May 4 19:31:44 UTC 2021
Architecture
x86_64
Describe the bug When specifying a passphrase as the k3s service token (containing spaces), the token is not properly quoted in the startup configuration, causing a heavily truncated token to be used by the cluster.
To Reproduce
Expected behavior
As this is a development environment, I wasn't expecting to provide a super secure token; but I wanted it to be more secure than a semi-random string of 15 characters. And without copy/paste, wanted something that was relatively easy to type.
Actual behavior
The following error messages appear in the k3os startup logs:
Note that this causes the environment to run with the actual token
this
, which is critically insecure.Additional context
I'm not sure if anyone ever expected to see spaces in k3s service tokens, but didn't find any documentation to suggest that they're forbidden either here or in the k3s repo.
https://resources.infosecinstitute.com/topic/password-security-complexity-vs-length
I believe this behavior was caused by Issue #590.
This is roughly the line that is causing the problem: https://github.com/dweomer/k3os/blob/master/pkg/cc/funcs.go#L132
A proper fix might be to change any line that creates an environment variable within a shell script to read: