CVE-2014-3504
NoneCVSS
—
EPSS
3.1%
Published
Aug 19, 2014
CISA due date
—
Cloudanix analysis
A flaw in an encryption library used by some version-control tools could let attackers secretly read or change data sent between a computer and a server by using a specially made security certificate.
- Exploitation
- Remote Unauthenticated
- Attacker needs
- None
- Complexity
- Moderate
- Impact
- Data Exposure
- Component
- Library
- Class
- Cryptographic Weakness
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
The affected Serf functions fail to terminate certificate CN field parsing at an embedded NUL byte, allowing a certificate containing a CN such as "example.com\0attacker.com" to be treated as matching the attacker's domain.
Why it matters to the business
Organizations relying on Subversion or other Serf-based clients for encrypted repository access face risk of silent interception of source code, credentials, and other sensitive data in transit.
How an attack unfolds
An attacker obtains a CA-signed certificate containing a NUL byte in the CN, positions themselves on the network path to a Subversion or Serf client, and presents the crafted certificate; the vulnerable client accepts it as valid for the intended hostname, establishing a decrypted session under attacker control.
How to fix it
Upgrade Serf to version 1.3.7 or later; rebuild and redeploy any dependent packages such as Subversion clients that statically or dynamically link the vulnerable Serf library.
How to confirm the fix worked
Confirm the installed Serf shared library or source reports version 1.3.7 or newer; recompile dependent applications against the fixed library and verify that certificate validation tests reject NUL-byte CNs.
Typical attack path
- Obtain a CA-issued X.509 certificate embedding a NUL byte in the CN field
- Position as a man-in-the-middle on the path between client and legitimate server
- Present the crafted certificate during the TLS handshake
- Decrypt and inspect or modify traffic once the client accepts the spoofed certificate
How to detect it
Review TLS handshake logs and certificate validation events from Subversion or Serf clients for unexpected certificate subjects or validation bypass indicators; correlate with network flow data showing connections to unexpected endpoints during repository operations.
What your security team should do
- Identify all systems using Serf < 1.3.7 and schedule immediate library upgrades
- Prioritize upgrades for internet-facing or high-value Subversion clients
- Add Serf version checks to dependency scanning and build pipelines
The record
The (1) serf_ssl_cert_issuer, (2) serf_ssl_cert_subject, and (3) serf_ssl_cert_certificate functions in Serf 0.2.0 through 1.3.x before 1.3.7 does not properly handle a NUL byte in a domain name in the subject's Common Name (CN) field of an X.509 certificate, which allows man-in-the-middle attackers to spoof arbitrary SSL servers via a crafted certificate issued by a legitimate Certification Authority.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|---|---|---|
| Debian:11 | serf | 0 | 1.3.7-1 |
| Debian:12 | serf | 0 | 1.3.7-1 |
| Debian:13 | serf | 0 | 1.3.7-1 |
| Mageia:3 | serf | 0 | 1.1.1-2.1.mga3 |
| Mageia:4 | serf | 0 | 1.3.2-2.1.mga4 |
| Ubuntu:14.04:LTS | serf | 0 | 1.3.3-1ubuntu0.1 |
| openSUSE:Tumbleweed | libserf | 0 | 1.3.9-1.2 |