CVE-1999-0556

Executive Summary

This report details CVE-1999-0556, a critical misconfiguration in Unix-like operating systems where two or more user accounts are assigned the same User ID (UID). The Unix security model is fundamentally based on numeric UIDs, not usernames, for access control decisions. When multiple accounts share a UID, the kernel treats them as the same entity regarding file ownership and permissions. This leads to a complete breakdown of user separation and accountability.

The most severe impact occurs when an account is assigned UID 0, the identifier for the root superuser. Any user who can log into an account with UID 0 effectively gains full, unrestricted root access to the system, representing a complete compromise. For non-root UIDs, this misconfiguration allows any user sharing the UID to read, modify, and delete the files of other users with the same UID, leading to data theft, tampering, and repudiation issues. This is not a software flaw that can be patched with an update but a critical system administration oversight that must be remediated through manual configuration auditing and correction.

CVSS Breakdown & Threat Level

• CVSS v2.0 Score: 7.2 (High)
• Vector: AV:L/AC:L/AU:N/C:C/I:C/A:C

This CVE is rated as High severity. The score is derived from the following metrics:

• Access Vector (AV): Local (L): An attacker must have local access to the system, such as an SSH login or physical access, to exploit this vulnerability.
• Access Complexity (AC): Low (L): Exploitation is trivial. If an attacker has credentials for one of the accounts with a duplicated UID, no further special conditions are required.
• Authentication (AU): None (N): While initial system access is required, no further authentication is needed to leverage the shared privileges of the duplicated UID.
• Confidentiality (C): Complete (C): If UID 0 is duplicated, the attacker gains root access and can read all data on the system. For non-root UIDs, the attacker can read all files owned by other users sharing that UID.
• Integrity (I): Complete (C): With root access (from a duplicated UID 0), the attacker can modify any file on the system. For non-root UIDs, the attacker can modify all files owned by the shared UID.
• Availability (A): Complete (C): With root access, the attacker can shut down the system, delete critical files, or render the OS inoperable.

Deep Dive & Mechanics

The core of the Unix/Linux security model revolves around numeric identifiers for users (UID) and groups (GID). When a user creates a file, the file's metadata stores the creator's UID, not their username. When any process attempts to access that file, the kernel compares the process's UID with the file's owner UID and its permission bits (read, write, execute) to grant or deny access.

CVE-1999-0556 describes the scenario where this fundamental principle is violated. The /etc/passwd file, which maps usernames to UIDs, is configured incorrectly to have duplicate UIDs.

Example /etc/passwd entries: user_a:x:1001:1001::/home/user_a:/bin/bash user_b:x:1001:1001::/home/user_b:/bin/bash

In this case, both user_a and user_b have UID 1001. The kernel makes no distinction between them.

• If user_a creates a file /tmp/secret.txt, the file is owned by UID 1001.
• If user_b logs in and lists the file, the system will show user_b as the owner (or whichever username appears first in /etc/passwd for that UID).
• user_b has full control over /tmp/secret.txt as if they created it, allowing them to read, modify, or delete it.

The Ultimate Threat: UID 0 Duplication The most critical exploitation vector is duplicating UID 0.

root:x:0:0:root:/root:/bin/bash backdoor:x:0:0:backdoor account:/home/backdoor:/bin/bash

Here, a new user backdoor has been created with UID 0. Anyone with the password for the backdoor account can log in and immediately become the root user. The id command will confirm their identity as uid=0(root), granting them absolute control over the entire system. This is a classic privilege escalation and persistence technique.

Vulnerable vs. Patched Code

This is a configuration vulnerability, not a code flaw. The "vulnerable code" is an insecure system configuration file, and the "patched code" is a secure one.

Insecure Configuration (/etc/passwd)

# This configuration is VULNERABLE
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
jdoe:x:1005:1005:John Doe:/home/jdoe:/bin/bash
# Malicious or accidental entry with a duplicate UID
badactor:x:1005:1005:Bad Actor:/home/badactor:/bin/bash
# Critical privilege escalation vector
fakeadmin:x:0:0:Fake Admin:/home/fakeadmin:/bin/bash

Secure Configuration (/etc/passwd)

# This configuration is SECURE (remediated)
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
jdoe:x:1005:1005:John Doe:/home/jdoe:/bin/bash
# badactor UID has been changed to be unique
badactor:x:1006:1006:Bad Actor:/home/badactor:/bin/bash
# fakeadmin account has been removed or had its UID changed
# fakeadmin:x:1007:1007:Fake Admin:/home/fakeadmin:/bin/bash

Exploitation & Lab Setup

Objective: Demonstrate privilege escalation by exploiting a duplicated UID 0.

Lab Setup:

1. A Linux VM (e.g., Debian, Ubuntu, CentOS).
2. Root or sudo access for initial setup.

Steps:

1. As root, create a standard, low-privilege user.

   sudo useradd lowpriv
   sudo passwd lowpriv
   

2. Create a "backdoor" user and deliberately assign it UID 0. The -o flag is required to override the system's default protection against creating non-unique UIDs.

   sudo useradd -o -u 0 -g 0 -M -s /bin/bash backdoor
   sudo passwd backdoor
   

   • -o: Allows creating a user with a non-unique UID.
   • -u 0: Sets the UID to 0 (root).
   • -g 0: Sets the primary group ID to 0 (root group).
   • -M: Does not create a home directory.
   • -s /bin/bash: Sets the login shell.

3. Now, log out from the root/sudo session and log in as the backdoor user with the password you just set.

4. Verify your identity. You are now root.

   id
   

   Expected Output:

   uid=0(root) gid=0(root) groups=0(root)
   

5. You have full control. For example, read the shadow password file, which is normally only readable by root.

   cat /etc/shadow
   

This simple process demonstrates a complete system takeover via a misconfigured account.

Detection Engineering

Detecting this misconfiguration can be done via periodic system audits or by monitoring for the commands used to create this state.

Audit Script (Bash)

This shell script can be run by system administrators or security tools to audit the /etc/passwd file for duplicate UIDs.

#!/bin/bash
#
# CVE-1999-0556 Detection Script
# Finds duplicate UIDs in /etc/passwd

echo "[*] Checking for duplicate UIDs in /etc/passwd..."

# Cut the 3rd field (UID), sort it, count unique occurrences, and find lines with counts > 1
duplicates=$(cut -f3 -d':' /etc/passwd | sort -n | uniq -c | while read count uid; do
    if [ $count -gt 1 ]; then
        echo "UID $uid is duplicated $count times for the following users:"
        grep -E "^[^:]+:[^:]+:$uid:" /etc/passwd | cut -f1 -d':' | sed 's/^/  - /'
        echo ""
    fi
done)

if [ -z "$duplicates" ]; then
    echo "[+] SUCCESS: No duplicate UIDs found."
    exit 0
else
    echo "[-] VULNERABILITY DETECTED: Duplicate UIDs found!"
    echo "$duplicates"
    exit 1
fi

Sigma Rule

This Sigma rule detects the suspicious use of useradd or usermod with the --non-unique (-o) flag, which is a prerequisite for creating this vulnerability via standard tools.

title: Potential Duplicate UID Creation
id: 5743a18a-9c7b-42e1-8f51-34e857ab349c
status: stable
description: Detects the use of user management commands with the '-o' or '--non-unique' flag, which allows the creation of accounts with a duplicate UID (CVE-1999-0556). This is a highly suspicious activity often associated with creating hidden administrative accounts.
author: Valters IT
date: 2023/10/27
references:
    - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-1999-0556
logsource:
    product: linux
    category: process_creation
detection:
    selection_program:
        - 'useradd'
        - 'usermod'
    selection_flag:
        - ' -o '
        - '--non-unique'
    condition: selection_program and selection_flag
falsepositives:
    - Extremely rare but legitimate administrative tasks, which should be heavily scrutinized.
level: high
tags:
    - attack.privilege_escalation
    - attack.t1068
    - cve.1999.0556

Remediation & Mitigation

Remediation requires manual intervention to correct the system's configuration. Automated configuration management and regular audits are key to preventing recurrence.

1. Immediate Remediation Steps:

• Identify Duplicates: Use the detection script provided above or the following one-liner to find accounts with duplicate UIDs.

  cut -f3 -d':' /etc/passwd | sort | uniq -d
  

• Investigate and Plan: For each duplicate UID found, identify which accounts are associated with it. Determine which account is the "primary" or legitimate one and which needs to be changed.
• Change UID: Use the usermod command to assign a new, unique UID to the non-primary account.

  # Example: Change UID for user 'badactor' to a new unique UID 1006
  sudo usermod -u 1006 badactor
  

• Re-assign File Ownership: This is a critical step. After changing a user's UID, all files they previously owned will still be associated with the old UID, effectively orphaning them. You must find and re-assign ownership to the new UID.

  # Find all files owned by the old UID (e.g., 1005) and change ownership to the new user/UID (e.g., badactor or 1006)
  sudo find / -path /proc -prune -o -user 1005 -exec chown -h badactor {} \;
  

2. Proactive Mitigation & Hardening:

• Regular Audits: Schedule a cron job to run the detection script daily or weekly and alert on any findings.
• Use System Integrity Checkers: Use built-in tools like pwck which can identify formatting errors and duplicates in /etc/passwd.
• Configuration Management: Employ tools like Ansible, Puppet, or Chef to enforce system state. Create rules that ensure user UIDs are unique across your infrastructure.
• Principle of Least Privilege: Limit sudo and root access. Monitor the execution of sensitive commands like useradd and usermod, especially with flags like -o.
• Disable Direct Root Login: Always disable direct root login over SSH (PermitRootLogin no in sshd_config) to force users to log in with their own accounts and elevate privileges via sudo, which provides an audit trail.

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

{/* [Security Hash: C795EB065FF8CF7BD56FC1CC] */}