This performs in effect an array lookup based on a secret value, the index of the token character in string validBootstrapTokenChars. This would in principle leak the index, and therefore the secret token character, via timing side-channels. The lookup based on index x, where x is val.Uint64(), could be replaced by a constant-time selection e.g. res := x + 48 + (39 & ((9 - x) >> 8)), then string(rune(res)).

thanks for the reply.
so we still generate a random index x := val.Uint64() but then use the simple operations to range lock it in the ASCII values for a-z and 0-9?

Yes, you keep the random index generation as is (val, err := rand.Int(rand.Reader, max)). Then, instead of performing an array lookup, you map x (val.Uint64) to the appropriate ASCII ranges using the operation above.

understood, thank you. i will update this as soon as possible in the next few days (not on a computer right now).

updated!

@gdncc do you think that it's worth using golang's crypto/subtle package for these comparisons?
https://pkg.go.dev/crypto/subtle#ConstantTimeLessOrEq

another question,
in the issue description we have:

Attackers may determine Bootstrap Token values based on timing-based side channels.

is that a case where the attacker has tapped into the protected process memory of a the running binary (e.g. kubeadm) run by the cluster administrator and they could intercept the tokens? that would imply that the host OS has a vulnerability.

i am giving kubeadm as an example, because kubeadm is the only core k8s consumer of the cluster-bootstrap library.
the way to generates a token is a one-shot operation of calling the randBytes(), generating a token and uploading it as a secret in etcd. the token is also validated in the process using IsValidBootstrapToken().
the token is also validated when the user specifies it (i.e. pre-generated by the user).

Using the crypto/subtle package is an option, but I can’t think of a compelling reason to switch.

To perform a timing side-channel attack, the attacker does not need to have access to the memory of the running binary e.g. access to a debugger.

Common processors use caches to speed up access to resources such as data and code. Attackers who can monitor the cache, for example from the host, or from a VM machine for code running on the host (e.g. a different process/user), or another VM on the same hypervisor than the attacker controlled VM, may observe changes in speed and cache behaviour, when resources that depend on sensitive information are used. This attack can reveal in principle the locations where the victim is accessing data (data flow), or the code the victim is running (control flow). The attacker leverages a signal which is measured through elapsed time. In the case of an array access at a secret address, this exercises caches and their contents, so that the memory access, but also other subsequent memory accesses elsewhere in the system, will be impacted (e.g. the actual array access kicked out of cache another data element, and a later access to that evicted element will be slower). This means that what the attacker actually measures can be other code running at a (slightly) later time.

Timing differences may also be observable from the network (e.g. how long it takes to validate the token). This is probably not exploitable in this case (although recent paper Out of the Box Testing discusses impressive results a few network hops from the target, or better, using the loopback interface).

Noting that this finding was classified as informational. There are also potential attenuating circumstances. Timing side-channel attacks are statistical; the attacker has to be able to do repeated experiments and somehow assemble together the small scraps of information they gathered. It would require additional research to determine whether it is exploitable, or not.

thanks for the context. this is quite interesting!