A new vulnerability, CVE-2024-43167, was found in Unbound DNS resolver. It’s related to how the API handles forwarding addresses. A certain order of API calls can trigger a bug: the code tries to read from a pointer that is actually NULL. This will crash the process, which can lead to a Denial of Service (DoS) attack.

What is Unbound?

Unbound is a popular, secure, and fast DNS resolver used all over the internet for handling DNS queries. It’s often used in ISPs, enterprises, VPNs, and sometimes even on home routers.

Where’s the Problem?

The problem is inside the API, specifically when using the ub_ctx_set_fwd and ub_ctx_resolvconf functions. If these are used in a certain order by an application, there’s a logic bug:

But, because of the order of function calls, that pointer is left as NULL.

- When it tries to use that pointer, boom: the program tries to access an invalid spot in memory and crashes.

In simple terms: a software expects something to be there, but it’s not, and this unexpected nothingness causes a crash.

Explaining with Code

Let’s see the risky sequence in the Unbound API (simplified version).

Suppose your application code looks like this

struct ub_ctx* ctx = ub_ctx_create();
ub_ctx_set_fwd(ctx, "1.1.1.1");
ub_ctx_resolvconf(ctx, "/etc/resolv.conf");
// Now calling any ub_resolve or ub_resolve_async will crash the app

Why does it crash?
The order matters. By setting a forwarder before telling Unbound to use the system’s resolv.conf file, if you then reset with ub_ctx_resolvconf, internal pointers are not correctly updated, leading to a crash when followed by other resolver operations.

Real-life Impact

Suppose you have a DNS service using Unbound’s API with the above sequence (maybe due to configuration reloading or user input). A malicious user (or even a misconfiguration) can trigger this bug. The worst that happens is a process crash — the DNS resolver goes down, and name resolution stops. In some setups, this could break entire networks.

Here’s a minimal program that triggers the bug

#include <unbound.h>

int main() {
    struct ub_ctx* ctx = ub_ctx_create();
    if (!ctx) return 1;

    ub_ctx_set_fwd(ctx, "8.8.8.8");
    ub_ctx_resolvconf(ctx, "/etc/resolv.conf");

    struct ub_result* result;
    // This will segfault:
    int r = ub_resolve(ctx, "example.com", 1, 1, &result);

    return ;
}

Compile and run on a vulnerable Unbound version. You’ll see a segmentation fault.

Upgrade: The best fix is to upgrade to the latest version of Unbound where this bug is fixed.

- Order of Calls: As a temporary workaround, avoid using ub_ctx_set_fwd and changing resolvconf in conflicting ways. Don’t mix these settings at runtime.

References and Further Reading

- NVD - CVE-2024-43167
- Unbound Project on GitHub
- Unbound Documentation

Summary

If you’re running Unbound or are using its API directly, check your version and code. This bug lets anyone who can control API calls crash your resolver. There’s no threat of taking over your system, but Denial of Service is still bad news if your infrastructure depends on it.

Timeline

Published on: 08/12/2024 13:38:35 UTC
Last modified on: 08/19/2024 16:59:38 UTC