Impact

Any user with read/write access to the backup storage location (e.g. an S3 bucket) can manipulate backup manifest files so that arbitrary code is later executed when that backup is restored. This can be used to provide that attacker with unintended/unauthorized access to the production deployment environment — allowing them to access information available in that environment as well as run any additional arbitrary commands there.

Patches Fixes are expected to be released with versions v23.0.3 and v22.0.4 See fix commit at https://github.com/vitessio/vitess/commit/4c0173293907af9cb942a6683c465c3f1e9fdb5c

Workarounds

If maintainers intended to use an external decompressor then they can always specify that decompressor command in the --external-decompressor flag value for vttablet and vtbackup. That then overrides any value specified in the manifest file.

If maintainers did not intend to use an external decompressor, nor an internal one, then they can specify a value such as cat or tee in the --external-decompressor flag value for vttablet and vtbackup to ensure that a harmless command is always used.

References

Users can read more about the issue here: https://github.com/vitessio/vitess/issues/19459

Vitess is a database clustering system for horizontal scaling of MySQL through generalized sharding. Prior to version 16.0.2, users can either intentionally or inadvertently create a shard containing / characters from VTAdmin such that from that point on, anyone who tries to create a new shard from VTAdmin will receive an error. Attempting to view the keyspace(s) will also no longer work. Creating a shard using vtctldclient does not have the same problem because the CLI validates the input correctly. Version 16.0.2, corresponding to version 0.16.2 of the go module, contains a patch for this issue. Some workarounds are available. Always use vtctldclient to create shards, instead of using VTAdmin; disable creating shards from VTAdmin using RBAC; and/or delete the topology record for the offending shard using the client for your topology server.

Impact Users can either intentionally or inadvertently create a keyspace containing / characters such that from that point on, anyone who tries to view keyspaces from VTAdmin will receive an error. Trying to list all the keyspaces using vtctldclient GetKeyspaces will also return an error. Note that all other keyspaces can still be administered using the CLI (vtctldclient).

Patches v16.0.1 (corresponding to 0.16.1 on pkg.go.dev)

Workarounds Delete the offending keyspace using a CLI client (vtctldclient) vtctldclient --server ... DeleteKeyspace a/b

Found during a security audit sponsored by the CNCF and facilitated by OSTIF.