Understanding the Croc Classic Mode Vulnerability (CVE-2023-43621)

CVE-2023-43621 is a security vulnerability in croc where the classic mode transmitted the shared secret via command-line arguments, exposing it to any local user through the Unix process list.

The croc command-line tool provides secure file transfers between computers using end-to-end encryption. The croc classic mode vulnerability CVE-2023-43621 specifically affects how older versions of the tool handled shared secrets on Unix-like systems, creating a significant information disclosure risk that allowed local attackers to intercept file transfers.

What Is CVE-2023-43621?

CVE-2023-43621 describes an information leak in croc's original "classic mode" implementation. When operating in this mode, croc transmitted the shared secret directly as a command-line argument. On Unix-like systems including Linux and macOS, command-line arguments are visible to all users in the process list via commands like ps aux.

This design flaw meant that any unprivileged local user could observe the secret in real-time and use it to intercept the file transfer between parties. The National Vulnerability Database (NVD) formally classifies this issue as "leaking the secret via the process name."

How the Vulnerability Works

The vulnerability exploits a fundamental Unix security model limitation where process arguments are world-readable.

The Process List Exposure

When a user executed croc in classic mode with a code flag, the secret appeared in plain text:

# Vulnerable pattern - secret visible in 'ps aux'

croc send --code mySecret123 file.txt

Any user running ps aux or inspecting /proc/[pid]/cmdline could capture mySecret123. With this secret, an attacker could connect to the same relay and intercept the file transfer, effectively bypassing croc's encryption protections.

Mitigation and Secure Alternatives

The croc developers addressed CVE-2023-43621 by restructuring how secrets are transmitted and making classic mode strictly opt-in.

Environment Variable Method

The secure remediation replaces command-line arguments with environment variables. Set CROC_SHARED_SECRET before running croc:

export CROC_SHARED_SECRET=mySecret123
croc send file.txt

This approach keeps the secret out of the process list because environment variables are not exposed via ps commands in the same manner as command-line arguments.

The --classic Flag (Opt-In Only)

Classic mode now requires explicit activation and carries clear security warnings. To enable it (only for compatibility with legacy setups):

croc --classic

The tool prompts for confirmation before enabling the insecure mode. When classic mode is disabled, croc aborts on Unix systems if a --code flag is used without an environment-variable secret, preventing accidental exposure.

Implementation Details in the Source Code

The security checks reside primarily in src/cli/cli.go, where the application validates the transfer mode before executing.

The shouldExitForUnixSendCode Guard

In src/cli/cli.go at lines 298-301, croc implements the function shouldExitForUnixSendCode to enforce secure paths:

if shouldExitForUnixSendCode(runtime.GOOS, c.IsSet("code"), classicInsecureMode, envSecret) {
    // abort to avoid leaking the secret
    return
}

This validation ensures that on Unix systems, if a code is provided via command line but classic mode is not explicitly enabled, the program exits before the secret can be exposed in the process table.

Configuration Detection

The codebase uses src/utils/utils.go to provide the Exists helper function, which detects whether classic mode is enabled via configuration files. This allows croc to maintain persistent user preferences while defaulting to secure behavior on fresh installations.

Summary

• CVE-2023-43621 exposed shared secrets through Unix process lists when using croc's classic mode
• The vulnerability allowed any local user to view secrets via ps aux when secrets were passed as command-line arguments
• The secure fix uses environment variables (CROC_SHARED_SECRET) instead of command-line flags
• Classic mode is now opt-in only and explicitly marked as insecure in src/cli/cli.go
• The shouldExitForUnixSendCode function prevents accidental secret leakage on Unix systems when classic mode is disabled

Frequently Asked Questions

How can I check if my croc version is vulnerable to CVE-2023-43621?

Versions prior to the security patch that use classic mode by default are vulnerable. If your croc installation requires the --classic flag to enable the old behavior, you are running a patched version. Check your version by running croc --version and consult the release notes for CVE-2023-43621 patches.

Is Windows affected by the croc classic mode vulnerability?

No, CVE-2023-43621 primarily affects Unix-like systems including Linux and macOS where process command-line arguments are world-readable via ps or /proc. Windows handles process enumeration differently, making this specific attack vector ineffective on that platform.

What happens if I try to use --code without classic mode enabled?

According to the source code in src/cli/cli.go, croc calls shouldExitForUnixSendCode which detects the conflict on Unix systems. The program aborts with an error message explaining that you must either use the CROC_SHARED_SECRET environment variable or explicitly enable insecure classic mode with the --classic flag.

Can I still use classic mode safely on a single-user system?

While the risk is reduced on single-user systems, it is not eliminated. Background processes, monitoring tools, and system logs may still capture the command-line arguments. The recommended approach is always using export CROC_SHARED_SECRET regardless of the user count, as this completely eliminates the process list exposure vector.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}