Distracted..

This post is more about a side quest, as I was a bit distracted awaiting some responses on some UAF and Format string vulnerabilities submitted to a couple bug bounty programs.

In order to keep momentum going and my thirst for knowledge well fed with regards to vulnerability discovery and research, I wanted to start the next chronicle looking into applications that are again default to an OS installation. The virtual machine default that I am leveraging:

• Operating System: Debian GNU/Linux 12 (bookworm)
• Kernel: Linux 6.1.0-20-arm64
• Architecture: arm64

Out of the box it comes with a set of decent usable (open source) applications, particularly MS office and Google document competitor, LibreOffice.

Screenshot of LibreOffice Start Center/Community

As you can see from the screenshot above, the version that comes installed is LibreOffice 7.4.7.2. This helps orient me with how updated the applications maybe when I start reviewing advisories. Plus now I can leverage LibreOffice's source code instructions to get the right codebase version from the repository and review contributions/issues via their issue tracker, Gerrit

Past advisories

One of the methods I typically take when targeting an application, is reviewing past issues. Some developers and organizations do a great job managing/maintaining security related issues. You can typically find information via their website, code respositories or issue trackers. With LibreOffice, they maintain a little bit of the three. So I started reviewing LibreOffice's curated view of security issues with CVEs on their advisory page.

Advisories at the time of writing 4/28/24

There are several more but I decided to start from the top with CVE-2023-6186, also noted on MITRE. The reason I call out the MITRE CVE link, is because typically it contains a bit more references regarding the vulnerability. Sometimes CVE descriptions alone are not enough to determine the root cause of a bug. MITRE, NIST or other sources may also link to mailing lists, issue trackers, code patches or a POC. This is important to note because its probably one of the best ways you can learn about the target application code and what patches are applied.

And this is where my research takes a side quest and LibreOffice is put on pause...

The Quest

As noted the "references" field from MITRE should have some more context.

So I clicked around a bit only to be disappointed that more information wasnt available than what was in the initial advisory. However, the Fedoraproject list did have some buried context on the Bugzilla tracker for Redhat.

The ticket in bugzilla didnt have much more to offer but it did show how Redhat structures/triages the bugs and more importantly bugs identified as vulnerabilities since they may be downstream consumers of libraries and applications.

I like to note these types of systems as they a treasure trove for future vulnerability discovery and research.

Clicking the "show other bugs for this component", you are presented with a table of 37,445 vulnerability entries (at least at the time of this writing). Of course not all are new and not critical, but it does open up a world to explore what's out there. This is when I clicked about randomly and stumbled on a vulnerability related to a library called cJSON and its bugzilla report

cJSON Now and Later

Looking at the bug report it states that there is a "segmentation violaton", which is one of my favorite phrases to look for in comments, issues , and debug logs. Particuarly "segfault" is commonly seen when an applcation just gives up and crashes. This typically tells me there is a potential bug that might be worth investigating.

Following the "A segmentation fault in cJSON_SetValuestring" github issue, a comment links the vulnerable code with a POC.

This is where the quest gets a bit interesting... Almost as if I am about to talk to an NPC in an RPG that keeps me guessing on what to do next...

A user reported on March 25 2024 that the segfault happens when passing a NULL value to the object->valuestring of the cJSON_SetValuestring() function. The original snippet of code as reported below:

CJSON_PUBLIC(char*) cJSON_SetValuestring(cJSON *object, const char *valuestring)
{
    ···
    if (object->valuestring == NULL)
    {
        return NULL;
    }
    if (strlen(valuestring) <= strlen(object->valuestring))
    {
        strcpy(object->valuestring, valuestring);
        return object->valuestring;
    }
    ...
}

Now before we go further, one should look at this snippet of code (and the whole cJSON.c) and notice a couple things wrong and not just a NULL dereference happening. More about that latter if you can't find the issues.

You can see that one of the code maintainers would have preferred for this disclosure to be discussed in private and also notes that the user should have requested a CVE for this bug after a fix had been released. I have thoughts but we wont go there...for now.

They eventually get a fix for the NULL dereference. Unforunately it does not fix the issue at least from my perspective.

Below is the updated, outside merged code from the maintainer into main

    /* return NULL if the object is corrupted or valuestring is NULL */
    if (object->valuestring == NULL || valuestring == NULL)
    {
        return NULL;
    }
    if (strlen(valuestring) <= strlen(object->valuestring))
    {
        strcpy(object->valuestring, valuestring);
        return object->valuestring;
    }

Okay so now the code checks to make sure the pointer object or variable valuestring contains NULL and if it does just return NULL. But there needs to be further improvement.

What about that strlen() comparison? Does it account for the NULL byte?

• No

One can just take another short cut and use '<' rather than '<=' but the real solution there is to use strnlen(). This will allow for saftey checks against non-null terminated strings, preventing potential overflows by controlling max length that is read.

What about that strcpy()?

• No

Of course this is not great, this can lead to a buffer or a stack overflow if there are no bounds or limit checks. So without understanding further what the buffer purpose might be, it would be best practices to leverage strncpy() and explicitly set a null terminator.

If you look a little bit deeper at that merged request, there was a related issue opened but like other commits/comments pretty swiftly closed.

Things to highlight:

• Yes, this codebase seems to be rushed
• And YES the security policy is the same security policy state actors have inserted into projects before...
  • Most notably the recent open-source backdoor in XZ which almost compromised SSH
  • Also good write ups on tracking Jia Tan and here

Lastly at the bottom of the README.md you can see that "maintainer one" is the current maintainer but in issue #845, another individual, which will call "guest maintainer" was mentioned as a maintainer as well. Which if you have been following along or been curious about the SECURITY.md policy, all reports go to both those individuals.

I have to ask my self the question,

• How does a maintainer get chosen for these projects?
• What are the maintainers duties and guidelines?

Curious what the industry thinks about that.....

Previously on cJSON

Okay so we talked about issues in that small snippet of code...but remember how I stated I felt like I was trying to figure out what the NPC was telling me? Well turns out, this issue (literally the same issue) was reported by another user back on December 4th, 2023 and was also assigned a CVE-2023-50472. Again there was some back and forth comments on if it was an exploitable issue which might effect security boundaries. None the less the commit went in without futher validating if it truly resolved the issue as you may have already concluded.

Lingering questions and Later thoughts

It seems like cJSON has its place in the world and several thousands have liked or forked the project. Which could suggest that usage and implementation could be exponentially bigger in products we use daily, or maybe not.

Given the presence of bugs found and only two current maintainers who may, or may not have the ability to correctly identify rootCause->solution, it makes me wonder if there are valid attack vectors in products which use this code (or older versions) today. But also what happens when you have such a code base and no one to help identify, fix and validate security issues for a project that could be widely used.

The lightweightness of this project and what I glimpse, it seems projects/products such as Hauwei, Netgear, OpenWRT and Pi-hole (mostly edge and IoT devices?) may or may not have different versions of this code implemented today. Could be worth investigating for the future chronicle hunts with the below thoughts in mind:

• What remaining products use cJSON?
• This will probably lead to implementation dependent security bugs
• Who are these maintainers?
• How can we better audit code to validate working patches and other use cases on OSS projects?
• CVEs and CVE submission process needs better explaination for more junior devs

One thing I do know, Mark Dowd (mdowd) and Alisa Esage are right when they stated similar messages around sometimes you may find a bug early that may not be exploitable but code changes, which can change the effects making it a exploitable security bug in the future