Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[release-5.29] Fix CVE-2024-3727 #2418

Merged
merged 6 commits into from
May 16, 2024

Conversation

mtrmac
Copy link
Collaborator

@mtrmac mtrmac commented May 15, 2024

Digest values used throughout this library were not always validated. That allowed attackers to trigger, when pulling untrusted images, unexpected authenticated registry accesses on behalf of a victim user.

In less common uses of this library (using other transports or not using the containers/image/v5/copy.Image API), an attacker could also trigger local path traversals or crashes.


This is a backport of #2404 . Thanks to @dcermak for independently validating this work via #2415 .

mtrmac added 6 commits May 15, 2024 11:30
If doing it makes sense at all, it should happen before
the values are used.

Signed-off-by: Miloslav Trmač <[email protected]>
... to prevent panics if the value does not contain a :, or other unexpected
values (e.g. a path traversal).

Don't bother on paths where we computed the digest ourselves, or it is already trusted
for other reasons.

Signed-off-by: Miloslav Trmač <[email protected]>
Use defer() to remove the temporary file, instead
of duplicating the call.

Should not change behavior.

Signed-off-by: Miloslav Trmač <[email protected]>
Use defer, a nested function, and early returns.

Besides being a bit more directly related to what
we want to achieve, this now does not call decompressed.Close()
on a nil value if DecompressStream fails.

Signed-off-by: Miloslav Trmač <[email protected]>
... to prevent unexpected behavior on invalid values.

Signed-off-by: Miloslav Trmač <[email protected]>
@TomSweeneyRedHat
Copy link
Member

LGTM, nice work @mtrmac !

@TomSweeneyRedHat
Copy link
Member

@kwilczynski, I'll let @mtrmac correct me if I'm wrong, but I think you will also want to grab the follow-on fix for this fix for CRI-O. That fix is in this PR on main: #2440 and solves the issue as noted here: containers/skopeo#2346

If it helps, this has been fixed in c/image v5.31.1, v5.30.2, and v5.29.4. If you need older versions fixed, please let us know.

@mtrmac
Copy link
Collaborator Author

mtrmac commented Jul 11, 2024

From a very quick check, CRI-O seems to never call the affected GetRepositoryTags function, but I could well have missed something.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants