☠️
EXFILTRATING
DATA...
01010111 10110010 00101001 11000110 01101100 10011011 00010001 11100101 01000010 10101111
[ <-- BACK_TO_SEARCH ]
Ibm logo [ WEBSITE ] [ VENDOR STATS ]
CVSS: 10 🐛 CWE-378
👁️
Common Weakness Enumeration - Identifies the specific category of software weakness or flaw.

CVE-1999-1405

This report details CVE-1999-1405, a critical local privilege escalation vulnerability affecting IBM AIX operating systems prior to version 4.
📅 PUBLISHED: 1999-02-17 05:00 UTC 🔄 UPDATED: 2026-09-19 11:15 UTC
[ OFFICIAL PATCH DEPLOYED ↓ ] FIX: CLAIMED — single source claims patch (not independently confirmed)
[ DEFENSE PATCH ↓ ]
💣 PoC: Public
👁️
Proof of Concept - Indicates if functional exploit code is publicly available, drastically increasing the risk of immediate attacks.
🎯 EPSS: 3.35%
👁️
3.35% probability
83.6× above the median CVE
Tier: HIGH
30-day exploitation window · FIRST.org · updated daily
Affected: 3.2.5 — upgrade to patched release
CVSS SEVERITY SCALE
9.0–10.0 CRITICAL
7.0–8.9 HIGH
4.0–6.9 MEDIUM
0.1–3.9 LOW
0.0 NONE
10.0
THREAT LEVEL
■ tracking this CVE ✓ independent patch confirmation ⧗ same-origin mirror (GHSA) ⚠ active exploitation verification policy →

Executive Summary

This report details CVE-1999-1405, a critical local privilege escalation vulnerability affecting IBM AIX operating systems prior to version 4.3.2. The vulnerability resides in the snap command, a system administration tool used for collecting system configuration data. The flaw stems from the insecure creation of a temporary directory, /tmp/ibmsupt, with world-readable permissions, and the subsequent failure to remove this directory after execution.

An unprivileged local attacker can exploit this condition by waiting for a privileged user (typically root) to run the snap -a command. After the command completes, sensitive system information, including a copy of the shadowed password file (/etc/security/passwd), is left in the world-readable temporary directory. This allows the attacker to retrieve the password hashes of all users on the system, which can then be cracked offline to gain unauthorized access and achieve complete system compromise. Given the UNKNOWN / UNPATCHED status, immediate application of mitigation strategies is crucial for vulnerable systems.

⚡ AUTOMATE YOUR CVE INTELLIGENCE

This record — and 170,000+ others — are available via the ValtersIT API. One endpoint replaces five: NVD + GitHub CVE + CISA KEV + EPSS + Nuclei + Exploit-DB, unified.

›Patch confidence — UNVERIFIED to CONFIRMED, cross-referenced NVD + RHSA + Debian
›Exploit & PoC — poc_status, poc_url, has_exploit. Not in NVD.
›Shodan dorks — ready-made queries to find exposed vulnerable systems
›Detection rules — YARA · Wazuh · Elastic (all plans) · Sigma (Pro)
›pending_fields — know exactly which of 7 fields NVD hasn't processed yet
›Free backfill — data incomplete when you paid? Re-check within 30 days = 0 credits
PAYG €0.08/lookup Standard €19/mo (was €29) · 5k credits Pro €65/mo (was €99) · 20k credits FOUNDING PRICE · LOCKED FOR LIFE · ENDS 31 DEC 2026
[ FROM €19/MO ]
Free sandbox key available
No signup required

CVSS Breakdown & Threat Level

The provided CVSS score for this vulnerability is 10.0 (Critical). It is important to note that this score likely originates from an older standard, such as CVSS v2.0, where local vulnerabilities could be rated this highly. A modern CVSS v3.1 analysis provides a more nuanced view but still highlights a significant risk.

A plausible CVSS v3.1 vector would be CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H, resulting in a score of 7.3 (High).

  • Attack Vector (AV): Local (L): The attacker must have local shell access to the target system.
  • Attack Complexity (AC): Low (L): No complex techniques are required beyond waiting for the snap command to be executed by an administrator.
  • Privileges Required (PR): Low (L): The attack can be initiated by any unprivileged user account.
  • User Interaction (UI): Required (R): A privileged user must run the snap -a command for the vulnerability to be exposed.
  • Scope (S): Unchanged (U): The exploit does not impact components beyond the security scope of the vulnerable snap binary itself.
  • Confidentiality (C): High (H): The attacker gains access to the entire shadowed password file, compromising all user credentials on the system.
  • Integrity (I): High (H): With cracked credentials, the attacker can impersonate users, including root, leading to a total loss of system integrity.
  • Availability (A): High (H): An attacker who gains root access can cause a complete denial of service.

Despite being a local vulnerability, the potential for total system compromise through credential theft justifies its classification as a high-severity threat to multi-user AIX environments.

Deep Dive & Mechanics

The snap command in IBM AIX is a diagnostic tool designed to gather comprehensive system information for support and troubleshooting. The -a flag instructs it to collect all available system data. The vulnerability is rooted in its improper handling of temporary files and directories.

The exploitation mechanism is straightforward:

  1. Execution by Root: A system administrator executes the snap -a command.
  2. Insecure Directory Creation: The snap process creates the directory /tmp/ibmsupt with insecure permissions (e.g., 777 or 755), making it readable and traversable by all users on the system.
  3. Sensitive Data Collection: The command proceeds to copy numerous system configuration and data files into subdirectories within /tmp/ibmsupt. Crucially, a copy of the shadowed password file is placed at /tmp/ibmsupt/general/passwd. The permissions on this copied file are also insecure, inheriting from the parent directory or a lax umask.
  4. Failure to Clean Up: Upon completion, the snap command exits without removing the /tmp/ibmsupt directory and its contents.
  5. Information Disclosure: An unprivileged local user can then freely navigate to /tmp/ibmsupt/general/ and read the passwd file, exfiltrating the password hashes for all system accounts.

The core of the issue is a violation of secure temporary file handling principles: creating predictable directory names, applying insecure permissions, and failing to perform cleanup.

Vulnerable vs. Patched Code

The source code for the proprietary snap binary is not public. However, the flawed logic can be represented in pseudocode and contrasted with a secure implementation.

Vulnerable Logic (Pseudocode):

#!/bin/sh
# Simplified vulnerable logic of snap -a

TEMP_DIR="/tmp/ibmsupt"

# 1. Insecure, predictable directory name
# 2. Permissions are world-readable due to default umask or explicit chmod
mkdir -p "$TEMP_DIR/general"

# 3. Sensitive data is copied into the insecure location
cp /etc/security/passwd "$TEMP_DIR/general/passwd"
# ... other data collection ...

# 4. Critical flaw: no cleanup is performed. The directory and its contents remain.
exit 0

Patched Logic (Pseudocode):

#!/bin/sh
# Simplified secure logic for snap -a

# Define a cleanup function to run on exit
cleanup() {
  rm -rf "$TEMP_DIR"
}
trap cleanup EXIT

# 1. Use mktemp for a unique, unpredictable directory name
# 2. Set strict permissions (user-only access)
TEMP_DIR=$(mktemp -d /tmp/snap.XXXXXX)
chmod 700 "$TEMP_DIR"

# 3. Collect data into the secure, temporary location
mkdir -p "$TEMP_DIR/general"
cp /etc/security/passwd "$TEMP_DIR/general/passwd"
# ... other data collection ...

# 4. The 'trap' command ensures cleanup runs automatically when the script exits
exit 0

A proper patch would ensure the temporary directory is created with a unique name, has restrictive permissions (700), and is reliably removed upon command completion or failure.

Exploitation & Lab Setup

The exploitation process requires patience, as the attacker must wait for an administrator to trigger the vulnerable command.

Prerequisites:

  • A local, unprivileged shell account on a vulnerable AIX system (< 4.3.2).
  • A privileged user must execute snap -a as part of their routine duties.

Exploitation Steps:

  1. Log in to the vulnerable AIX system as a non-root user.
  2. Periodically check for the existence of the vulnerable directory. This can be done with a simple while loop or by using watch.
    watch 'ls -ld /tmp/ibmsupt'
    
  3. Once an administrator runs snap -a, the directory will appear. Verify its permissions are world-readable.
  4. List the contents of the general subdirectory to find the password file.
    ls -l /tmp/ibmsupt/general/
    
  5. Read the contents of the copied password file to obtain the user hashes.
    cat /tmp/ibmsupt/general/passwd
    
  6. The output will look similar to this, containing usernames and their corresponding password hashes:
    root:
        password = !
        lastupdate = 1665410000
        flags = ADMCHG
    
    daemon:
        password = *
    
    jane.doe:
        password = {ssha256}06$...................................................
        lastupdate = 1665420000
    
  7. The captured hashes can be saved to a file and processed with password cracking tools like John the Ripper or Hashcat to recover the cleartext passwords.

Detection Engineering

Detecting this attack involves monitoring for the specific artifacts left behind by the snap command. A Sigma rule is an effective way to detect this activity using endpoint logs.

Here is a Sigma rule for use with a SIEM or EDR solution that monitors file creation events:

title: IBM AIX Snap Password File Disclosure (CVE-1999-1405)
id: 61e93c10-5ab8-45e0-9a3b-18f1a8c8e6a5
status: stable
description: >
    Detects the creation of a 'passwd' file within the '/tmp/ibmsupt/general/' directory. 
    This is a strong indicator of the vulnerable 'snap -a' command being executed on an IBM AIX system, 
    exposing sensitive password hashes as per CVE-1999-1405.
author: Valters IT
date: 2023/10/27
references:
    - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-1999-1405
logsource:
    category: file_creation
    product: linux # Use 'linux' as a proxy for Unix-like systems such as AIX
detection:
    selection:
        TargetFilename|contains: '/tmp/ibmsupt/general/passwd'
    condition: selection
falsepositives:
    - Extremely unlikely, as this file path is highly specific to the vulnerable command.
level: high
tags:
    - attack.privilege_escalation
    - attack.t1548
    - cve.1999.1405

For direct host-based detection, a simple shell script can be run via cron to check for the vulnerable directory's existence and alert administrators.

#!/bin/sh
VULN_DIR="/tmp/ibmsupt"

if [ -d "$VULN_DIR" ]; then
    # Check if the directory is older than a few minutes to avoid false positives during a legitimate run
    if [ -n "$(find "$VULN_DIR" -mmin +5)" ]; then
        echo "Alert: Vulnerable directory $VULN_DIR found on $(hostname). Possible CVE-1999-1405 activity." | mail -s "CVE-1999-1405 Alert" your-admin-email@example.com
        # Optionally, add a cleanup command
        # rm -rf "$VULN_DIR"
    fi
fi

Remediation & Mitigation

As the official patch status is listed as UNKNOWN / UNPATCHED for this legacy vulnerability, a defense-in-depth approach is required.

  • Primary Remediation (Recommended): The vulnerability is documented to be fixed in AIX version 4.3.2 and later. The most effective solution is to upgrade any systems running affected versions to a supported, modern version of AIX.

  • Mitigation Strategies (If upgrading is not feasible):

    1. Restrict snap Execution: If the snap command is not required for regular operations, tighten its permissions to prevent execution by unauthorized users.
      # Remove execute permissions for group and other
      chmod go-x /usr/sbin/snap
      
    2. Automated Cleanup: Implement a cron job that runs every few minutes as root to forcefully remove the vulnerable directory if it exists. This significantly shortens the window of opportunity for an attacker.
      # Crontab entry to clean up /tmp/ibmsupt every 5 minutes
      */5 * * * * /usr/bin/rm -rf /tmp/ibmsupt > /dev/null 2>&1
      
    3. System Auditing: Configure AIX system auditing to log all executions of the snap command and all file creation events within the /tmp directory. Regularly review these logs for suspicious activity.
    4. Principle of Least Privilege: Ensure that users and services operate with the minimum level of privilege necessary. Avoid using privileged accounts for daily tasks to reduce the chances of the vulnerable command being run.

[!] This Threat Intelligence report was automatically generated by Valters IT (valtersit.com) Neural Engine.

{/* [Security Hash: 51030BB3F2929DC15203321F] */}

⚠ EXPLOIT CODE 3RD-PARTY · UNVERIFIED

This code is sourced from public security research repositories (ExploitDB, GitHub). It has not been reviewed or verified by ValtersIT. Use only in authorized test environments. Unauthorized use against systems you do not own is illegal.

source: https://www.securityfocus.com/bid/375/info

The snap command is a diagnostic utlitiy for gathering system information on AIX platforms. It can only be executed by root, but it copies various system files into /tmp/ibmsupt/ under /tmp/ibmsupt/general/ you will find the passwd file with cyphertext. The danger here is if a system administrator executes snap -a as sometimes requested by IBM support while diagnosing a problem it defeats password shadowing. /tmp/ibmsupt is created with 755 permissions they may carry out a symlink attack and gain access to the password file.

snap is a shell script which uses cp -p to gather system information. Data from /etc/security is gathered between lines 721 - 727. Seeing that snap uses the /tmp/ibmsupt/general directory someone may create the directory as a normal user (tested on on AIX 4.2.1). The user may then do a touch on /tmp/ibmsupt/general/passwd. Once the passwd file is created do tail -f /tmp/ibmsupt/general/passwd. If in another session someone loggs in as root and ran snap -a - this will cause the contents of the /etc/security/passwd to show up in tail command.
◈ SOURCE Analysis & enrichment: valtersit.com/cve/CVE-1999-1405/ · CVE data: NVD/MITRE (public domain) · © 2026 ValtersIT Hub
>_ SYSTEM_CORE: INTEL_ACTIVE
90% TEAM-CURATED // 10% AUTOMATED INGESTION.
ALL PATCH REFERENCES AND VERSION DATA SOURCED FROM NVD + OSV OFFICIAL REGISTRIES.