A vulnerability in EbmlTypeDispatcher::send in VideoLAN VLC media player 3.0.11 allows attackers to trigger a heap-based buffer overflow via a crafted .mkv file.

CVE-2020-26664

mwifiex_cmd_802_11_ad_hoc_start in drivers/net/wireless/marvell/mwifiex/join.c in the Linux kernel through 5.10.4 might allow remote attackers to execute arbitrary code via a long SSID value, aka CID-5c455c5ab332.

Message ID

20201206084801.26479-1-ruc\_zhangxiaohui@163.com (mailing list archive)

State

Accepted

Commit

5c455c5ab332773464d02ba17015acdca198f03d

Delegated to:

Kalle Valo

Headers

show

Series

\[1/1\] mwifiex: Fix possible buffer overflows in mwifiex\_cmd\_802\_11\_ad\_hoc\_start | expand

**Commit Message****Comments**

**Patch**

diff --git a/drivers/net/wireless/marvell/mwifiex/join.c b/drivers/net/wireless/marvell/mwifiex/join.c
index 5934f7147..173ccf79c 100644
\--- a/drivers/net/wireless/marvell/mwifiex/join.c
+++ b/drivers/net/wireless/marvell/mwifiex/join.c
@@ -877,6 +877,8 @@  mwifiex\_cmd\_802\_11\_ad\_hoc\_start(struct mwifiex\_private \*priv,
 
 	memset(adhoc\_start->ssid, 0, IEEE80211\_MAX\_SSID\_LEN);
 
+	if (req\_ssid->ssid\_len > IEEE80211\_MAX\_SSID\_LEN)
+		req\_ssid->ssid\_len = IEEE80211\_MAX\_SSID\_LEN;
 	memcpy(adhoc\_start->ssid, req\_ssid->ssid, req\_ssid->ssid\_len);
 
 	mwifiex\_dbg(adapter, INFO, "info: ADHOC\_S\_CMD: SSID = %s\\n",

CVE-2020-36158: [1/1] mwifiex: Fix possible buffer overflows in mwifiex_cmd_802_11_ad_hoc_start

A flaw exists in binutils in bfd/pef.c. An attacker who is able to submit a crafted PEF file to be parsed by objdump could cause a heap buffer overflow -> out-of-bounds read that could lead to an impact to application availability. This flaw affects binutils versions prior to 2.34.

'1911437?cve=title' is not a valid bug number nor an alias to a bug.

Please press **Back** and try again.

CVE-2020-35493: Invalid Bug ID

Buffer overflow in QUIC dissector in Wireshark 3.4.0 to 3.4.1 allows denial of service via packet injection or crafted capture file

Problems have been found with the following capture file:

https://www.wireshark.org/download/automated/captures/fuzz-2020-12-09-3589621.pcap

stderr:

    Input file: /home/wireshark/menagerie/menagerie/16072-rtcp_transport_cc.pcap
    
    Build host information:
    Linux build1 5.4.0-56-generic #62-Ubuntu SMP Mon Nov 23 19:20:19 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
    Distributor ID:	Ubuntu
    Description:	Ubuntu 20.04.1 LTS
    Release:	20.04
    Codename:	focal
    
    Buildbot information:
    BUILDBOT_REPOSITORY=git@gitlab.com:wireshark/wireshark.git
    BUILDBOT_WORKERNAME=clang-code-analysis
    BUILDBOT_URL=https://buildbot.wireshark.org/wireshark-master/
    BUILDBOT_BUILDNUMBER=5360
    BUILDBOT_BUILDERNAME=Clang Code Analysis
    BUILDBOT_GOT_REVISION=770746cca810f0979f4b8dc82e2b2f1150f98dcc
    
    Return value:  0
    
    Dissector bug:  0
    
    Valgrind error count:  0
    
    
    
    Latest (but not necessarily the problem) commit:
    770746cca8 epan: Fix format_text treament of Greek, Arabic, etc.
    
    
    Command and args: /home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/install.asan/bin/tshark  -nVxr
    =================================================================
    ==3789690==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fff2d57a755 at pc 0x5649451bcff6 bp 0x7fff2d57a690 sp 0x7fff2d579e38
    READ of size 73 at 0x7fff2d57a755 thread T0
        #0 0x5649451bcff5 in MemcmpInterceptorCommon(void*, int (*)(void const*, void const*, unsigned long), void const*, void const*, unsigned long) (/home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/install.asan/bin/tshark+0x71ff5)
        #1 0x5649451bd4ea in memcmp (/home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/install.asan/bin/tshark+0x724ea)
        #2 0x7f4a99e28ac6 in quic_connection_equal /home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/build/cmbuild/../epan/dissectors/packet-quic.c:794:39
        #3 0x7f4a99e22b30 in check_dcid_on_coalesced_packet /home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/build/cmbuild/../epan/dissectors/packet-quic.c:3260:12
        #4 0x7f4a99e20410 in dissect_quic /home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/build/cmbuild/../epan/dissectors/packet-quic.c:3333:14
        #5 0x7f4a9b9a4b21 in call_dissector_through_handle /home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/build/cmbuild/../epan/packet.c:720:9
        #6 0x7f4a9b999ad0 in call_dissector_work /home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/build/cmbuild/../epan/packet.c:813:9
        #7 0x7f4a9b9a13d0 in call_dissector_only /home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/build/cmbuild/../epan/packet.c:3233:8
        #8 0x7f4a9b9515e1 in try_conversation_call_dissector_helper /home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/build/cmbuild/../epan/conversation.c:1351:8
        #9 0x7f4a9b95104f in try_conversation_dissector /home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/build/cmbuild/../epan/conversation.c:1381:7
        #10 0x7f4a9a49bc47 in decode_udp_ports /home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/build/cmbuild/../epan/dissectors/packet-udp.c:652:7
        #11 0x7f4a9a4a4e9e in dissect /home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/build/cmbuild/../epan/dissectors/packet-udp.c:1261:5
        #12 0x7f4a9a49ef5d in dissect_udp /home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/build/cmbuild/../epan/dissectors/packet-udp.c:1267:3
        #13 0x7f4a9b9a4b21 in call_dissector_through_handle /home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/build/cmbuild/../epan/packet.c:720:9
        #14 0x7f4a9b999ad0 in call_dissector_work /home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/build/cmbuild/../epan/packet.c:813:9
        #15 0x7f4a9b9993e9 in dissector_try_uint_new /home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/build/cmbuild/../epan/packet.c:1413:8
        #16 0x7f4a995ff9bb in ip_try_dissect /home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/build/cmbuild/../epan/dissectors/packet-ip.c:1817:7
        #17 0x7f4a99605089 in dissect_ip_v4 /home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/build/cmbuild/../epan/dissectors/packet-ip.c:2299:10
        #18 0x7f4a9b9a4b21 in call_dissector_through_handle /home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/build/cmbuild/../epan/packet.c:720:9
        #19 0x7f4a9b999ad0 in call_dissector_work /home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/build/cmbuild/../epan/packet.c:813:9
        #20 0x7f4a9b9993e9 in dissector_try_uint_new /home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/build/cmbuild/../epan/packet.c:1413:8
        #21 0x7f4a9b999ebb in dissector_try_uint /home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/build/cmbuild/../epan/packet.c:1437:9
        #22 0x7f4a991c1bfe in dissect_ethertype /home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/build/cmbuild/../epan/dissectors/packet-ethertype.c:292:21
        #23 0x7f4a9b9a4b21 in call_dissector_through_handle /home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/build/cmbuild/../epan/packet.c:720:9
        #24 0x7f4a9b999ad0 in call_dissector_work /home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/build/cmbuild/../epan/packet.c:813:9
        #25 0x7f4a9b9a13d0 in call_dissector_only /home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/build/cmbuild/../epan/packet.c:3233:8
        #26 0x7f4a9b995b04 in call_dissector_with_data /home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/build/cmbuild/../epan/packet.c:3246:8
        #27 0x7f4a991be72b in dissect_eth_common /home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/build/cmbuild/../epan/dissectors/packet-eth.c:568:5
        #28 0x7f4a991bd197 in dissect_eth /home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/build/cmbuild/../epan/dissectors/packet-eth.c:861:5
        #29 0x7f4a9b9a4b21 in call_dissector_through_handle /home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/build/cmbuild/../epan/packet.c:720:9
        #30 0x7f4a9b999ad0 in call_dissector_work /home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/build/cmbuild/../epan/packet.c:813:9
        #31 0x7f4a9b9a13d0 in call_dissector_only /home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/build/cmbuild/../epan/packet.c:3233:8
        #32 0x7f4a9924ea42 in dissect_frame /home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/build/cmbuild/../epan/dissectors/packet-frame.c:788:6
        #33 0x7f4a9b9a4b21 in call_dissector_through_handle /home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/build/cmbuild/../epan/packet.c:720:9
        #34 0x7f4a9b999ad0 in call_dissector_work /home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/build/cmbuild/../epan/packet.c:813:9
        #35 0x7f4a9b9a13d0 in call_dissector_only /home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/build/cmbuild/../epan/packet.c:3233:8
        #36 0x7f4a9b995b04 in call_dissector_with_data /home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/build/cmbuild/../epan/packet.c:3246:8
        #37 0x7f4a9b9952f9 in dissect_record /home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/build/cmbuild/../epan/packet.c:594:3
        #38 0x7f4a9b965118 in epan_dissect_run_with_taps /home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/build/cmbuild/../epan/epan.c:598:2
        #39 0x56494528215b in process_packet_single_pass /home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/build/cmbuild/../tshark.c:3806:5
        #40 0x564945285ab6 in process_cap_file_single_pass /home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/build/cmbuild/../tshark.c:3460:9
        #41 0x56494527f490 in process_cap_file /home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/build/cmbuild/../tshark.c:3616:26
        #42 0x5649452791c0 in main /home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/build/cmbuild/../tshark.c:2057:16
        #43 0x7f4a8eb750b2 in __libc_start_main /build/glibc-ZN95T4/glibc-2.31/csu/../csu/libc-start.c:308:16
        #44 0x5649451a641d in _start (/home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/install.asan/bin/tshark+0x5b41d)
    
    Address 0x7fff2d57a755 is located in stack of thread T0 at offset 53 in frame
        #0 0x7f4a99e224df in check_dcid_on_coalesced_packet /home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/build/cmbuild/../epan/dissectors/packet-quic.c:3226
    
      This frame has 1 object(s):
        [32, 53) 'dcid' (line 3229) <== Memory access at offset 53 overflows 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 (/home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/install.asan/bin/tshark+0x71ff5) in MemcmpInterceptorCommon(void*, int (*)(void const*, void const*, unsigned long), void const*, void const*, unsigned long)
    Shadow bytes around the buggy address:
      0x100065aa7490: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x100065aa74a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x100065aa74b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x100065aa74c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x100065aa74d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    =>0x100065aa74e0: 00 00 00 00 f1 f1 f1 f1 00 00[05]f3 f3 f3 f3 f3
      0x100065aa74f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x100065aa7500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x100065aa7510: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00 05 f2
      0x100065aa7520: f2 f2 f2 f2 00 00 05 f2 f2 f2 f2 f2 f8 f2 f8 f2
      0x100065aa7530: f8 f8 f8 f2 f2 f2 f2 f2 f8 f8 f8 f2 f2 f2 f2 f2
    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
    ==3789690==ABORTING

_no debug trace_

CVE-2020-26422: Buildbot crash output: fuzz-2020-12-09-3589621.pcap (#17073) · Issues · Wireshark Foundation / wireshark · GitLab

There are multiple unauthenticated directory traversal vulnerabilities in different FTP commands in uftpd FTP server versions 2.7 to 2.10 due to improper implementation of a chroot jail in common.c's compose_abspath function that can be abused to read or write to arbitrary files on the filesystem, leak process memory, or potentially lead to remote code execution.

Aaron's Blog

uftpd - Buffer Overflow and Directory Traversal Writeup

This post is a very informal writeup about multiple vulnerabilities in uftpd FTP server, some of which could lead to remote code execution.

**Introduction**

I've been wanting to find a binary exploitation-related vulnerability in something that isn't a Capture The Flag challenge for a very long time. I know that I am not nearly as experienced as many people are, so in the past when I've searched, I would quickly begin to doubt that I would find anything and lose motivation.

On August 28, 2019, I sat down, picked an FTP server written in C to target, and told myself that I wouldn't stop and I wouldn't go to sleep until I found something (spoiler: I got to sleep that night).

*   The section titled "Discovery Process" explains how I found the vulnerabilities and a bit about their root causes.
*   If you want a tl;dr of the vulnerabilities I found, skip to the section titled "Summary of Vulnerabilities".

**Discovery Process**

In this section I will walk through my thought process as I was discovering these vulnerabilities. I am writing this so that in the future I can look back and read about my first binary exploitation related vulnerability that I found outside of CTF. I'm sure I'll be glad I did it in a few years. :)

I chose the FTP server uftpd because I understand the FTP protocol very well, it is a plaintext protocol (mostly/usually/sometimes), and it involves a lot of string parsing. So, it seems prone to off-by-one (which could lead to a buffer overflow) or heap corruption-related vulnerabilities.

I wrote a fuzzer and ran it the entire time I was testing, but clearly I did not do a good job of writing it, because the fuzzer did not cause a single crash the entire time.

I started out by looking for uses of inherently vulnerable functions that should absolutely never be used. And wow. How stupid am I? It's modern software compiled with a modern compiler. No gets anywhere.

Then, I began looking for uses of functions that could be used insecurely that involve string manipulation (e.g. strcat / strncat, strcpy / strncpy, etc). Plenty of uses, but all were safe. No dice. I also carefully looked at uses of malloc and free.

Keep in mind, at this point, I was only looking for obvious buffer overflows, use-after-frees, off-by-ones, and format string injection vulnerabilities. After a few dead ends I followed and several hours wasted, I really wished I hadn't committed myself to finding something.

**Buffer Overflow Vulnerability**

For some reason I thought about what a friend had told me at Defcon about how Go is basically bulletproof as far as SQL injection goes. He told me about some awful code he had seen where the author had basically gone out of the way to make a program vulnerable by constructing the query with sprintf instead of the built-in parameterized library's functions. That made me think to re-check all uses of ^[a-z]*printf$ in the code.

I eventually came upon the handle_PORT function in ftpcmd.c:

The buffer size is INET_ADDRSTRLEN? What's that?

A quick search shows that it's the value 16 (the maximum length of an IPv4 address in ###.###.###.### format).

Hold up. That sprintf line is using the %d format specifier which takes a signed integer. The string representation of a signed integer is not at most 4 bytes like an (octet + '.' char) is, and it isn't checking the value of each octet to ensure that they are each between 0 and 255 inclusive.

Sick! A buffer overflow vulnerability!

Crap, a stack canary. Right, this isn't a CTF challenge.

I tried to find a way to leak memory, but other than leaking memory into logs (which maybe you could consider a vulnerability?), I couldn't get anywhere. So an attacker would have to either find a way to leak the stack canary that I couldn't or would have to brute force the canary.

Also, there's another restriction: the address must be constructed out of the characters [0-9\-] because of the %d specifier. Considering I can't bypass the stack canary, I haven't bothered looking into this.

Had the FTP server had written the address and port back to the user without updating it first anywhere in the code, I would've been able to leak memory by crafting a PORT command with not enough integers to satisfy the format.

And even if somehow I leaked memory and somehow I got lucky with ASLR and the addresses were all ASCII numeric, it wouldn't be possible to exploit unless uftpd was compiled without stack canaries since I cannot write a null byte.

To reproduce this, try sending this in:

    USER anonymous
    PASS hi
    PORT 13371337,13371337,13371337,13371337,1,1
    

**Multiple Directory Traversal Vulnerabilities (Chroot Bypass)**

Sigh. So that was fun finding that buffer overflow vuln. It is 12am by this point and I could go to sleep now, but why sleep when at peak performance?

I saw this function at the top of common.c.

The compose_abspath function that protects against directory traversal attacks was far too long for me to bother reading (that's not its full source code in the above screenshot). So, just to confirm to myself that it wasn't vulnerable, I pulled up my favorite FTP client, netcat:

Oh my... is it really...

Here is the source code of compose_abspath:

The vulnerability is in the function it calls, compose_path:

Then I tested most of the file I/O FTP commands and every command I tested was vulnerable (as they all use the same chroot jailing function compose_abspath).

That's right. Arbitrary file write/read anywhere on the operating system that I have access to. It should be easy to get remote code execution from this if you write a backdoor to a webserver root with CGI enabled. I wrote a proof of concept to automate that.

To reproduce this, all you have to do is, after setting up a listener with nc -lvp 1258, send in:

    USER anonymous
    PASS hi
    PORT 127,0,0,1,1,1002
    RETR ../../../etc/passwd
    

But wait—it gets even better.

Think you need authentication to exploit any of these so far? Think again! You don't even need to login as the anonymous user to exploit either of those.

This vulnerability is not exploitable if the FTP server is running as root; when running as root, it uses the "real" chroot instead of the custom (vulnerable) chroot implementation.

This bug was introduced in commit ce1c9234c78eb3b939f465bcb40c19cd5141eab7 and fixed in commit 455b47d3756aed162d2d0ef7f40b549f3b5b30fe.

**Summary of Vulnerabilities****Unauthenticated Buffer Overflow Vulnerability in handle_PORT in ftpcmd.c**

*   **Product:** uftpd <=2.10
*   **CVE:** CVE-2020-5204

An unauthenticated stack-based buffer overflow vulnerability in common.c's handle_PORT in uftpd FTP server versions 2.10 and earlier can be abused to cause a crash and could potentially lead to remote code execution.

**Exploits**

There currently are no plans to develop an exploit. Please contact me if you are developing / have developed one.

**Reproduction Steps**

Connect to the FTP server and send:

    PORT 13371337,13371337,13371337,13371337,1,1
    

**Multiple Unauthenticated Directory Traversal Vulnerabilities**

*   **Product:** uftpd 2.6-2.10
*   **CVE:** CVE-2020-5221

There are multiple unauthenticated directory traversal vulnerabilities in different FTP commands in uftpd FTP server versions 2.7 to 2.10 due to improper implementation of a chroot jail in common.c's compose_abspath function that can be abused to read or write to arbitrary files on the filesystem, leak process memory, or potentially lead to remote code execution.

**Exploits**

*   **Metasploit:** Download here. Module is in development and does not currently function.
*   **Python:** Download here. Demonstration below.

**Reproduction Steps**

Setup a TCP listener on port 1258, connect to the FTP server, and send:

    PORT 127,0,0,1,1,1002
    RETR ../../../etc/passwd
    

**Disclosure**

The project maintainer Joachim (troglobit) replied and fixed all of the vulnerabilities within 4 hours of my initial contact. Very impressive!

**Timeline**

    August 28, 2019: Discovered the vulnerabilities
    August 29, 2019: Wrote this writeup
    August 30, 2019: Created a proof of concept and wrote the report
    August 31, 2019: Emailed a report to troglobit
    August 31, 2019: Vulnerabilities fixed
    

**References**

*   Commit that fixes the buffer overflow vulnerability: https://github.com/troglobit/uftpd/commit/0fb2c031ce0ace07cc19cd2cb2143c4b5a63c9dd
*   Commit that fixes the directory traversal regression: https://github.com/troglobit/uftpd/commit/455b47d3756aed162d2d0ef7f40b549f3b5b30fe

**Footnotes:** Thank you to pwnpnw and Robert Chen for getting me interested in binary exploitation and for helping me learn.

CVE-2020-20277: Aaron Esau (arinerron)

There's a flaw in jasper's jpc encoder in versions prior to 2.0.23. Crafted input provided to jasper by an attacker could cause an arbitrary out-of-bounds write. This could potentially affect data confidentiality, integrity, or application availability.

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

Closed

zodf0055980 opened this issue

Nov 30, 2020

· 8 comments

**Comments**

I found a heap buffer overflow in the current master (9975856).  
I build jasper with ASAN, this is an ASAN report.  
POC picture : sample.zip

    ➜  appl git:(master) ✗ ./jasper --input ./sample.pgx --output ./out --output-format jpc -O numrlvls=40
    =================================================================
    ==12383==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x617000000350 at pc 0x7fba3fab9db8 bp 0x7ffc56cf7fa0 sp 0x7ffc56cf7f90
    WRITE of size 8 at 0x617000000350 thread T0
        #0 0x7fba3fab9db7 in cp_create /home/yuan/afl-target/jasper/src/libjasper/jpc/jpc_enc.c:629
        #1 0x7fba3fab9db7 in jpc_encode /home/yuan/afl-target/jasper/src/libjasper/jpc/jpc_enc.c:287
        #2 0x5571432fbe8a in main /home/yuan/afl-target/jasper/src/appl/jasper.c:276
        #3 0x7fba3f5f0bf6 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21bf6)
        #4 0x5571432fd339 in _start (/home/yuan/afl-target/jasper/build/src/appl/jasper+0x5339)
    
    0x617000000350 is located 0 bytes to the right of 720-byte region [0x617000000080,0x617000000350)
    allocated by thread T0 here:
        #0 0x7fba3fe71b40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40)
        #1 0x7fba3fa2e5f2 in jas_malloc /home/yuan/afl-target/jasper/src/libjasper/base/jas_malloc.c:238
    
    SUMMARY: AddressSanitizer: heap-buffer-overflow /home/yuan/afl-target/jasper/src/libjasper/jpc/jpc_enc.c:629 in cp_create
    Shadow bytes around the buggy address:
      0x0c2e7fff8010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c2e7fff8020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c2e7fff8030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c2e7fff8040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c2e7fff8050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    =>0x0c2e7fff8060: 00 00 00 00 00 00 00 00 00 00[fa]fa fa fa fa fa
      0x0c2e7fff8070: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c2e7fff8080: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c2e7fff8090: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c2e7fff80a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c2e7fff80b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
    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
    ==12383==ABORTING
    

I also try to prove it without ASAN.  
It malloc 720 bytes in jas\_malloc.c:238.  
When -O numrlvls=x  > 36  
It tries to write tccp->prcheightexpns[35] and causes heap-buffer-overflow-write.

I saw that you did some PRs for openjpeg. Do you plan to create one for this issue too?

This is an easy bug. I can try to fix it.

Fixed in #253 . I add the upper bound check.  
Could I try to submit this problem to get CVE ID?

> Could I try to submit this problem to get CVE ID?

Yes.

@zodf0055980 thank you for your PR! Next time please use 'Fixes #252' in the commit body.

Closing this since the PR got merged. Please mention the CVE here in case you will get one, ok?

@jubalh OK. I am sorry I forget it.  
If I get a CVE id, I will report here.  
Thanks a lot.

shipujin pushed a commit to shipujin/slackware-loongarch64 that referenced this issue

Jul 8, 2022

a/elogind-243.7-x86\_64-2.txz:  Rebuilt.
  Moved default udev rules to /lib/udev/rules.d/. Thanks to Robby Workman.
  Added /usr/share/polkit-1/rules.d/10-enable-session-power.rules.
a/glibc-zoneinfo-2020d-noarch-2.txz:  Rebuilt.
  Make /etc/localtime a symlink pointing into /usr/share/zoneinfo. If you
  have /usr on a separate partition, this might cause time problems prior
  to /usr being mounted (I recommend \*not\* making /usr a separate partition).
  But if you insist for some reason, you can probably work around it by
  adding the pointed-to directory and timezone file to your empty pre-mounted
  /usr directory.
a/upower-0.99.11-x86\_64-2.txz:  Rebuilt.
  Added /usr/share/polkit-1/rules.d/10-enable-upower-suspend.rules.
d/autoconf-2.70-noarch-1.txz:  Upgraded.
d/gnucobol-3.1.1-x86\_64-1.txz:  Upgraded.
kde/powerdevil-5.20.4-x86\_64-2.txz:  Rebuilt.
  Moved 10-enable-powerdevil-discrete-gpu.rules.new to
  /usr/share/polkit-1/rules.d/. Thanks to Robby Workman.
  Moved 10-enable-session-power.rules to the elogind package.
  Moved 10-enable-upower-suspend.rules to the upower package.
  Thanks to GazL.
l/jasper-2.0.23-x86\_64-1.txz:  Upgraded.
  Fix heap-overflow in cp\_create() in jpc\_enc.c.
  For more information, see:
    jasper-software/jasper#252
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-27828
  (\* Security fix \*)
l/sbc-1.5-x86\_64-1.txz:  Upgraded.
n/curl-7.74.0-x86\_64-1.txz:  Upgraded.
  This release includes the following security related bugfixes:
  Inferior OCSP verification \[93\]
  FTP wildcard stack overflow \[95\]
  Trusting FTP PASV responses \[97\]
  For more information, see:
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-8286
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-8285
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-8284
  (\* Security fix \*)
xap/xscreensaver-5.45-x86\_64-1.txz:  Upgraded.
xfce/Greybird-3.22.13-noarch-1.txz:  Upgraded.

2 participants

CVE-2020-27828: Heap-buffer-overflow in libjasper/jpc/jpc_enc.c:629 · Issue #252 · jasper-software/jasper

A heap-based buffer overflow vulnerability exists in Academy Software Foundation OpenEXR 2.3.0 in chunkOffsetReconstruction in ImfMultiPartInputFile.cpp that can cause a denial of service via a crafted EXR file.

Browse files

Fix #491, issue with part number range check reconstructing chunk off…

…set table

The chunk offset was incorrectly testing for a part number that was the
same size (i.e. an invalid index)

Signed-off-by: Kimball Thurston <kdt3rd@gmail.com>

*   Loading branch information

kdt3rd committed

Jul 25, 2019

1 parent d5800c1 commit 8b5370c688a7362673c3a5256d93695617a4cd9a

CVE-2020-16587: Fix #491, issue with part number range check reconstructing chunk off… · AcademySoftwareFoundation/openexr@8b5370c

A head-based buffer overflow exists in Academy Software Foundation OpenEXR 2.3.0 in writeTileData in ImfTiledOutputFile.cpp that can cause a denial of service via a crafted EXR file.

@@ -1313,6 +1313,13 @@ TiledInputFile::rawTileData (int &dx, int &dy,

throw IEX\_NAMESPACE::ArgExc ("rawTileData read the wrong tile");

}

}

else

{

if(!isValidTile (dx, dy, lx, ly) )

{

throw IEX\_NAMESPACE::IoExc ("rawTileData read an invalid tile");

}

}

pixelData = tileBuffer->buffer;

}

catch (IEX\_NAMESPACE::BaseExc &e)

CVE-2020-16589: Fix for #494: validate tile coordinates when doing copyPixels · AcademySoftwareFoundation/openexr@6bb3671

A buffer overflow in the web server of Flexense DupScout Enterprise 10.0.18 allows a remote anonymous attacker to execute code as SYSTEM by overflowing the sid parameter via a GET /settings&sid= attack.

DupScout News

**14-Aug-2022** - DupScout v14.4 improves the duplicate files search options dialog and improves the duplicate files filters and categories allowing one to search specific types of duplicate files using one or more user-specified file matching rules. In addition, the new product version improves the duplicate files search results dialog, improves the main DupScout GUI application and fixes a number of bugs.

**12-May-2022** - DupScout v14.3 adds the ability to search duplicate files by the creation week day, modification week day or last access **week day**. In addition, the new product version improves the performance of the duplicate files search operations, improves the DupScout Server product version, improves the file properties dialog and fixes a number of bugs.

**4-Apr-2022** - DupScout v14.2 adds the history of previously connected **network drives** and provides the ability to reconnect any network drive in a single mouse click. In addition, the new product version improves the CSV and text duplicate files search reports, improves the support for Unicode file names and fixes a number of bugs.

CVE-2020-29659: DupScout - Duplicate Files Finder

A spoofing issue existed in the handling of URLs. This issue was addressed with improved input validation. This issue is fixed in macOS Big Sur 11.0.1, Safari 14.0.1. Visiting a malicious website may lead to address bar spoofing.

Tag

#buffer_overflow