Quick Overview:
A critical vulnerability, tracked as CVE-2023-42118, has been discovered in the libspf2 library used by the popular Exim mail server. This bug exposes systems to remote code execution (RCE) attacks by network-adjacent attackers, requiring no authentication. The flaw is rooted in how SPF (Sender Policy Framework) macros are parsed and was initially reported as ZDI-CAN-17578 by Trend Micro’s Zero Day Initiative.

Below, we’ll break down what this vulnerability is, why it’s dangerous, and include code snippets and practical exploit details to help sysadmins and security pros understand and defend their systems.

What is Exim and libspf2?

Exim is a widely used mail transfer agent (MTA) for Unix-like systems. For anti-spam checks, Exim uses the libspf2 library to check SPF records in email headers. SPF helps detect forged sender addresses, but mismanaging its macros can have security consequences.

The Vulnerability in Simple Terms

The heart of CVE-2023-42118 is in how the code parses special sequences (“macros”) in SPF records. The function responsible does not check user input strictly enough. A clever attacker can send specially crafted data to cause an integer underflow. This underflow messes up how much memory the program tries to write, allowing the attacker to overwrite memory and execute arbitrary code as the Exim process.

Attack Surface:

The Code: Where is the Bug?

The vulnerable code lives in macro_expand.c of the libspf2 project. Here’s a simplified code snippet to explain what’s wrong:

// Hypothetical vulnerable function
int macro_expand(char *output, size_t outlen, const char *input) {
    size_t inlen = strlen(input);

    // Reads a number from input (could be negative or huge)
    int num = atoi(input); // BAD: No range/filter check

    // Here comes the danger: underflow if num > inlen
    size_t to_copy = inlen - num;
    memcpy(output, input + num, to_copy);
}

If an attacker sends input where num is larger than inlen, to_copy underflows (wraps around to a huge value), leading to writing out of boundaries—even overwriting critical program memory.

Key Issue: No bounds checking on user-provided data.

Send SPF Record with Malicious Macro

Craft an SPF record with a special macro such that the value being parsed causes an integer underflow.

Trigger Memory Overwrite

When Exim reads the SPF value, its parsing will calculate a negative or huge copy size, writing data past the buffer, smashing adjacent memory—classic buffer overflow.

Execute Malicious Code

By careful arrangement of the memory (using further SPF data or exploiting heap behavior), the attacker can overwrite structures (like function pointers) and gain code execution as the Exim process.

Proof of Concept Attack Vector:
Assume the victim has Exim configured to do SPF checks. The attacker controls the DNS (SPF TXT record) for their own test domain. They serve something like:

v=spf1 mx include:%{l-100}._spf.example.com -all

Here, %{l-100} tries to expand a macro with an insane negative offset, purposely triggering the integer underflow inside libspf2.

Note:
Building a full RCE exploit takes effort: attackers need to know specific Exim/libspf2 versions, memory layout, etc. But the out-of-bounds write is enough to crash the service or start escalating to RCE.

References and Resources

- Zero Day Initiative advisory (ZDI-23-1458)
- CVE-2023-42118 in NVD
- libspf2 GitHub repository
- Exim official documentation

How to Stay Safe?

A fixed version is available. If you run Exim, update libspf2 as soon as possible and restart the Exim service. Disable SPF checks until you can patch.

Bottom Line

CVE-2023-42118 is a serious risk for any Exim installation using libspf2. It’s a stark reminder that even well-meaning tools like email anti-spam libraries can become attack vectors by mishandling input. Patch up, stay updated, and keep an eye on your logs.

Spread the word so administrators can protect their servers before attackers figure this one out!

*Author: Security Researcher*
*Last updated: June 2024*

Timeline

Published on: 05/03/2024 03:15:50 UTC