Summary

GuardDog's safeextract() function does not validate decompressed file sizes when extracting ZIP archives (wheels, eggs), allowing attackers to cause denial of service through zip bombs. A malicious package can consume gigabytes of disk space from a few megabytes of compressed data.

Vulnerability Details

Affected Component: guarddog/utils/archives.py - safeextract() function Vulnerability Type: CWE-409 - Improper Handling of Highly Compressed Data (Zip Bomb) Severity: HIGH (CVSS ~8) Attack Vector: Network (malicious package uploaded to PyPI/npm) or local

Root Cause

The safeextract() function handles TAR files securely using the tarsafe library, but ZIP file extraction has no size validation: python elif zipfile.iszipfile(sourcearchive): with zipfile.ZipFile(sourcearchive, "r") as zip: for file in zip.namelist(): zip.extract(file, path=os.path.join(targetdirectory, file))

Missing protections: - ❌ No decompressed size limit - ❌ No compression ratio validation - ❌ No file count limits - ❌ No total extracted size validation

Impact

Denial of Service Scenarios

1. CI/CD Pipeline Disruption - Attacker publishes malicious package to PyPI - Developer adds package to requirements.txt - CI/CD runs GuardDog scan - Disk fills (GitHub Actions: standard 14GB limit) - All deployments blocked

2. Resource Exhaustion - Local development environments - Security scanning infrastructure - Automated scanning systems - Docker containers with limited disk

3. Supply Chain Attack Amplification - Single malicious package blocks security scanning - Prevents detection of other malicious packages - Forces manual intervention - Increases security team workload

Recommended Fix

Add size validation for ZIP files similar to what tarsafe provides for TAR files

Configuration Options

Make limits configurable via environment variables or config file

Additional Improvements

1. Add warning logs when archives approach limits 2. Provide clear error messages for users 3. Document limits in user-facing documentation 4. Add tests for zip bomb detection 5. Consider using a safe ZIP library (similar to tarsafe)

Credit

Reported by: Charbel (dwbruijn)

Summary

A path traversal vulnerability exists in GuardDog's safeextract() function that allows malicious PyPI packages to write arbitrary files outside the intended extraction directory, leading to Arbitrary File Overwrite and Remote Code Execution on systems running GuardDog.

CWE: CWE-22 (Improper Limitation of a Pathname to a Restricted Directory)

Details

Vulnerable Code

File: guarddog/utils/archives.py

python elif zipfile.iszipfile(sourcearchive): with zipfile.ZipFile(sourcearchive, "r") as zip: for file in zip.namelist(): # Note: zip.extract cleans up any malicious file name # such as directory traversal attempts This is not the # case of zipfile.extractall zip.extract(file, path=os.path.join(targetdirectory, file)) # ❌ VULNERABLE

Root Cause

The comment about zip.extract() fooled me at first :) then I noticed the os.path.join() call. The vulnerability stems from incorrect usage of Python's zipfile.ZipFile.extract() API:

- The path parameter should be the target directory, not a full file path - extract() automatically appends the member name to the path - By passing os.path.join(targetdirectory, file), GuardDog causes the filename to be appended twice - This breaks zipfile's built-in path traversal sanitization

Attack Vector

1. Attacker creates malicious wheel with path traversal filenames 2. Uploads to PyPI or distributes directly 3. Package scan: guarddog pypi scan malicious-pkg 4. GuardDog downloads and extracts the package 5. Malicious files written to arbitrary locations 6. Code execution could be achieved

Impact

Impact depends on how GuardDog is running and under which environment.

Critical Scenarios

1. Immediate Code Execution - Write to ~/.bashrc → executes on next shell - Write to ~/.profile → executes on login

2. Persistent Backdoors - Write to ~/.ssh/authorizedkeys → SSH access - Write to /etc/cron.d/malicious → scheduled execution (if root) - Write to systemd user services → persistent execution

and more...

Credits

Reported by: Charbel (dwbruijn)

Summary

Unsafe extracting using shutil.unpackarchive() from a remotely retrieved tarball may lead to writing the extracted file to an unintended destination.

Details

Extracting files using shutil.unpackarchive() from a potentially malicious tarball without validating that the destination file path is within the intended destination directory can cause files outside the destination directory to be overwritten.

The vulnerable code snippet is between L153..158.

python response = requests.get(url, stream=True)

with open(zippath, "wb") as f: f.write(response.raw.read())

shutil.unpackarchive(zippath, unzippedpath) It seems that a remotely retrieved tarball which could be with the extension .tar.gz happens to be unpacked using shutil.unpackarchive() with no destination verification/limitation of the extracted files.

PoC

The PoC provided showcases the risk of extracting the non-harmless text file sim4n6.txt to a parent location rather than the current folder.

bash tar --list -f archive.tar tar: Removing leading ../../../' from member names ../../../sim4n6.txt

python3 Python 3.10.6 (main, Nov 2 2022, 18:53:38) [GCC 11.3.0] on linux Type "help", "copyright", "credits" or "license" for more information. >> import shutil >> shutil.unpackarchive("archive.tar") >> exit()

file ../../../sim4n6.txt ../../../sim4n6.txt: ASCII text

A Potential Attack Scenario

- An attacker may craft a malicious tarball with a filename path, such as ../../../../../../../../etc/passwd, and then serve the archive remotely, thus, providing a possibility to overwrite the system files.

Mitigation

Potential mitigation could be to: - Use a safer module, like zipfile. - Validate the location of the extracted files and discard those with malicious paths such as a relative path .. or absolute ones.

Impact

Running GuardDog against a specially-crafted package can allow an attacker to write an arbitrary file on the machine where GuardDog is executed.

This is due to a path traversal vulnerability when extracting the .tar.gz file of the package being scanned, which exists by design in the tarfile.TarFile.extractall function. See also https://docs.python.org/3/library/tarfile.html#tarfile.TarFile.extractall

Remediation

Upgrade to GuardDog v0.1.5 or more recent.

References

https://semgrep.dev/r?q=trailofbits.python.tarfile-extractall-traversal.tarfile-extractall-traversal https://www.trellix.com/en-us/about/newsroom/stories/research/tarfile-exploiting-the-world.html https://docs.python.org/3/library/tarfile.html#tarfile.TarFile.extractall

Impact The import-in-the-middle loader works by generating a wrapper module on the fly. The wrapper uses the module specifier to load the original module and add some wrapping code. It allows for remote code execution in cases where an application passes user-supplied input directly to an import() function.

Patches This vulnerability has been patched in import-in-the-middle version 1.4.2

Workarounds Do not pass any user-supplied input to import(). Instead, verify it against a set of allowed values. If using import-in-the-middle and support for EcmaScript Modules is not needed, ensure that none of the following options are set (either via command-line or the NODEOPTIONS environment variable): --loader=import-in-the-middle/hook.mjs --loader import-in-the-middle/hook.mjs

References If you have any questions or comments about this advisory, email us at security@datadoghq.com

CF CLI version prior to v6.45.0 (bosh release version 1.16.0) writes the client id and secret to its config file when the user authenticates with --client-credentials flag. A local authenticated malicious user with access to the CF CLI config file can act as that client, who is the owner of the leaked credentials.

The Java client for the Datadog API before version 1.0.0-beta.9 has a local information disclosure of sensitive information downloaded via the API using the API Client. The Datadog API is executed on a unix-like system with multiple users. The API is used to download a file containing sensitive information. This sensitive information is exposed locally to other users. This vulnerability exists in the API Client for version 1 and 2. The method prepareDownloadFilecreates creates a temporary file with the permissions bits of -rw-r--r-- on unix-like systems. On unix-like systems, the system temporary directory is shared between users. As such, the contents of the file downloaded via the downloadFileFromResponse method will be visible to all other users on the local system. Analysis of the finding determined that the affected code was unused, meaning that the exploitation likelihood is low. The unused code has been removed, effectively mitigating this issue. This issue has been patched in version 1.0.0-beta.9. As a workaround one may specify java.io.tmpdir when starting the JVM with the flag -Djava.io.tmpdir, specifying a path to a directory with drw------- permissions owned by dd-agent.