chore(deps): update docker images to v11

[renovate]

Motivation

Automated dependency update by Renovate bot.

Description

This PR contains the following updates:

Package	Type	Update	Change
mcr.microsoft.com/dotnet/aspnet	stage	major	10.0-azurelinux3.0-distroless → 11.0-azurelinux3.0-distroless
mcr.microsoft.com/dotnet/sdk	stage	major	10.0 → 11.0

Testing

This is an automated dependency update. No functional changes are expected.

Impact

Additional Information

---

• If you want to rebase/retry this PR, check this box

This PR was generated automatically by Renovate.

[github-actions]

🔍 Vulnerabilities of dockerhubaneo/armonik_control_metrics:0.41.1-renovatemajordocker.1.sha.80e87157

📦 Image Reference dockerhubaneo/armonik_control_metrics:0.41.1-renovatemajordocker.1.sha.80e87157

digest	sha256:5028ef2ca97f7bea1e2f2e1aac59a187661aaff401c811a7e2dfc6898e084cd5
vulnerabilities
platform	linux/amd64
size	68 MB
packages	63

SharpCompress 0.30.1 (nuget) pkg:nuget/SharpCompress@0.30.1 # Dockerfile (159:159) COPY --from=build /app/publish/metrics . Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') Affected range <0.48.0 Fixed version 0.48.0 CVSS Score 5.9 CVSS Vector CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:H/A:L EPSS Score 0.313% EPSS Percentile 24th percentile Description Summary A path traversal vulnerability in IArchive.WriteToDirectory() allows a malicious archive to create directories outside the intended extraction root. For TAR archives, this can be escalated to arbitrary file writes by chaining with a symlink entry, giving a full write primitive on the target filesystem subject to the permissions of the running process. Details The vulnerable code is in the directory-entry branch of WriteToDirectoryInternal (sync, IArchiveExtensions.cs:48–61) and WriteToDirectoryAsyncInternal (async, IAsyncArchiveExtensions.cs:70–84): var dirPath = Path.Combine(destinationDirectory, entry.Key); Directory.CreateDirectory(Path.GetDirectoryName(dirPath + "/")); No Path.GetFullPath() normalisation and no bounds check are applied before the Directory.CreateDirectory call. Two .NET Path.Combine behaviours make this exploitable: Relative traversal: Path.Combine("/safe/extract", "../../evil") → the OS resolves .. segments on the raw path, placing the directory outside the extraction root. Absolute path override: Path.Combine("/safe/extract", "/tmp/evil") → returns "/tmp/evil" — the base is discarded entirely for rooted paths. File entries are not directly affected — they route through ExtractionMethods.WriteEntryToDirectory which applies the correct guard (GetFullPath + StartsWith, see ExtractionMethods.cs:54–65). The directory-entry branch is a separate fast-path that was added without that guard. Affected archive formats: ZIP and TAR (non-solid). Solid archives and 7-Zip use the reader path which calls the secure method. Escalation to arbitrary file writes (TAR only) Path.GetFullPath on .NET does not resolve symlinks — it only normalises . and .. segments. This means the file-entry guard in ExtractionMethods.WriteEntryToDirectory can be bypassed via symlink chaining in TAR archives when the caller supplies a SymbolicLinkHandler: archive.WriteToDirectory("/safe/extract", new ExtractionOptions { ExtractFullPath = true, SymbolicLinkHandler = (linkPath, linkTarget) => File.CreateSymbolicLink(linkPath, linkTarget) // naive — no validation of linkTarget }); Attack sequence in a single TAR archive: Symlink entry — link → ../evil_outside/ The SymbolicLinkHandler creates /safe/extract/link pointing outside the extraction root. File entry — link/secret.txt ExtractionMethods.WriteEntryToDirectory computes: destdir = Path.GetFullPath("/safe/extract/link") → "/safe/extract/link" — textually inside root, check passes ✓ File.Open("/safe/extract/link/secret.txt") — OS follows symlink, file is written to /evil_outside/secret.txt The library does not validate linkTarget before passing it to the caller's handler, and the XML docs do not warn that it may be a traversal path. The idiomatic handler implementation above is therefore silently exploitable. ZIP does not support symlinks in SharpCompress (ZipEntry.LinkTarget always returns null), so this escalation is TAR-only. Attack ZIP TAR Directory traversal (escape extraction root) Yes Yes Escalate to arbitrary file writes via symlink chain No Yes (if caller provides SymbolicLinkHandler) Recommended fix — apply the same pattern from ExtractionMethods.WriteEntryToDirectory to both affected files: var fullDestDir = Path.GetFullPath(destinationDirectory); if (!fullDestDir.EndsWith(Path.DirectorySeparatorChar)) fullDestDir += Path.DirectorySeparatorChar; var dirPath = Path.GetFullPath(Path.Combine(fullDestDir, entry.Key)); if (!dirPath.StartsWith(fullDestDir, PathComparison)) throw new ExtractionException( "Entry is trying to create a directory outside of the destination directory."); Directory.CreateDirectory(dirPath); Additionally, the library should validate LinkTarget before invoking the caller's SymbolicLinkHandler, or document clearly that callers must validate it themselves. PoC A self-contained .NET console app is available at: https://github.com/svenclaesson/poc-sharpcompress-traversal git clone https://github.com/svenclaesson/poc-sharpcompress-traversal cd poc-sharpcompress-traversal dotnet run The PoC crafts a ZIP with three directory entries (../../escaped_relative/, /tmp/escaped_absolute/, safe_subdir/) using System.IO.Compression (stdlib), then extracts with SharpCompress. Output shows [ESCAPED] for the two malicious entries and [ok] for the legitimate one, on both sync and async APIs. Tested against SharpCompress 0.47.4 (latest NuGet). Impact This is a path traversal / zip slip vulnerability (CWE-22). Any application that calls archive.WriteToDirectory() on an untrusted archive is affected — which covers the primary documented extraction API. For ZIP archives the impact is limited to arbitrary directory creation, which can be used to stage privilege escalation (e.g. cron drop-ins, XDG config paths, service spool directories) or shadow expected paths to alter application behaviour. For TAR archives, callers that implement a SymbolicLinkHandler — which is the only way to faithfully restore a TAR — are exposed to a full arbitrary file write primitive via the symlink chaining described above.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud