A malicious MySQL server can request local file content from a client using ruby-mysql prior to version 2.10.0 without explicit authorization from the user. This issue was resolved in version 2.10.0 and later.

_Last updated at Tue, 28 Jun 2022 14:50:24 GMT_

The ruby-mysql Ruby gem prior to version 2.10.0 maintained by Tomita Masahiro is vulnerable to an instance of CWE-610: Externally Controlled Reference to a Resource in Another Sphere, wherein a malicious MySQL server can request local file content from a client without explicit authorization from the user. The initial CVSSv3 estimate for this issue is 6.5. Note that this issue does not affect the much more popular mysql2 gem. This issue was fixed in ruby-mysql 2.10.0 on October 23, 2021, and users of ruby-mysql are urged to update.

**Product description**

The ruby-mysql Ruby gem is an implementation of a MySQL client. While it is far less popular than the mysql2 gem, it serves a particular niche audience of users that desire a pure Ruby implementation of MySQL client functionality without linking to an external library (as mysql2 does).

**Credit**

This issue was reported to Rapid7 by Hans-Martin Münch of MOGWAI LABS GmbH, initially as a Metasploit issue, and is being disclosed in accordance with Rapid7's vulnerability disclosure policy after coordination with the upstream maintainer of this library, as well as JPCERT/CC and CERT/CC.

**Exploitation**

A malicious actor can read arbitrary files from a client that uses ruby-mysql to communicate to a rogue MySQL server and issue database queries. In these cases, the server has the option to create a database reply using the LOAD DATA LOCAL statement, which instructs the client to provide additional data from a local file readable by the client (and not a "local" file on the server). The easiest way to demonstrate this issue is to run an instance of Rogue-MySql-Server by Gifts and perform any database query using the vulnerable version of the mysql gem.

Note that this behavior is a defined and expected option for servers and is described in the documentation, quoted below:

> Because LOAD DATA LOCAL is an SQL statement, parsing occurs on the server side, and transfer of the file from the client host to the server host is initiated by the MySQL server, which tells the client the file named in the statement. In theory, a patched server could tell the client program to transfer a file of the server's choosing rather than the file named in the statement. Such a server could access any file on the client host to which the client user has read access. (A patched server could in fact reply with a file-transfer request to any statement, not just LOAD DATA LOCAL, so a more fundamental issue **is that clients should not connect to untrusted servers**.) \[emphasis added\]

So, the vulnerability is not so much a MySQL server or protocol issue, but a vulnerability in a client that does not at least provide an option to disable LOAD DATA LOCAL queries; this is the situation with version 2.9.14 and earlier versions of ruby-mysql.

There is also prior work on this type of issue, and interested readers should refer to Knownsec 404 Team's article describing the issue for a thorough understanding of the dangers of LOAD DATA LOCAL and untrusted MySQL servers.

**Impact**

As stated, this issue only affects Ruby-based MySQL clients that connect to malicious MySQL servers. The vast majority of clients already know who they're connecting to, and while an attacker could poison DNS records or otherwise intercede in network traffic to capture unwitting clients, such network shenanigans will be foiled by routine security controls like SSL certificates. The true risk is posed only to those people who connect to random and unknown MySQL servers in unfamiliar environments.

In other words, penetration testers and other opportunistic MySQL attackers are most at risk from this kind of vulnerability. CVE-2021-3779 fits squarely in the category of "hacking the hackers," where an aggressive honeypot is designed to lie in wait for wandering MySQL scanners and attackers and steal data local to those connecting clients.

This is the reason why Hans-Martin Münch of MOGWAI LABS GmbH first brought this to Rapid7's attention as an issue in Metasploit. While Metasploit users are indeed the most at risk to falling victim to an exploit for this vulnerability, the underlying issue was quickly identified as one in the shared open-source library code that Metasploit depends on for managing MySQL connections to remote servers. (One such example is the MySQL hashdump auxiliary module.)

Users who implement ruby-mysql should update their packaged gem with the latest version of ruby-mysql, as it has been fixed in version 2.10.0. The current version (as of this writing) is 3.0.0 and was released in November of 2021.

Users unable to update can patch around the issue by ensuring that CLIENT\_LOCAL\_FILES is disallowed by the client, similarly to how Metasploit Framework initially remediated this issue while waiting on a fix from the upstream maintainer.

**Disclosure timeline**

The astute reader will note a significant gap of several months between the fix release and this disclosure. This was a failure on my, Tod Beardsley's, part, since I was handling this issue.

For the record, there was no intention to bury this vulnerability — after all, we communicated it to the Tomita (the maintainer), RubyGems (who pointed us in the direction of Rubysec, thanks André), CERT/CC, and JPCERT/CC, so hopefully the intention to disclose in a timely manner was and is obvious.

But a confluence of family tragedies and home-office technical disasters conspired with the usual complications of a multi-stakeholder, multi-continent effort to coordinate disclosure in open-source library code.

I am also acutely aware of the irony of this delay in light of my recent post on silent patches, and I offer apologies for that delay. I am committed to being better with backups, both of the data and human varieties.

Note that all dates are local to the United States (some dates may differ in Japan and Germany depending on the time of day).

*   **August, 2021:** Issue discovered by Hans-Martin Münch of MOGWAI LABS GmbH.
*   **Thu, Sep 2, 2021:** Issue reported to Rapid7's security contact as a Metasploit issue, #9286.
*   **Tue, Sep 7, 2021:** Rapid7 validated the issue, reserved CVE-2021-3779, and contacted the vulnerable gem maintainer, Tomita Masahiro.
*   **Tue, Sep 8, 2021:** Metasploit Framework temporary remediation committed.
*   **Tue, Sep 8, 2021:** Notified CERT/CC and RubyGems for disclosure coordination, as the gem appeared to be abandoned by the maintainer given no updates in several years.
*   **Tue, Sep 9, 2021:** Notified JPCERT/CC through VINCE on CERT/CC's advice, as VU#541053.
*   **Thu, Sep 10, 2021:** JPCERT/CC acknowledged the issue and attempted to contact the gem maintainer.
*   **Mon, Oct 18, 2021:** Maintainer responded to JPCERT/CC, acknowledging the issue.
*   **Fri, Oct 22, 2021:** Fixed version 2.10.0 released, Rapid7 notified Hans-Martin of the fix.
*   **Wed, Feb 16, 2022:** CERT/CC asks for an update on the issue, Rapid7 communicates the fix to CERT/CC and JPCERT/CC.
*   **Tue, Jun 6, 2022:** CERT/CC asks for an update, Rapid7 commits to sharing disclosure documentation.
*   **Tue, Jun 14, 2022:** Rapid7 shares disclosure details with CERT/CC and Hans-Martin, and asks JPCERT/CC to communicate this document to Tomita.
*   **Tue, June 28, 2022:** This public disclosure

**NEVER MISS A BLOG**

Get the latest stories, expertise, and news about security today.

Subscribe

  

_**Additional reading:**_

*   _CVE-2022-31749: WatchGuard Authenticated Arbitrary File Read/Write (Fixed)_
*   _New Report Shows What Data Is Most at Risk to (and Prized by) Ransomware Attackers_
*   _CVE-2022-32230: Windows SMB Denial-of-Service Vulnerability (FIXED)_
*   _The Hidden Harm of Silent Patches_

CVE-2021-3779: CVE-2021-3779: Ruby-MySQL Gem Client File Read (FIXED)

AnyDesk version 7.0.9 suffers from an arbitrary file write vulnerability via a symlink attack.

    # Exploit Title: AnyDesk allow arbitrary file write by symbolic link attack lead to denial-of-service attack on local machine# Google Dork: [if applicable]# Date: 24/5/2022# Exploit Author: Erwin Chan# Vendor Homepage: https://anydesk.com/en# Software Link: https://anydesk.com/en# Version: 7.0.9# Tested on: Windows 11It was found that AnyDesk (version 7.0.9) was vulnerable to arbitrary filewrite by symbolic link attack leading to denial-of-service attack on localmachine. It was noted that two functions were affected.*Affected function A*When there was a remote connection come in, a directory under AppData ofcurrent user (without admin privilege) and a "ad.trace" file (i.e.,"C:\Users\<user>\AppData\Roaming\AnyDesk") will be created by "AnyDesk.exe"with "NT Authority\SYSTEM" privilege.*Affected function B*After a connection was made, local or remote user could use the chat room.The chat log was written to folder"C:\Users\<user>\AppData\Roaming\AnyDesk\chat\" by "AnyDesk.exe" with "NTAuthority\SYSTEM" privilege. Or the local user (without admin privilege)could change the location of the chat log to anywhere that he/she has"Modify" privilege.*Vulnerability Summary*Since the directories (i.e., "C:\Users\<user>\AppData\Roaming\AnyDesk\","C:\Users\<user>\AppData\Roaming\AnyDesk\chat\") were assigned with"Modify" privilege for current user, current user could modify the entiredirectory. With this setup, an unprivileged user is able to achievearbitrary file write by creating a symbolic link to a privileged location(e.g., C:\Windows\System32). As a result, a malicious user couldpotentially deny any service by overwriting the configuration or systemfile of applications such as Anti Virus solutions. It was noted that thefile content could be manipulated in affected function B such that a lowprivileged user could write an arbitrary file to an arbitrary location.*Affected function A: Exploit steps by local user (without admin privilege)*   1. Remove the directory "C:\Users\<user>\AppData\Roaming\AnyDesk"   2. Create symbolic link of "ad.trace" file to a privileged location   (e.g., C:\Windows\System32\test.file) (PoC binary could be found here:   https://github.com/googleprojectzero/symboliclink-testing-tools/blob/main/CreateSymlink/CreateSymlink_readme.txt   )   1. Connect to local machine (target machine) from a remote machine.   After the connection was initiated, the content of "ad.trace" file would be   written to target file (e.g., C:\Windows\System32\test.file)*Affected function B: Exploit steps by local user (without admin privilege)*   1. edit username of remote connector   1. Establish a AnyDesk connection from remote. Enter arbitrary text into   the chat box. Mark down the filename of chat log   1. Remove the directory "C:\Users\<user>\AppData\Roaming\AnyDesk\chat"   2. Create symbolic link of chat log file (e.g., 657584961.txt) to a   privileged location (e.g., C:\Windows\test.conf) (PoC binary could be found   here:   https://github.com/googleprojectzero/symboliclink-testing-tools/blob/main/CreateSymlink/CreateSymlink_readme.txt   )   1. Open the chat room and enter arbitrary content into it. After that,   the content of chat room would be written to target file (e.g.,   C:\Windows\test.conf)Please let me know if any detail need further. ThanksRegards,Erwin

AnyDesk 7.0.9 Arbitrary File Write / Denial Of Service

Ubuntu Security Notice 5495-1 - Harry Sintonen discovered that curl incorrectly handled certain cookies. An attacker could possibly use this issue to cause a denial of service. This issue only affected Ubuntu 21.10, and Ubuntu 22.04 LTS. Harry Sintonen discovered that curl incorrectly handled certain HTTP compressions. An attacker could possibly use this issue to cause a denial of service. Harry Sintonen incorrectly handled certain file permissions. An attacker could possibly use this issue to expose sensitive information. This issue only affected Ubuntu 21.10, and Ubuntu 22.04 LTS.

==========================================================================  
Ubuntu Security Notice USN-5495-1  
June 27, 2022

curl vulnerabilities  
==========================================================================

A security issue affects these releases of Ubuntu and its derivatives:

- Ubuntu 22.04 LTS  
- Ubuntu 21.10  
- Ubuntu 20.04 LTS  
- Ubuntu 18.04 LTS

Summary:

Several security issues were fixed in curl.

Software Description:  
- curl: HTTP, HTTPS, and FTP client and client libraries

Details:

Harry Sintonen discovered that curl incorrectly handled certain cookies.  
An attacker could possibly use this issue to cause a denial of service.  
This issue only affected Ubuntu 21.10, and Ubuntu 22.04 LTS. (CVE-2022-32205)

Harry Sintonen discovered that curl incorrectly handled certain HTTP compressions.  
An attacker could possibly use this issue to cause a denial of service.  
(CVE-2022-32206)

Harry Sintonen incorrectly handled certain file permissions.  
An attacker could possibly use this issue to expose sensitive information.  
This issue only affected Ubuntu 21.10, and Ubuntu 22.04 LTS. (CVE-2022-32207)

Harry Sintonen discovered that curl incorrectly handled certain FTP-KRB messages.  
An attacker could possibly use this to perform a machine-in-the-diddle attack.  
(CVE-2022-32208)

Update instructions:

The problem can be corrected by updating your system to the following  
package versions:

Ubuntu 22.04 LTS:  
  curl                            7.81.0-1ubuntu1.3  
  libcurl3-gnutls                 7.81.0-1ubuntu1.3  
  libcurl3-nss                    7.81.0-1ubuntu1.3  
  libcurl4                        7.81.0-1ubuntu1.3

Ubuntu 21.10:  
  curl                            7.74.0-1.3ubuntu2.3  
  libcurl3-gnutls                 7.74.0-1.3ubuntu2.3  
  libcurl3-nss                    7.74.0-1.3ubuntu2.3  
  libcurl4                        7.74.0-1.3ubuntu2.3

Ubuntu 20.04 LTS:  
  curl                            7.68.0-1ubuntu2.12  
  libcurl3-gnutls                 7.68.0-1ubuntu2.12  
  libcurl3-nss                    7.68.0-1ubuntu2.12  
  libcurl4                        7.68.0-1ubuntu2.12

Ubuntu 18.04 LTS:  
  curl                            7.58.0-2ubuntu3.19  
  libcurl3-gnutls                 7.58.0-2ubuntu3.19  
  libcurl3-nss                    7.58.0-2ubuntu3.19  
  libcurl4                        7.58.0-2ubuntu3.19

In general, a standard system update will make all the necessary changes.

References:  
  https://ubuntu.com/security/notices/USN-5495-1  
  CVE-2022-32205, CVE-2022-32206, CVE-2022-32207, CVE-2022-32208

Package Information:  
  https://launchpad.net/ubuntu/+source/curl/7.81.0-1ubuntu1.3  
  https://launchpad.net/ubuntu/+source/curl/7.74.0-1.3ubuntu2.3  
  https://launchpad.net/ubuntu/+source/curl/7.68.0-1ubuntu2.12  
  https://launchpad.net/ubuntu/+source/curl/7.58.0-2ubuntu3.19

Ubuntu Security Notice USN-5495-1

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

In GPAC MP4Box 1.1.0, there is a Null pointer reference in the function gf_filter_pid_get_packet function in src/filter_core/filter_pid.c:5394, as demonstrated by GPAC. This can cause a denial of service (DOS).

if you try:  
gpac -i test.nhml:reframe=1:index=1.0 inspect:deep  
you should see the content of your nhml file

Using either of the following

    gpac -i test.nhml:reframe=1:index=1.0 -o /dev/null
    gpac -i test.nhml nhmlr:reframe=1:gpac:index=1.0 -o /dev/null
    

simply forward fin (raw file) to /dev/null because no extension/format is provided on the output, hence the message. You can check this adding -graph to your command line.

If you use:

    gpac -i test.nhml:reframe=1:index=1.0 -o /dev/null:ext=mp4
    gpac -i test.nhml nhmlr:reframe=1:gpac:index=1.0 -o /dev/null:ext=mp4
    

then a mp4 muxer will be loaded.

Otherwise you will need to force fout to only use inputs from nhmlr using link directives (here, '@'):

    gpac -i test.nhml nhmlr:reframe=1 @ -o /dev/null:ext=mp4

CVE-2021-40944: Null pointer reference in GPAC at src/filter_core/filter_pid.c:5394 · Issue #1906 · 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

An issue was discovered in MediaWiki through 1.38.1. The lemma length of a Wikibase lexeme is currently capped at a thousand characters. Unfortunately, this length is not validated, allowing much larger lexemes to be created, which introduces various denial-of-service attack vectors within the Wikibase and WikibaseLexeme extensions. This is related to Special:NewLexeme and Special:NewProperty.

To use PolyGerrit, please enable JavaScript in your browser settings, and then refresh this page.

CVE-2022-34750

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

#dos