30 Days of Bugs: Day 9

Welcome to "30 Days of Bugs," a campaign by 3Flatline, a startup that's all about making code safer. Our product, the Dixie Code Scanner, enabled by AI and machine learning (but also lots of normal and boring regular processes) to catch vulnerabilities that other tools miss. It doesn’t just find bugs—it also suggests fixes and writes test code to see if those vulnerabilities can be exploited. We're sharing a new bug every day from open-source projects to show just how powerful the Dixie Code Scanner is. These are real bugs that other tools didn't catch, highlighting that our scanner can make a real difference for developers and security researchers.

This is real output from our code scanner, minus the “tests” or code to help exploit the vulnerability (for obvious reasons). One day, we hope that we can stop prioritizing bugs based on CVEs and just automatically fix security vulnerabilities. Until then, we leverage the below output to reduce the amount of time you spend validating false positives or figuring out what your scanner is telling you.

And yes, for all you sneaky researchers out there: we have an offline version including LLM that can be run locally, or deploy into your tenant to keep you code secret and safe.

If you want to learn more, check out https://3flatline.ai or reach out to me here on LinkedIn. I’m happy to talk or give out free trial codes!

Today’s bug showcases Dixie's ability to work on assembly languages and comes from . . .

Memory Allocation Vulnerability in wifi driver in Mircotik routerOS.

https://mikrotik.com/download

File:

routeros-7.15.3-arm64/fileSystem/bndl/wifi/nova/bin/ww2

Code Description:

The code defines a function named sub_43b28 that takes a pointer to an integer (`int32_t* arg1`) as an argument. Within the function, it allocates 32 bytes of memory (enough to hold four 32-bit integers) using malloc and assigns the pointer to this allocated memory to the variable r0. The function initializes the first three integers in the allocated memory to zero and sets the fourth integer to the value pointed to by arg1. It then calls another function, sub_9b284, passing a pointer to the fifth integer in the allocated memory and the second integer from the input pointer arg1. Finally, the function returns the pointer r0, which points to the newly allocated and initialized memory.

Vuln Class: Memory Allocation Vulnerability

Summary:

    int32_t* r0 = malloc(0x20);        

The function allocates 32 bytes of memory using malloc without checking if the allocation was successful. If malloc fails, r0 will be NULL, and subsequent dereferencing of r0 will lead to undefined behavior, potentially causing a segmentation fault or memory corruption. To test this issue, you can simulate low memory conditions to observe the behavior of the application when malloc returns NULL.

Assessment: True

Confidence Level: High confidence.

The report accurately identifies the lack of a check for the success of the malloc call. If malloc fails and returns NULL, dereferencing r0 will indeed lead to undefined behavior, which aligns with the summary provided in the vulnerability report. The potential consequences of this oversight, such as segmentation faults or memory corruption, are correctly noted.