Summary
Fission's buildermgr controller processed Package CRDs without verifying that Package.spec.environment.namespace matched Package.metadata.namespace.
Details
An attacker with packages.fission.io/create in their own namespace could set spec.environment.namespace to any other tenant's namespace. The controller then used its high-privilege service account to fetch the Environment
cross-namespace and dispatch the build command into the victim namespace's builder pod.
The build command's stdout is written verbatim into Package.status.buildlog. By running malicious code through an npm preinstall lifecycle hook (or any equivalent build step), the attacker could read the victim namespace's
fission-builder Bearer token from inside that builder pod and surface it through the build log — then use the leaked token to read every Secret and ConfigMap in the victim namespace.
Impact
Cross-tenant compromise: a package author in one namespace could execute code inside another tenant's builder pod and exfiltrate that namespace's fission-builder service-account token, giving namespace-wide secret and configmap read in
the victim namespace.
Fix
Fixed in #3379 and released in v1.24.0. Two checks in series:
- Admission webhook (
pkg/webhook/package.go::Validate) rejects Package.spec.environment.namespace != Package.metadata.namespace. An empty namespace is still accepted; the controllers default it to the package's own namespace.
- Controller belt-and-braces: the same check is repeated in
pkg/buildermgr/pkgwatcher.go::build and pkg/buildermgr/common.go::buildPackage before the cross-namespace Environments(...).Get call, so a stale Package CR or a
webhook-bypass cluster (failurePolicy=Ignore) cannot exploit the primitive either.
Behavioural change
Packages that explicitly set spec.environment.namespace to a different namespace are now rejected at admission. Empty-string remains accepted (resolves to the package's own namespace, the same as the prior implicit behaviour).
References
j311yl0v3u Reporter
b0b0haha Reporter
sanketsudake Remediation developer
Summary
Fission's
buildermgrcontroller processedPackageCRDs without verifying thatPackage.spec.environment.namespacematchedPackage.metadata.namespace.Details
An attacker with
packages.fission.io/createin their own namespace could setspec.environment.namespaceto any other tenant's namespace. The controller then used its high-privilege service account to fetch the Environmentcross-namespace and dispatch the build command into the victim namespace's builder pod.
The build command's stdout is written verbatim into
Package.status.buildlog. By running malicious code through an npmpreinstalllifecycle hook (or any equivalent build step), the attacker could read the victim namespace'sfission-builderBearer token from inside that builder pod and surface it through the build log — then use the leaked token to read every Secret and ConfigMap in the victim namespace.Impact
Cross-tenant compromise: a package author in one namespace could execute code inside another tenant's builder pod and exfiltrate that namespace's
fission-builderservice-account token, giving namespace-wide secret and configmap read inthe victim namespace.
Fix
Fixed in #3379 and released in v1.24.0. Two checks in series:
pkg/webhook/package.go::Validate) rejectsPackage.spec.environment.namespace != Package.metadata.namespace. An empty namespace is still accepted; the controllers default it to the package's own namespace.pkg/buildermgr/pkgwatcher.go::buildandpkg/buildermgr/common.go::buildPackagebefore the cross-namespaceEnvironments(...).Getcall, so a stale Package CR or awebhook-bypass cluster (
failurePolicy=Ignore) cannot exploit the primitive either.Behavioural change
Packages that explicitly set
spec.environment.namespaceto a different namespace are now rejected at admission. Empty-string remains accepted (resolves to the package's own namespace, the same as the prior implicit behaviour).References