CVE-2014-0083

Vulnerability

Overview

The Ruby net-ldap gem (also known as Net::LDAP) prior to version 0.11 implemented SSHA (salted SHA1) password hashing using a weak salt. In the generate method of the password hash module, the salt was generated by calling srand; salt = (rand * 16).to_i.to_s [4]. This approach used the built-in rand() function seeded with srand, which produces a predictable sequence of pseudo-random numbers and a very small salt space of at most 16 possible values (0–15). This violates security best practices for password storage, where salts must be both unique and unpredictable to prevent precomputation attacks.

Attack

Vector and Exploitation

The vulnerability is present in the SSHA password generation code path within the gem. An attacker who gains access to the stored password hashes (e.g., via a database breach or LDAP server compromise) can exploit the weak salt. Because the salt is limited to a small numeric range, the attacker can precompute a rainbow table or dictionary for each of the 16 possible salt values. For each hash, the attacker iterates through possible salts and computes candidate SHA1 digests until a match is found. This dramatically reduces the computational effort required to recover plaintext passwords compared to proper salted hashing.

Impact

Successful exploitation allows an attacker to recover passwords from SSHA hashes with significantly less effort than would be required with a strong, random salt. The weak salt undermines the primary security property of SSHA: protection against precomputed dictionary and rainbow table attacks. This could lead to unauthorized access to systems that rely on net-ldap for LDAP authentication, especially if users reuse passwords across services.

Mitigation

The issue was fixed in net-ldap version 0.11 by changing the salt generation to use SecureRandom.random_bytes(16) [4], which provides 128 bits of cryptographically strong randomness. Users should upgrade to net-ldap 0.11 or later. Debian security tracker notes that packages in stable releases (bullseye and later) contain the fixed version [3]. Systems that generated SSHA hashes with the vulnerable code should rotate all affected passwords, as previously generated hashes remain weak even after upgrading.