A newly discovered malware has been put to use in the wild at least since March 2021 to backdoor Microsoft Exchange servers belonging to a wide range of entities worldwide, with infections lingering in 20 organizations as of June 2022.
Dubbed SessionManager, the malicious tool masquerades as a module for Internet Information Services (IIS), a web server software for Windows systems, after

A newly discovered malware has been put to use in the wild at least since March 2021 to backdoor Microsoft Exchange servers belonging to a wide range of entities worldwide, with infections lingering in 20 organizations as of June 2022.

Dubbed **SessionManager**, the malicious tool masquerades as a module for Internet Information Services (IIS), a web server software for Windows systems, after exploiting one of the ProxyLogon flaws within Exchange servers.

Targets included 24 distinct NGOs, government, military, and industrial organizations spanning Africa, South America, Asia, Europe, Russia and the Middle East. A total of 34 servers have been compromised by a SessionManager variant to date.

This is far from the first time the technique has been observed in real-world attacks. The use of a rogue IIS module as a means to distribute stealthy implants mirrors the tactics of a credential stealer called Owowa that came to light in December 2021.

"Dropping an IIS module as a backdoor enables threat actors to maintain persistent, update-resistant and relatively stealthy access to the IT infrastructure of a targeted organization; be it to collect emails, update further malicious access, or clandestinely manage compromised servers that can be leveraged as malicious infrastructure," Kaspersky researcher Pierre Delcher said.

The Russian cybersecurity firm attributed the intrusions with medium-to-high confidence to an adversary tracked as Gelsemium, citing overlaps in the malware samples linked to the two groups and victims targeted.

ProxyLogon, since its disclosure in March 2021, has attracted the repeated attention of several threat actors, and the latest attack chain is no exception, with the Gelsemium crew exploiting the flaws to drop SessionManager, a backdoor coded in C++ and is engineered to process HTTP requests sent to the server.

"Such malicious modules usually expect seemingly legitimate but specifically crafted HTTP requests from their operators, trigger actions based on the operators' hidden instructions if any, then transparently pass the request to the server for it to be processed just like any other request," Delcher explained.

Said to be a "lightweight persistent initial access backdoor," SessionManager comes with capabilities to read, write, and delete arbitrary files; execute binaries from the server; and establish communications with other endpoints in the network.

The malware further acts as a covert channel to conduct reconnaissance, gather in-memory passwords, and deliver additional tools such as Mimikatz as well as a memory dump utility from Avast.

The findings come as the U.S. Cybersecurity and Infrastructure Security Agency (CISA) urged government agencies and private sector entities using the Exchange platform to switch from the legacy Basic Authentication method to Modern Authentication alternatives prior to its deprecation on October 1, 2022.

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

New 'SessionManager' Backdoor Targeting Microsoft IIS Servers in the Wild

Researchers say the remote-access Trojan ZuoRAT is likely the work of a nation-state and has infected at least 80 different targets.

An unusually advanced hacking group has spent almost two years infecting a wide range of routers in North America and Europe with malware that takes full control of connected devices running Windows, macOS, and Linux, researchers reported on June 28.

So far, researchers from Lumen Technologies' Black Lotus Labs say they've identified at least 80 targets infected by the stealthy malware, including routers made by Cisco, Netgear, Asus, and DrayTek. Dubbed ZuoRAT, the remote access Trojan is part of a broader hacking campaign that has existed since at least the fourth quarter of 2020 and continues to operate.

A High Level of Sophistication

The discovery of custom-built malware written for the MIPS architecture and compiled for small-office and home-office routers is significant, particularly given its range of capabilities. Its ability to enumerate all devices connected to an infected router and collect the DNS lookups and network traffic they send and receive and remain undetected is the hallmark of a highly sophisticated threat actor.

"While compromising SOHO routers as an access vector to gain access to an adjacent LAN is not a novel technique, it has seldom been reported," Black Lotus Labs researchers wrote. "Similarly, reports of person-in-the-middle style attacks, such as DNS and HTTP hijacking, are even rarer and a mark of a complex and targeted operation. The use of these two techniques congruently demonstrated a high level of sophistication by a threat actor, indicating that this campaign was possibly performed by a state-sponsored organization."

The campaign comprises at least four pieces of malware, three of them written from scratch by the threat actor. The first piece is the MIPS-based ZuoRAT, which closely resembles the Mirai internet-of-things malware that achieved record-breaking distributed denial-of-service attacks that crippled some Internet services for days. ZuoRAT often gets installed by exploiting unpatched vulnerabilities in SOHO devices.

Once installed, ZuoRAT enumerates the devices connected to the infected router. The threat actor can then use DNS hijacking and HTTP hijacking to cause the connected devices to install other malware. Two of those malware pieces—dubbed CBeacon and GoBeacon—are custom-made, with the first written for Windows in C++ and the latter written in Go for cross-compiling on Linux and macOS devices. For flexibility, ZuoRAT can also infect connected devices with the widely used Cobalt Strike hacking tool.

ZuoRAT can pivot infections to connected devices using one of two methods:

*   DNS hijacking, which replaces the valid IP addresses corresponding to a domain such as Google or Facebook with a malicious one operated by the attacker.
*   HTTP hijacking, in which the malware inserts itself into the connection to generate a 302 error that redirects the user to a different IP address.

Intentionally Complex

Black Lotus Labs said the command-and-control infrastructure used in the campaign is intentionally complex in an attempt to conceal what's happening. One set of infrastructure is used to control infected routers, and another is reserved for the connected devices if they're later infected.

The researchers observed routers from 23 IP addresses with a persistent connection to a control server that they believe was performing an initial survey to determine if the targets were of interest. A subset of those 23 routers later interacted with a Taiwan-based proxy server for three months. A further subset of routers rotated to a Canada-based proxy server to obfuscate the attacker's infrastructure.

The researchers wrote:

_Black Lotus Labs visibility indicates ZuoRAT and the correlated activity represent a highly targeted campaign against US and Western European organizations that blends in with typical internet traffic through obfuscated, multistage C2 infrastructure, likely aligned with multiple phases of the malware infection. The extent to which the actors take pains to hide the C2 infrastructure cannot be overstated. First, to avoid suspicion, they handed off the initial exploit from a dedicated virtual private server (VPS) that hosted benign content. Next, they leveraged routers as proxy C2s that hid in plain sight through router-to-router communication to further avoid detection. And finally, they rotated proxy routers periodically to avoid detection._

The discovery of this ongoing campaign is the most important one affecting SOHO routers since VPNFilter, the router malware created and deployed by the Russian government that was discovered in 2018. Routers are often overlooked, particularly in the work-from-home era. While organizations often have strict requirements for what devices are allowed to connect, few mandate patching or other safeguards for the devices' routers.

Like most router malware, ZuoRAT can't survive a reboot. Simply restarting an infected device will remove the initial ZuoRAT exploit, consisting of files stored in a temporary directory. To fully recover, however, infected devices should be factory reset. Unfortunately, in the event connected devices have been infected with the other malware, they can't be disinfected so easily.

_This story originally appeared on_ _Ars Technica__._

A New, Remarkably Sophisticated Malware Is Attacking Routers

The malware has been in circulation since 2020, with sophisticated, advanced malicious actors taking advantage of the vulnerabilities in SOHO routers as the work-from-home population expands rapidly.

Security researchers have discovered a multi-stage remote access Trojan (RAT) currently being used against a wide range of small office-home office (SOHO) routers in Europe and North America — potentially the work of a state-sponsored actor.

Researchers believe that at least 80 victims have been infected so far during the campaign.

The malware, known as ZuoRAT, has been active since 2020, according to the Black Lotus Labs, the threat intelligence arm of Lumen Technologies.

According to the report, the malware makes its way onto the routers through exploits for known vulnerabilities. It can also infect other devices in the network and introduce additional malware via DNS and HTTP hijacking.

"ZuoRAT is a MIPS file compiled for SOHO routers that can enumerate a host and internal LAN, capture packets being transmitted over the infected device, and perform person-in-the-middle attacks (DNS and HTTPS hijacking based on predefined rules)," Lumen's threat intelligence team wrote in a blog post on the malware.

**Trojan Targets Cisco, Netgear Routers**

The malware targets routers from Cisco, Netgear, Asus, and DrayTek.

"The device types consisted of, but were not limited to: Cisco RV 320, 325 and 420; Asus RT-AC68U, RT-AC530, RT-AC68P and RT-AC1900U; DrayTek Vigor 3900 and unspecified NETGEAR devices," according to the analysis.

The research team noted that while compromising SOHO routers as an access vector to gain access to an adjacent LAN is not a novel technique, it has seldom been reported.

"Reports of person-in-the-middle style attacks, such as DNS and HTTP hijacking, are \[rare\] and a mark of a complex and targeted operation," the post continued. "The use of these two techniques congruently demonstrated a high level of sophistication by a threat actor, indicating that this campaign was possibly performed by a state-sponsored organization."

From the perspective of Danny Adamitis, principal information security engineer for Lumen Black Lotus Labs, the sophistication of this campaign cannot be overstated, especially the ability to enumerate infected devices and the LANs they are connected to, and packet-capture network traffic for additional targeting.

"Moreover, the multi-stage campaign includes multiple fully functional Trojans, as well as complex and covert C2 and proxy C2 infrastructure to obfuscate command-and-control and evade detection, which is why it went undetected for nearly two years," he adds.

**Other Trojans Found on Hacked Devices**

To Adamitis' point, the researchers found two other Trojans on the hacked devices. One was based on C++ and targeted Windows workstations. The other Trojan was based on the Go programming language and attacked Linux and macOS as well as Windows.

Among other things, they allowed the attackers to start new processes, gain permanent access to infected systems, intercept network traffic, and upload or download arbitrary files.

**Shift to Secure the Home Office**

According to a recent survey, nearly a quarter of the respondents (23%) named securing the remote workforce as their top priority for 2022. Routers are an important part of that, as they act as central waypoints for the rest of the home IT footprint.

"Once you are on the router you have a full trusted connection to poke and prod at whatever device is connected to it," Dahvid Schloss, offensive security team lead at Echelon, said via email. "From there, you could attempt to use proxychains to throw exploits into the network or just monitor all the traffic going in, out, and around the network."

So, as part of the work-from-home shift, some major vendors are moving their security focus, such as HP, which helps admins secure work-from-home endpoints by extending cloud security management that can remotely track, detect, and self-heal remote company devices.

"The consumer router space is ripe for targeting because these devices reside outside of the traditional security perimeter, and they are rarely monitored or patched," Adamitis adds. "This is only exacerbated by the rapid shift to remote work at the start of the pandemic."

Alex Ondrick, director of security operations at incident-response specialist BreachQuest, says a general lack of security controls for consumer-grade routers, and difficulties in "force" patching/update for them, makes SOHO routers particularly vulnerable.

"If a SOHO router is unpatched or vulnerable to known security flaws, ZuoRAT poses a dangerous combination of reconnaissance and authentication-bypass exploit script and lateral-movement capabilities," he explains.

**Bolstering the Human Firewall**

Ondrick adds that the SOHO router threat is an opportunity for organizations to expand their security awareness programs and spread valuable improved security measures among their users.

"Educating users on how to protect their home networks, their passwords, their financial information, and their families increases their engagement and builds cybersecurity hygiene and acumen they take back to the office, and reduces the organization's attack surface and builds the better human firewall," he says.

He says SOHO users should regularly update their router's firmware and ensure their devices are behind multiple layers of security (defense-in-depth) wherever possible.

For home routers, he says it's important to leverage the vendor's built-in security capabilities alongside host-based network security wherever possible.

"Think of your home router as 'yet another' device which should be regularly updated and think of it as the 'first line of defense' between you and the public-facing Internet," he says. "Pending any leaps forward in SOHO router security, consider adding a recurring biannual reminder on your phone or calendar to check for updates on your router's firmware."

ZuoRAT Hijacks SOHO Routers From Cisco, Netgear

A binary hijack in Orwell-Dev-Cpp v5.11 allows attackers to execute arbitrary code via a crafted .exe file.

**Orwell-Dev-Cpp CreateProcessW Misuse Binary Hijack****Basic Info**

**Software name**：Orwell dev-cpp

**download**：https://sourceforge.net/projects/orwelldevcpp/

**Vuln Version**：v5.11and before

**Description**：When users run Dev-cpp in windows, we can see that it will try to run C:\\Program.exe, if C:\\Program.exe not exists, then it will run C:\\Program Files (x86)\\MingGW64\\bin\\gcc.exe. So an attacker can put C:\\Program.exe in C:, and it will execute arbitrary code when other users run Dev-Cpp.

**Analyse**

When we start devcpp.exe in windows, we can see that it will try to start process C:\Program Files (x86)\MingGW64\bin\gcc.exe with CreateProcessA

This vuln occured because the developer misuse CreateProcesAs API in AcGeneral.dll .

So an attacker which have write permission of C:\\ can place binary named C:\\Program.exe. And it will be executed when embarcadero dev-cpp started.

**Proof of Concept**

Poc Vedio

CVE-2022-33037: Vuln/Orwell-Dev-Cpp-CreateProcessA-Misuse-Binary-Hijack.md at main · ycdxsb/Vuln

A binary hijack in Embarcadero Dev-CPP v6.3 allows attackers to execute arbitrary code via a crafted .exe file.

**Embarcadero-Dev-Cpp CreateProcessW Misuse Binary Hijack****Basic Info**

**Software name**：embarcadero dev-cpp

**download**：https://github.com/Embarcadero/Dev-Cpp

**Vuln Version**：v6.3 and before

**Description**：When users run Dev-cpp in windows, we can see that it will try to run C:\\Program.exe, if C:\\Program.exe not exists, then it will run C:\\Program Files (x86)\\Embarcadero\\Dev-Cpp\\TDM-GCC-64\\bin\\gcc.exe. So an attacker can put C:\\Program.exe in C:, and it will execute arbitrary code when other users run Dev-Cpp.

**Analyse**

When we start devcpp.exe in windows, we can see that it will try to start process C:\Program Files (x86)\Embarcadero\Dev-cpp\TDM-GCC-64\bin\gcc.exe with CreateProcessW

This vuln occured because the developer misuse CreateProcess API. We can find it by the call stack.

An attacker which have write permission of C:\\ can place binary named C:\\Program.exe. And it will be executed when embarcadero dev-cpp started.

**Proof of Concept**

Poc Vedio

CVE-2022-33036: Vuln/Embarcadero-Dev-Cpp-CreateProcessW-Misuse-Binary-Hijack.md at main · ycdxsb/Vuln

The GetHintFormat function in GPAC 1.0.1 allows attackers to cause a denial of service via a crafted file in the MP4Box command.

*   I looked for a similar issue and couldn't find any.
*   I tried with the latest version of GPAC. Installers available at http://gpac.io/downloads/gpac-nightly-builds/
*   I give enough information for contributors to reproduce my issue (meaningful title, github labels, platform and compiler, command-line ...).

It's a heap-buffer-overflow bug

Step to reproduce:  
1.get latest commit code (GPAC version 1.1.0-DEV-rev1170-g592ba26-master)  
2.compile with --enable-sanitizer  
3.run ./MP4BOX info poc

Env:  
Ubunut 20.04 , clang 12.0.1

ASAN report

    ==2275020==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x604000000638 at pc 0x7f1c17ca68a4 bp 0x7ffd52eab1d0 sp 0x7ffd52eab1c8
    READ of size 4 at 0x604000000638 thread T0
        #0 0x7f1c17ca68a3 in GetHintFormat /home/lly/pro/gpac_public/src/isomedia/hint_track.c:46:22
        #1 0x7f1c17ca68a3 in CheckHintFormat /home/lly/pro/gpac_public/src/isomedia/hint_track.c:58:6
        #2 0x7f1c17ca68a3 in gf_isom_get_payt_count /home/lly/pro/gpac_public/src/isomedia/hint_track.c:979:7
        #3 0x5b52e5 in DumpTrackInfo /home/lly/pro/gpac_public/applications/mp4box/filedump.c:3178:14
        #4 0x5e4af1 in DumpMovieInfo /home/lly/pro/gpac_public/applications/mp4box/filedump.c:3789:3
        #5 0x52ea16 in mp4boxMain /home/lly/pro/gpac_public/applications/mp4box/main.c:6023:9
        #6 0x7f1c15d710b2 in __libc_start_main /build/glibc-eX1tMB/glibc-2.31/csu/../csu/libc-start.c:308:16
        #7 0x429aad in _start (/home/lly/pro/gpac_public/bin/gcc/MP4Box+0x429aad)
    
    0x604000000638 is located 0 bytes to the right of 40-byte region [0x604000000610,0x604000000638)
    allocated by thread T0 here:
        #0 0x4a496d in malloc (/home/lly/pro/gpac_public/bin/gcc/MP4Box+0x4a496d)
        #1 0x7f1c17543a17 in nmhd_box_new /home/lly/pro/gpac_public/src/isomedia/box_code_base.c:4651:2
        #2 0x7f1c1775de4f in gf_isom_box_new_ex /home/lly/pro/gpac_public/src/isomedia/box_funcs.c:1673:6
        #3 0x7f1c17756209 in gf_isom_box_parse_ex /home/lly/pro/gpac_public/src/isomedia/box_funcs.c:239:12
        #4 0x7f1c17760a0b in gf_isom_box_array_read_ex /home/lly/pro/gpac_public/src/isomedia/box_funcs.c:1707:7
        #5 0x7f1c1751e43a in minf_box_read /home/lly/pro/gpac_public/src/isomedia/box_code_base.c:3527:6
        #6 0x7f1c17757fe8 in gf_isom_box_read /home/lly/pro/gpac_public/src/isomedia/box_funcs.c:1810:9
        #7 0x7f1c17757fe8 in gf_isom_box_parse_ex /home/lly/pro/gpac_public/src/isomedia/box_funcs.c:263:14
        #8 0x7f1c17760a0b in gf_isom_box_array_read_ex /home/lly/pro/gpac_public/src/isomedia/box_funcs.c:1707:7
        #9 0x7f1c17511b3d in mdia_box_read /home/lly/pro/gpac_public/src/isomedia/box_code_base.c:3078:6
        #10 0x7f1c17757fe8 in gf_isom_box_read /home/lly/pro/gpac_public/src/isomedia/box_funcs.c:1810:9
        #11 0x7f1c17757fe8 in gf_isom_box_parse_ex /home/lly/pro/gpac_public/src/isomedia/box_funcs.c:263:14
        #12 0x7f1c17760a0b in gf_isom_box_array_read_ex /home/lly/pro/gpac_public/src/isomedia/box_funcs.c:1707:7
        #13 0x7f1c17582c10 in trak_box_read /home/lly/pro/gpac_public/src/isomedia/box_code_base.c:6734:6
        #14 0x7f1c17757fe8 in gf_isom_box_read /home/lly/pro/gpac_public/src/isomedia/box_funcs.c:1810:9
        #15 0x7f1c17757fe8 in gf_isom_box_parse_ex /home/lly/pro/gpac_public/src/isomedia/box_funcs.c:263:14
        #16 0x7f1c17760a0b in gf_isom_box_array_read_ex /home/lly/pro/gpac_public/src/isomedia/box_funcs.c:1707:7
        #17 0x7f1c17757fe8 in gf_isom_box_read /home/lly/pro/gpac_public/src/isomedia/box_funcs.c:1810:9
        #18 0x7f1c17757fe8 in gf_isom_box_parse_ex /home/lly/pro/gpac_public/src/isomedia/box_funcs.c:263:14
        #19 0x7f1c177548b9 in gf_isom_parse_root_box /home/lly/pro/gpac_public/src/isomedia/box_funcs.c:38:8
        #20 0x7f1c177e2347 in gf_isom_parse_movie_boxes_internal /home/lly/pro/gpac_public/src/isomedia/isom_intern.c:320:7
        #21 0x7f1c177e2347 in gf_isom_parse_movie_boxes /home/lly/pro/gpac_public/src/isomedia/isom_intern.c:781:6
        #22 0x7f1c177f84d3 in gf_isom_open_file /home/lly/pro/gpac_public/src/isomedia/isom_intern.c:901:19
        #23 0x53c4b8 in mp4boxMain /home/lly/pro/gpac_public/applications/mp4box/main.c:5841:12
        #24 0x7f1c15d710b2 in __libc_start_main /build/glibc-eX1tMB/glibc-2.31/csu/../csu/libc-start.c:308:16
    
    SUMMARY: AddressSanitizer: heap-buffer-overflow /home/lly/pro/gpac_public/src/isomedia/hint_track.c:46:22 in GetHintFormat
    Shadow bytes around the buggy address:
      0x0c087fff8070: fa fa 00 00 00 00 04 fa fa fa 00 00 00 00 00 00
      0x0c087fff8080: fa fa 00 00 00 00 00 00 fa fa 00 00 00 00 00 00
      0x0c087fff8090: fa fa 00 00 00 00 00 fa fa fa 00 00 00 00 00 00
      0x0c087fff80a0: fa fa 00 00 00 00 00 fa fa fa 00 00 00 00 00 00
      0x0c087fff80b0: fa fa 00 00 00 00 00 fa fa fa 00 00 00 00 00 00
    =>0x0c087fff80c0: fa fa 00 00 00 00 00[fa]fa fa 00 00 00 00 00 00
      0x0c087fff80d0: fa fa 00 00 00 00 00 fa fa fa 00 00 00 00 00 00
      0x0c087fff80e0: fa fa 00 00 00 00 00 fa fa fa 00 00 00 00 00 fa
      0x0c087fff80f0: fa fa 00 00 00 00 00 fa fa fa 00 00 00 00 00 00
      0x0c087fff8100: fa fa 00 00 00 00 00 fa fa fa 00 00 00 00 00 00
      0x0c087fff8110: fa fa 00 00 00 00 00 00 fa fa 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
    
    

poc.zip

CVE-2021-40609: heap-buffer-overflow in MP4BOX at souce file src/isomedia/hint_track.c:46 · Issue #1894 · gpac/gpac

The gf_hinter_track_finalize function in GPAC 1.0.1 allows attackers to cause a denial of service via a crafted file in the MP4Box command.

*   I looked for a similar issue and couldn't find any.
*   I tried with the latest version of GPAC. Installers available at http://gpac.io/downloads/gpac-nightly-builds/
*   I give enough information for contributors to reproduce my issue (meaningful title, github labels, platform and compiler, command-line ...).

It's a pointer free on unknown addrees bug caused by freeing a uninitialized pointer.

Step to reproduce:  
1.get latest commit code (GPAC version 1.1.0-DEV-rev1170-g592ba26-master)  
2.compile with --enable-sanitizer  
3.run ./MP4BOX -hint poc\_isom\_hinter -out /dev/null

Env:  
Ubunut 20.04 , clang 10.0.0

ASAN report

    ==40495==ERROR: AddressSanitizer: SEGV on unknown address 0x7f0eebe5ccf8 (pc 0x7f0eef8765fc bp 0x7f0eebe5ccf8 sp 0x7ffecbe40880 T0)
        #0 0x7f0eef8765fb  (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x215fb)
        #1 0x7f0eef8ed29d in __interceptor_free (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x9829d)
        #2 0x7f0eed579cb9 in gf_hinter_track_finalize media_tools/isom_hinter.c:956
        #3 0x42842d in HintFile /home/lly/gpac_public/applications/mp4box/main.c:3533
        #4 0x42e4e4 in mp4boxMain /home/lly/gpac_public/applications/mp4box/main.c:6329
        #5 0x7f0eead8983f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2083f)
        #6 0x413bc8 in _start (/home/lly/gpac_public/bin/gcc/MP4Box+0x413bc8)
    

Buggy code and reason:  
in isom\_hinter.c:950

    for (i=0; i<gf_isom_get_sample_description_count(tkHint->file, tkHint->TrackNum); i++) {
        u8 *tx3g;   <---with out init
        ...
        gf_isom_text_get_encoded_tx3g(..., &tx3g, &tx3g_len);  <--- supposed to init tx3g
        ...
        gf_free(tx3g); <--- free tx3g
       ...
    		}
    

It is supposed to init tx3g in gf\_isom\_text\_get\_encoded\_tx3g, but in gf\_isom\_text\_get\_encoded\_tx3g, it might forget that mission.

    GF_Err gf_isom_text_get_encoded_tx3g(GF_ISOFile *file, u32 track, u32 sidx, u32 sidx_offset, u8 **tx3g, u32 *tx3g_size)
    {
    	...
            //  it returns without init tx3g once a->type equals another value;
    	if ((a->type != GF_ISOM_BOX_TYPE_TX3G) && (a->type != GF_ISOM_BOX_TYPE_TEXT)) return GF_BAD_PARAM;
    
    	...
    	*tx3g = NULL;  <--- real init here
    	*tx3g_size = 0;
    	gf_bs_get_content(bs, tx3g, tx3g_size);
    	gf_bs_del(bs);
    	return GF_OK;
    }
    

poc\_isom\_hinter.zip

CVE-2021-40608: BUG : free on unknown addrees in MP4BOX at  gf_hinter_track_finalize media_tools/isom_hinter.c:956 · Issue #1883 · gpac/gpac

The schm_box_size function in GPAC 1.0.1 allows attackers to cause a denial of service via a crafted file in the MP4Box command.

*   I looked for a similar issue and couldn't find any.
*   I tried with the latest version of GPAC. Installers available at http://gpac.io/downloads/gpac-nightly-builds/
*   I give enough information for contributors to reproduce my issue (meaningful title, github labels, platform and compiler, command-line ...).

It's a heap-buffer-overflow bug caused by missing '\\0' check of the end of URI.

**Step to reproduce:**  
1.get latest commit code (MP4Box - GPAC version 1.1.0-DEV-rev1169-gbbd741e-master)  
2.compile with --enable-sanitizer  
3.run ./MP4BOX -hint poc -out /dev/null

**Env:**  
Ubunut 20.04 , clang 10.0.0

**ASAN report**

    ==789683==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x604000000bb7 at pc 0x7f277ca50a6d bp 0x7ffd14f790b0 sp 0x7ffd14f78858
    READ of size 40 at 0x604000000bb7 thread T0
        #0 0x7f277ca50a6c  (/lib/x86_64-linux-gnu/libasan.so.5+0x67a6c)
        #1 0x7f277a6d0ece in schm_box_size isomedia/box_code_drm.c:179
        #2 0x7f277a7569f1 in gf_isom_box_size_listing isomedia/box_funcs.c:1903
        #3 0x7f277a7569f1 in gf_isom_box_size isomedia/box_funcs.c:1915
        #4 0x7f277a805c14 in WriteInterleaved isomedia/isom_store.c:1870
        #5 0x7f277a8086d3 in WriteToFile isomedia/isom_store.c:2527
        #6 0x7f277a7a73d9 in gf_isom_write isomedia/isom_read.c:600
        #7 0x7f277a7a778f in gf_isom_close isomedia/isom_read.c:624
        #8 0x562161c082db in mp4boxMain /home/lly/pro/gpac_public/applications/mp4box/main.c:6401
        #9 0x7f27799da0b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
        #10 0x562161bd2bdd in _start (/home/lly/pro/gpac_public/bin/gcc/MP4Box+0x4abdd)
    
    0x604000000bb7 is located 0 bytes to the right of 39-byte region [0x604000000b90,0x604000000bb7)
    allocated by thread T0 here:
        #0 0x7f277caf6bc8 in malloc (/lib/x86_64-linux-gnu/libasan.so.5+0x10dbc8)
        #1 0x7f277a6d08b7 in schm_box_read isomedia/box_code_drm.c:148
    
    SUMMARY: AddressSanitizer: heap-buffer-overflow (/lib/x86_64-linux-gnu/libasan.so.5+0x67a6c)
    Shadow bytes around the buggy address:
      0x0c087fff8120: fa fa fd fd fd fd fd fd fa fa fd fd fd fd fd fd
      0x0c087fff8130: fa fa fd fd fd fd fd fa fa fa fd fd fd fd fd fa
      0x0c087fff8140: fa fa fd fd fd fd fd fd fa fa 00 00 00 00 00 01
      0x0c087fff8150: fa fa 00 00 00 00 04 fa fa fa 00 00 00 00 05 fa
      0x0c087fff8160: fa fa 00 00 00 00 00 06 fa fa 00 00 00 00 02 fa
    =>0x0c087fff8170: fa fa 00 00 00 00[07]fa fa fa 00 00 00 00 00 00
      0x0c087fff8180: fa fa 00 00 00 00 00 00 fa fa 00 00 00 00 00 00
      0x0c087fff8190: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c087fff81a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c087fff81b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c087fff81c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
    

**Buggy code and reason:**

    GF_Err schm_box_size(GF_Box *s)
    {
    	GF_SchemeTypeBox *ptr = (GF_SchemeTypeBox *) s;
    	if (!s) return GF_BAD_PARAM;
    	ptr->size += 8;
    	if (ptr->flags & 0x000001) ptr->size += 1 + (ptr->URI ? strlen(ptr->URI) : 0);   <---strlen overflow once URI does not end with '\0'
    	return GF_OK;
    }
    

poc.zip

CVE-2021-40607: BUG: heap-buffer-overflow  in MP4Box at src/isomedia/schm_box_size:179 · Issue #1879 · gpac/gpac

The gf_bs_write_data function in GPAC 1.0.1 allows attackers to cause a denial of service via a crafted file in the MP4Box command.

*   I looked for a similar issue and couldn't find any.
*   I tried with the latest version of GPAC. Installers available at http://gpac.io/downloads/gpac-nightly-builds/
*   I give enough information for contributors to reproduce my issue (meaningful title, github labels, platform and compiler, command-line ...).

It's a memcpy from unknown addrees bug.

Step to reproduce:  
1.get latest commit code (GPAC version 1.1.0-DEV-rev1170-g592ba2689-master)  
2.compile with --enable-sanitizer  
3.run ./MP4BOX -hint poc\_isom\_hinter -out /dev/null

Env:  
Ubunut 20.04 , clang 12.0.1

ASAN report

    =================================================================
    ==194694==ERROR: AddressSanitizer: unknown-crash on address 0x03e8ef58ac20 at pc 0x0000004a3cd7 bp 0x7ffdef589370 sp 0x7ffdef588b38
    READ of size 24912 at 0x03e8ef58ac20 thread T0
        #0 0x4a3cd6 in __asan_memcpy (/home/lly/pro/gpac_public/bin/gcc/MP4Box+0x4a3cd6)
        #1 0x7f35556d80ef in gf_bs_write_data /home/lly/pro/gpac_public/src/utils/bitstream.c:1028:4
        #2 0x7f3555da5a1a in gf_odf_write_default /home/lly/pro/gpac_public/src/odf/odf_code.c:1320:3
        #3 0x7f3555da92ec in gf_odf_desc_write_bs /home/lly/pro/gpac_public/src/odf/odf_codec.c:325:6
        #4 0x7f3555da92ec in gf_odf_desc_write /home/lly/pro/gpac_public/src/odf/odf_codec.c:343:6
        #5 0x7f3555da9661 in gf_odf_desc_copy /home/lly/pro/gpac_public/src/odf/odf_codec.c:387:6
        #6 0x7f3555cb8760 in gf_isom_set_extraction_slc /home/lly/pro/gpac_public/src/isomedia/isom_write.c:5468:9
        #7 0x7f3555fa467b in gf_hinter_finalize /home/lly/pro/gpac_public/src/media_tools/isom_hinter.c:1245:5
        #8 0x4e8d21 in HintFile /home/lly/pro/gpac_public/applications/mp4box/main.c:3550:2
        #9 0x4f5988 in mp4boxMain /home/lly/pro/gpac_public/applications/mp4box/main.c:6329:7
        #10 0x7f355476d0b2 in __libc_start_main /build/glibc-eX1tMB/glibc-2.31/csu/../csu/libc-start.c:308:16
        #11 0x429a6d in _start (/home/lly/pro/gpac_public/bin/gcc/MP4Box+0x429a6d)
    
    Address 0x03e8ef58ac20 is located in the high shadow area.
    

Buggy code  
in bitstream.c:

    u32 gf_bs_write_data(GF_BitStream *bs, const u8 *data, u32 nbBytes)
    {
    ...
    memcpy(bs->original + bs->position - bs->bytes_out, data, nbBytes);  <---data is not inited
    ...
    }
    

poc.zip

CVE-2021-40606: Bug: Memcpy from unknown addrees in MP4BOX at src/utils/bitstream.c:1028 · Issue #1885 · gpac/gpac

In Bento4 1.6.0-638, there is a null pointer reference in the function AP4_DescriptorListInspector::Action function in Ap4Descriptor.h:124 , as demonstrated by GPAC. This can cause a denial of service (DOS).

New issue

**Have a question about this project?** Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open

AntsKnows opened this issue

Aug 25, 2021

· 0 comments

**Comments**

How to reproduce:

    1.check out latest code, 5922ba762a
    2.compile with asan, 
        set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -fsanitize=address  -g")
        set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fsanitize=address  -g")
    3.run ./mp4dump --verbosity 3 --format text  poc
    

You can see the asan information below:

    
    =================================================================
    ==633802==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x0000003c3e48 bp 0x7ffcbc9d4550 sp 0x7ffcbc9d4470 T0)
    ==633802==The signal is caused by a READ memory access.
    ==633802==Hint: address points to the zero page.
        #0 0x3c3e48 in AP4_DescriptorListInspector::Action(AP4_Descriptor*) const /home/lly/pro/Bento4/Source/C++/Core/Ap4Descriptor.h:124:21
        #1 0x40bdc2 in AP4_List<AP4_Descriptor>::Apply(AP4_List<AP4_Descriptor>::Item::Operator const&) const /home/lly/pro/Bento4/Source/C++/Core/Ap4List.h:353:12
        #2 0x40bdc2 in AP4_InitialObjectDescriptor::Inspect(AP4_AtomInspector&) /home/lly/pro/Bento4/Source/C++/Core/Ap4ObjectDescriptor.cpp:327:22
        #3 0x3e0485 in AP4_IodsAtom::InspectFields(AP4_AtomInspector&) /home/lly/pro/Bento4/Source/C++/Core/Ap4IodsAtom.cpp:112:29
        #4 0x37117e in AP4_Atom::Inspect(AP4_AtomInspector&) /home/lly/pro/Bento4/Source/C++/Core/Ap4Atom.cpp:263:5
        #5 0x39f0a2 in AP4_AtomListInspector::Action(AP4_Atom*) const /home/lly/pro/Bento4/Source/C++/Core/Ap4Atom.h:601:15
        #6 0x39d3b1 in AP4_List<AP4_Atom>::Apply(AP4_List<AP4_Atom>::Item::Operator const&) const /home/lly/pro/Bento4/Source/C++/Core/Ap4List.h:353:12
        #7 0x39d3b1 in AP4_ContainerAtom::InspectChildren(AP4_AtomInspector&) /home/lly/pro/Bento4/Source/C++/Core/Ap4ContainerAtom.cpp:220:16
        #8 0x37117e in AP4_Atom::Inspect(AP4_AtomInspector&) /home/lly/pro/Bento4/Source/C++/Core/Ap4Atom.cpp:263:5
        #9 0x359b43 in main /home/lly/pro/Bento4/Source/C++/Apps/Mp4Dump/Mp4Dump.cpp:350:15
        #10 0x7f899655d0b2 in __libc_start_main /build/glibc-eX1tMB/glibc-2.31/csu/../csu/libc-start.c:308:16
        #11 0x2a2b1d in _start (/home/lly/pro/Bento4/cmakebuild/mp4dump+0x2a2b1d)
    
    AddressSanitizer can not provide additional info.
    SUMMARY: AddressSanitizer: SEGV /home/lly/pro/Bento4/Source/C++/Core/Ap4Descriptor.h:124:21 in AP4_DescriptorListInspector::Action(AP4_Descriptor*) const
    ==633802==ABORTING
    
    

poc.zip

1 participant

Tag

#c++