SanitizeFilePath in pkg/utils/utils.go validated that a path stayed under a safe directory by calling strings.HasPrefix(path, safedir). This is a lexical check, not a directory boundary check: /packages-extra/evil starts with
/packages, so it passed. The function did not enforce a path-separator boundary, so any sibling directory whose name began with the safe-directory string was accepted.
Callers included the builder's Clean handler (pkg/builder/builder.go:208) and the fetcher's Fetch / Upload handlers (pkg/fetcher/fetcher.go). A tenant who could pre-create or control a sibling directory under the fetcher /
builder's shared volume could induce a write or read outside the intended safe directory.
Affected
- Project:
github.com/fission/fission
- Versions: all versions through v1.24.0 with
SanitizeFilePath in the tree
- Audited commit:
647c141
- Component:
pkg/utils/utils.go:SanitizeFilePath
- Callers:
pkg/builder/builder.go:157,164,208, pkg/fetcher/fetcher.go:296,311,450,496,565,571
- Configuration: default; requires a sibling directory to the safe dir to exist on the filesystem
Fix section (paste into the Fix / Patches field)
Fixed in v1.25.0 by:
- PR #3445 (commit
8298e33e) — migrate every SanitizeFilePath call site (fetcher: storePath /
tmpPath / secretDir / configDir / rename + writeSecretOrConfigMap; builder: srcPkg / deployPkg path validation and srcPkg stat) to new pkg/utils/root.go helpers (RootJoin, RootStat, RootWriteFile, RootMkdirAll,
RootRename) that operate through os.Root. os.Root enforces directory confinement in the kernel and is recognized by CodeQL go/path-injection as a traversal barrier.
- PR #3446 (commit
5aac6f0b) — delete the deprecated SanitizeFilePath itself once no callers
remained. The vulnerable function no longer exists in the tree.
References
0xshdax Reporter
sanketsudake Remediation developer
SanitizeFilePathinpkg/utils/utils.govalidated that a path stayed under a safe directory by callingstrings.HasPrefix(path, safedir). This is a lexical check, not a directory boundary check:/packages-extra/evilstarts with/packages, so it passed. The function did not enforce a path-separator boundary, so any sibling directory whose name began with the safe-directory string was accepted.Callers included the builder's
Cleanhandler (pkg/builder/builder.go:208) and the fetcher'sFetch/Uploadhandlers (pkg/fetcher/fetcher.go). A tenant who could pre-create or control a sibling directory under the fetcher /builder's shared volume could induce a write or read outside the intended safe directory.
Affected
github.com/fission/fissionSanitizeFilePathin the tree647c141pkg/utils/utils.go:SanitizeFilePathpkg/builder/builder.go:157,164,208,pkg/fetcher/fetcher.go:296,311,450,496,565,571Fix section (paste into the Fix / Patches field)
Fixed in v1.25.0 by:
8298e33e) — migrate everySanitizeFilePathcall site (fetcher:storePath/tmpPath/secretDir/configDir/ rename +writeSecretOrConfigMap; builder:srcPkg/deployPkgpath validation andsrcPkgstat) to newpkg/utils/root.gohelpers (RootJoin,RootStat,RootWriteFile,RootMkdirAll,RootRename) that operate throughos.Root.os.Rootenforces directory confinement in the kernel and is recognized by CodeQLgo/path-injectionas a traversal barrier.5aac6f0b) — delete the deprecatedSanitizeFilePathitself once no callersremained. The vulnerable function no longer exists in the tree.
References