Impact

Developers using a malicious or compromised third-party buildpack could expose their registry credentials or local docker socket to a malicious lifecycle container. One such vulnerability path would look like:

1. A malicious attacker publishes a language framework, including both a function builder and buildpack (referenced by tag), and function templates referencing the builder and buildpack. The builder image would need to share a registry prefix with one of the image registry namespaces trusted by func. The image name would look like gcr.io/paketo-buildpacks-for-language/builder:latest.
2. A victim uses the function template to create a new function project, incorporating the tag-referenced builder.
3. The attacker updates the builder tag to point to a builder image which references a malicious lifecycle image. (The attacker could also publish a malicious lifecycle image in step 1, but that compromise might be easier to detect.)
4. When the victim next performs a func build operation (including when pushing code remotely or running it locally with run), the attacker's lifecycle image will be run with either:

• Publishing to a remote registry: Mounted registry credentials for the destination, cache, and run image repositories (any of which may be read-write)
• Pushing to the local docker daemon: Access to the local docker daemon through the docker control socket, with the ability to launch further containers with local access.

Patches

This issues has been patched in PR #1442, and is part of release 1.8.1

Workarounds

This issue only affects users who are using function buildpacks from third-parties; pinning the builder image to a specific content-hash with a valid lifecycle image will also mitigate the attack.

References

Func trusted builder prefixes:

For more information

If you have any questions or comments about this advisory:

• Open an issue in knative/func
• Email us at [email protected]