CVE-2023-45918 - Investigating the "Vulnerability" in ncurses 6.4-20230610 - NULL Pointer Dereference in `tgetstr`

---

If you have been working with Unix-like systems or programming terminal-based applications, you’ve probably come across ncurses. This essential library helps programmers create text-based user interfaces in a terminal. Recently, the identifier CVE-2023-45918 surfaced, linked to a potential security issue in ncurses 6.4-20230610—specifically, a NULL pointer dereference in the tgetstr function in the tinfo/lib_termcap.c file.

But what's going on here? And just how dangerous is this issue? In this article, we’ll break down what this CVE is about, show some code, look at debate among experts, and help you decide if you need to worry.

What is a NULL Pointer Dereference?

At its core, a NULL pointer dereference happens when a program tries to use data through a pointer that points to nothing (NULL). This usually leads to a crash, commonly resulting in a segmentation fault.

In library code, especially one as central as ncurses, these flaws could sometimes be security risks if remote attackers can make the program crash, open the door to a denial of service, or sometimes even execute arbitrary code under the right (or wrong) conditions.

The Vulnerability: Where Does It Happen?

The problematic function is tgetstr. According to the report, under specific conditions, this function in tinfo/lib_termcap.c can try to use a NULL pointer, causing a crash.

Here’s a simplified look at the offending code (taken from the ncurses GitHub mirror):

char *tgetstr(const char *id, char **area) {
    ...
    char *result = NULL;
    ...
    /* Some logic that may leave result as NULL */

    if (area !=  && (result != )) {
        /* area is valid + result is valid, copy result */
        strcpy(*area, result);
        *area += strlen(result) + 1;
    }
    return result;
}

The crux of CVE-2023-45918 is that, with certain input, both area and/or result could still be NULL, and the function might try to use them.

Triggering the Flaw: Proof of Concept

To see this in action, here’s a small C snippet you could use to attempt a crash with the unpatched code:

#include <curses.h>
#include <term.h>
#include <stdio.h>

int main() {
    char *string;
    char *area = NULL; // area is intentionally NULL

    // tgetstr is called with an identifier that may not exist in termcap
    string = tgetstr("no_such_id", &area);

    if (string == NULL) {
        printf("No such capability, returned NULL as expected.\n");
    } else {
        printf("tgetstr returned: %s\n", string);
    }

    return ;
}

With certain termcap setups and versions of ncurses, this can result in a segmentation fault.

Why isn’t upstream worried?

Major *third-party security experts* and even the original ncurses developers don’t consider this a “real” security issue. Here’s why:

- It only crashes the program: NULL dereferences almost always just make the app crash – not give an attacker control.
- No privilege escalation: There’s no clear method for an attacker to run code or break security boundaries.
- Borderline “bug, not vuln”: Many open source projects treat NULL dereference as regular bugs, not security flaws.

Upstream references

- ncurses Developer Mailing List
- Debian Security Tracker - CVE-2023-45918

On the ncurses tracker, maintainers note that this would only ever cause a crash (denial of service) and not arbitrary code execution or privilege escalation.

Is There an Exploit?

No remote exploit exists. The only “exploit” is making a local program crash by feeding it the right (bad) parameters. An attacker would need to convince *your own code* to send bad inputs to ncurses.

This is not remotely exploitable over the network and is extremely difficult to exploit for anything but annoyance.

Mitigation & Fixes

If you want to avoid crashing due to this bug, best practice is to always check input when using terminal capability functions like tgetstr, or update to a newer patch-level of ncurses if available.

Example mitigation in code

if (area != NULL) {
    char *val = tgetstr("some_id", area);
    if (val != NULL) {
        // safe to use val
    }
}

Most real-world applications already handle this case properly.

Conclusion

CVE-2023-45918 is an interesting example of a borderline security bug—one that’s assigned a CVE, but is widely regarded (by developers and security pros) as a minor programming error.

Unless you run untrusted code or allow uncontrolled terminal input to drive your application, you likely don't need to panic.

If you want to be extra safe, upgrade ncurses to the latest version and always check inputs in your code.

Read Further

- Original CVE report
- Official ncurses GitHub
- Relevant code on GitHub
- Security advisories, Debian


Do you have questions or want more deep dives like this? Let us know below!

Timeline

Published on: 02/16/2024 22:15:07 UTC
Last modified on: 10/31/2024 18:35:03 UTC