Unable to scan OCI images with syft v0.105.1

[sophiewigmore]

What happened:

Hey there,
We recently bumped to v0.105.1, and scanning OCI archives is no longer working. It was previously working with v0.105.0.

• Command we ran: syft scan build/run.oci --output cyclonedx-json=syft-output.json
• Output:

failed to construct source from user input "build/run.oci": unable to load image: unable to use OciTarball source: failed to visit tar entry="." : potential path traversal attack with entry: "."

Any ideas if we're doing something wrong, or if this is just a bug? I didn't see anything concerning in the CHANGELOG for v0.105.1, except potentially #2664

What you expected to happen:

Scanning succeeds as usual

Steps to reproduce the issue:

1. Get an OCI archive
2. Run syft scan <OCI archive> --output cyclonedx-json=syft-output.json

Anything else we need to know?:

Environment:

• Output of syft version:

Application: syft
Version:    0.105.1
BuildDate:  2024-02-26T16:52:59Z
GitCommit:  928511ea0f1449e057e8057e38743d258b22476b
GitDescription: v0.105.1
Platform:   darwin/amd64
GoVersion:  go1.21.7
Compiler:   gc

[spiffcs]

Thanks for the heads up on this @sophiewigmore! Let me try and reproduce this and come back with an answer as to the cause.

I'll also try and get a fix filed asap after determining the failure is for the generic OCI case.

Update: I did the most basic oci image I could think of:

FROM alpine:latest

docker buildx build --output type=oci . > alpine.tar

❯ syft scan alpine.tar --output cyclonedx-json=syft-output.json
 ✔ Parsed image                                                     sha256:4e53321e14aaf87b17329102a21d4388fd9bea986277a78a8aa13bd300c9e3f9
 ✔ Cataloged contents                                                      43b13813161da7f0ded631e38111c4210167109c4d87bda0cae4f5e974e93f83
   ├── ✔ Packages                        [15 packages]
   ├── ✔ File digests                    [80 files]
   ├── ✔ File metadata                   [80 locations]
   └── ✔ Executables                     [17 executables]

It looks like syft still does pass for the generic <OCI archive> case, but only when there is no tar entry for "."

I'm going to pull down https://github.com/paketo-buildpacks/jammy-full-stack specifically to try and find the error.

The change for this in syft came from:
anchore/stereoscope#223

It looks like the unarchiver is being told that a potential escape is possible via the . path entry for a given tar index entry. This seems like incorrect behavior.

[spiffcs]

PR filed in stereoscope - anchore/stereoscope#225

[spiffcs]

Fix pulled in here: #2683

[spiffcs]

Confirmed fix by pulling the affect build-pack from
https://github.com/paketo-buildpacks/jammy-full-stack/releases/tag/v0.1.22

[I] hal@CPHILLIPS ~/GolandProjects/syft (update-stereoscope)
❯ go run cmd/syft/main.go scan jammy-full-stack-0.1.22-build.oci --output cyclonedx-json=syft-output.json
 ✔ Parsed image                                                                                                                                                                                                   sha256:ae3bdba0314a72fec46ac12cc3e1509475f1257d65ee6b084fd0899d300c39b7
 ✔ Cataloged contents                                                                                                                                                                                                    dc6aae0717a791c676f4837fdee42b5e255829ccf8da5fb643ee2ecc9effab2a
   ├── ✔ Packages                        [718 packages]
   ├── ✔ File digests                    [28,403 files]
   ├── ✔ File metadata                   [28,403 locations]
   └── ✔ Executables                     [1,867 executables]

[spiffcs]

@sophiewigmore this closed because the PR fixing the issue went in (gh issues with fix keyword close on PR resolve not release 😢 )

Expect to see this in the next syft release - we JUST got out v1.0.0 so I'll coordinate with the team for when v1.0.1 goes out.

If you need this in the immediate term feel free to tag me and I can work with you guys to get a version built from main.

[sophiewigmore]

@spiffcs thank you for the quick fix!! you are the best :)
We can definitely wait for the next release, I'll just roll back the version as-needed until then. Cheers

[sophiewigmore]

@spiffcs the new release looks like its working! Thanks again