The component tcpprep in Tcpreplay v4.4.1 was discovered to contain a heap-based buffer overflow in parse_mpls at common/get.c:150. NOTE: this is different from CVE-2022-27942.

You are opening a _bug report_ against the Tcpreplay project: we use  
GitHub Issues for tracking bug reports and feature requests.

If you have a question about how to use Tcpreplay, you are at the wrong  
site. You can ask a question on the tcpreplay-users mailing list  
or on Stack Overflow with \[tcpreplay\] tag.  
General help is available here.

If you have a build issue, consider downloading the latest release

Otherwise, to report a bug, please fill out the reproduction steps  
(below) and delete these introductory paragraphs. Thanks!

**Describe the bug**  
A clear and concise description of what the bug is.  
There is a heap-overflow bug in get.c:150. This bug is different from #719 that crashes in get.c:118.

**To Reproduce**  
Steps to reproduce the behavior:

1.  export CC=clang && export CFLAGS="-fsanitize=address -g"
2.  ./autogen.sh && ./configure --disable-shared --disable-local-libopts && make clean && make -j8
3.  ./src/tcpprep --auto=bridge --pcap=POC --cachefile=/dev/null

**Expected behavior**  
A clear and concise description of what you expected to happen.  
The program does not crash.

**Screenshots**  
If applicable, add screenshots to help explain your problem.  

**System (please complete the following information):**

*   OS: Debian
*   OS version: buster
*   Tcpreplay Version: 09f0774

**Additional context**  
Add any other context about the problem here.  
**POC**  
poc.zip

CVE-2022-37049: [Bug] heap-overflow in get.c:150 · Issue #736 · appneta/tcpreplay

An insufficient validation input flaw, one of 11 patched in an update this week, could allow for arbitrary code execution and is under active attack.

An insufficient validation input flaw, one of 11 patched in an update this week, could allow for arbitrary code execution and is under active attack.

Google has patched the fifth actively exploited zero-day vulnerability discovered in Chrome this year as one in a series of fixes included in a stable channel update released Wednesday.

The bug, tracked as CVE-2022-2856 and rated as high on the Common Vulnerability Scoring System (CVSS), is associated with “insufficient validation of untrusted input in Intents,” according to the advisory posted by Google.

Google credits Ashley Shen and Christian Resell of its Google Threat Analysis Group (TAG) for reporting the zero-day bug, which could allow for arbitrary code execution, on July 19. The advisory also unveiled 10 other patches for various other Chrome issues.

Intents are a deep linking feature on the Android device within the Chrome browser that replaced URI schemes, which previously handled this process, according to Branch, a company that offers various linking options for mobile applications.

“Instead of assigning window.location or an iframe.src to the URI scheme, in Chrome, developers need to use their intent string as defined in this document,” the company explained on its website. Intent “adds complexity” but “automatically handles the case of the mobile app not being installed” within links, according to the post.

Insufficient validation is associated with input validation, a frequently-used technique for checking potentially dangerous inputs to ensure that they are safe for processing within the code, or when communicating with other components, according to MITRE’s Common Weakness Enumeration site.

“When software does not validate input properly, an attacker is able to craft the input in a form that is not expected by the rest of the application,” according to a post on the site. “This will lead to parts of the system receiving unintended input, which may result in altered control flow, arbitrary control of a resource, or arbitrary code execution.”

**Fending Off Exploits**

As is typical, Google did not disclose specific details of the bug until it is widely patched to avoid threat actors taking further advantage of it, a strategy that one security professional noted is a wise one.

“Publicizing details on an actively exploited zero-day vulnerability just as a patch becomes available could have dire consequences, because it takes time to roll out security updates to vulnerable systems and attackers are champing at the bit to exploit these types of flaws,” observed Satnam Narang, senior staff research engineer at cybersecurity firm Tenable, in an email to Threatpost.

 Holding back info is also sound given that other Linux distributions and browsers, such as Microsoft Edge, also include code based on Google’s Chromium Project. These all could be affected if an exploit for a vulnerability is released, he said.

“It is extremely valuable for defenders to have that buffer,” Narang added.

While the majority of the fixes in the update are for vulnerabilities rated as high or medium risk, Google did patch a critical bug tracked as CVE-2022-2852, a use-after-free issue in FedCM reported by Sergei Glazunov of Google Project Zero on Aug. 8. FedCM—short for the Federated Credential Management API–provides a use-case-specific abstraction for federated identity flows on the web, according to Google.

**Fifth Chrome 0Day Patch So Far**

The zero-day patch is the fifth Chrome bug under active attack that Google has patched so far this year.

In July, the company fixed an actively exploited heap buffer overflow flaw tracked as CVE-2022-2294 in WebRTC, the engine that gives Chrome its real-time communications capability, while in May it was a separate buffer overflow flaw tracked as CVE-2022-2294 and under active attack that got slapped with a patch.

In April, Google patched CVE-2022-1364, a type confusion flaw affecting Chrome’s use of the V8 JavaScript engine on which attackers already had pounced. The previous month a separate type-confusion issue in V8 tracked as CVE-2022-1096 and under active attack also spurred a hasty patch.

February saw a fix for the first of this year’s Chrome zero-days, a use-after-free flaw in Chrome’s Animation component tracked as CVE-2022-0609 that already was under attack. Later it was revealed that North Korean hackers were exploiting the flaw weeks before it was discovered and patched.

Google Patches Chrome’s Fifth Zero-Day of the Year

Heap-based Buffer Overflow in GitHub repository vim/vim prior to 9.0.0219.

**Description**

Heap-based Buffer Overflow in function latin\_ptr2len at vim/src/mbyte.c:1088 .

**vim version**

    git log
    commit 249e1b903a9c0460d618f6dcc59aeb8c03b24b20 (grafted, HEAD -> master, tag: v9.0.0213, origin/master, origin/HEAD)
    

**Proof of Concept**

    ./vim -u NONE -X -Z -e -s -S poc4_hbo.dat -c :qa!
    =================================================================
    ==66771==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000006111 at pc 0x55ec6e7efd5e bp 0x7ffd8cb71450 sp 0x7ffd8cb71440
    READ of size 1 at 0x602000006111 thread T0
        #0 0x55ec6e7efd5d in latin_ptr2len /home/fuzz/vim/src/mbyte.c:1088
        #1 0x55ec6e6341e4 in next_for_item /home/fuzz/vim/src/eval.c:1852
        #2 0x55ec6e6f1e21 in ex_while /home/fuzz/vim/src/ex_eval.c:1304
        #3 0x55ec6e6c2443 in do_one_cmd /home/fuzz/vim/src/ex_docmd.c:2570
        #4 0x55ec6e6b96e6 in do_cmdline /home/fuzz/vim/src/ex_docmd.c:992
        #5 0x55ec6e9dc845 in do_source_ext /home/fuzz/vim/src/scriptfile.c:1674
        #6 0x55ec6e9dd977 in do_source /home/fuzz/vim/src/scriptfile.c:1801
        #7 0x55ec6e9da506 in cmd_source /home/fuzz/vim/src/scriptfile.c:1174
        #8 0x55ec6e9da56b in ex_source /home/fuzz/vim/src/scriptfile.c:1200
        #9 0x55ec6e6c2443 in do_one_cmd /home/fuzz/vim/src/ex_docmd.c:2570
        #10 0x55ec6e6b96e6 in do_cmdline /home/fuzz/vim/src/ex_docmd.c:992
        #11 0x55ec6e6b7a80 in do_cmdline_cmd /home/fuzz/vim/src/ex_docmd.c:586
        #12 0x55ec6ecb3eda in exe_commands /home/fuzz/vim/src/main.c:3133
        #13 0x55ec6ecad048 in vim_main2 /home/fuzz/vim/src/main.c:780
        #14 0x55ec6ecac900 in main /home/fuzz/vim/src/main.c:432
        #15 0x7fa0c810e082 in __libc_start_main ../csu/libc-start.c:308
        #16 0x55ec6e538e4d in _start (/home/fuzz/vim/src/vim+0x139e4d)
    
    0x602000006111 is located 0 bytes to the right of 1-byte region [0x602000006110,0x602000006111)
    allocated by thread T0 here:
        #0 0x7fa0c85a5808 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cc:144
        #1 0x55ec6e53928a in lalloc /home/fuzz/vim/src/alloc.c:246
        #2 0x55ec6e53907b in alloc /home/fuzz/vim/src/alloc.c:151
        #3 0x55ec6ea6f52d in vim_strsave /home/fuzz/vim/src/strings.c:27
        #4 0x55ec6e633a55 in eval_for_line /home/fuzz/vim/src/eval.c:1781
        #5 0x55ec6e6f1c4d in ex_while /home/fuzz/vim/src/ex_eval.c:1295
        #6 0x55ec6e6c2443 in do_one_cmd /home/fuzz/vim/src/ex_docmd.c:2570
        #7 0x55ec6e6b96e6 in do_cmdline /home/fuzz/vim/src/ex_docmd.c:992
        #8 0x55ec6e9dc845 in do_source_ext /home/fuzz/vim/src/scriptfile.c:1674
        #9 0x55ec6e9dd977 in do_source /home/fuzz/vim/src/scriptfile.c:1801
        #10 0x55ec6e9da506 in cmd_source /home/fuzz/vim/src/scriptfile.c:1174
        #11 0x55ec6e9da56b in ex_source /home/fuzz/vim/src/scriptfile.c:1200
        #12 0x55ec6e6c2443 in do_one_cmd /home/fuzz/vim/src/ex_docmd.c:2570
        #13 0x55ec6e6b96e6 in do_cmdline /home/fuzz/vim/src/ex_docmd.c:992
        #14 0x55ec6e6b7a80 in do_cmdline_cmd /home/fuzz/vim/src/ex_docmd.c:586
        #15 0x55ec6ecb3eda in exe_commands /home/fuzz/vim/src/main.c:3133
        #16 0x55ec6ecad048 in vim_main2 /home/fuzz/vim/src/main.c:780
        #17 0x55ec6ecac900 in main /home/fuzz/vim/src/main.c:432
        #18 0x7fa0c810e082 in __libc_start_main ../csu/libc-start.c:308
    
    SUMMARY: AddressSanitizer: heap-buffer-overflow /home/fuzz/vim/src/mbyte.c:1088 in latin_ptr2len
    Shadow bytes around the buggy address:
      0x0c047fff8bd0: fa fa 06 fa fa fa fd fa fa fa fd fa fa fa 07 fa
      0x0c047fff8be0: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa
      0x0c047fff8bf0: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa
      0x0c047fff8c00: fa fa fd fa fa fa 00 00 fa fa 00 00 fa fa 05 fa
      0x0c047fff8c10: fa fa 00 00 fa fa fd fa fa fa fd fd fa fa 07 fa
    =>0x0c047fff8c20: fa fa[01]fa fa fa fd fa fa fa 01 fa fa fa 06 fa
      0x0c047fff8c30: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c047fff8c40: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c047fff8c50: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c047fff8c60: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c047fff8c70: 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
      Shadow gap:              cc
    ==66771==ABORTING
    
    

<p><a href="https://github.com/Janette88/vim/blob/main/poc4\_hbo.dat">poc4\_hbo.dat</a></p>

**Impact**

This vulnerability is capable of crashing software, modify memory, and possible remote execution.

CVE-2022-2849: Heap-based Buffer Overflow in function latin_ptr2len in vim

Google on Tuesday rolled out patches for Chrome browser for desktops to contain an actively exploited high-severity zero-day flaw in the wild.
Tracked as CVE-2022-2856, the issue has been described as a case of insufficient validation of untrusted input in Intents. Security researchers Ashley Shen and Christian Resell of Google Threat Analysis Group have been credited with reporting the flaw on

Google on Tuesday rolled out patches for Chrome browser for desktops to contain an actively exploited high-severity zero-day flaw in the wild.

Tracked as **CVE-2022-2856**, the issue has been described as a case of insufficient validation of untrusted input in Intents. Security researchers Ashley Shen and Christian Resell of Google Threat Analysis Group have been credited with reporting the flaw on July 19, 2022.

As is typically the case, the tech giant has refrained from sharing additional specifics about the shortcoming until a majority of the users are updated. "Google is aware that an exploit for CVE-2022-2856 exists in the wild," it acknowledged in a terse statement.

The latest update also addressed 10 other security flaws, most of which relate to use-after-free bugs in various components such as FedCM, SwiftShader, ANGLE, and Blink, among others. Also fixed is a heap buffer overflow vulnerability in Downloads.

The development marks the fifth zero-day vulnerability in Chrome that Google has resolved since the start of the year -

*   **CVE-2022-0609** - Use-after-free in Animation
*   **CVE-2022-1096** - Type confusion in V8
*   **CVE-2022-1364** - Type confusion in V8
*   **CVE-2022-2294** - Heap buffer overflow in WebRTC

Users are recommended to update to version 104.0.5112.101 for macOS and Linux and 104.0.5112.102/101 for Windows to mitigate potential threats. Users of Chromium-based browsers such as Microsoft Edge, Brave, Opera, and Vivaldi are also advised to apply the fixes as and when they become available.

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

New Google Chrome Zero-Day Vulnerability Being Exploited in the Wild

Categories: Exploits and vulnerabilities
Categories: News
Tags: 104.0.5112.101

Tags:  Google

Tags:  Chrome

Tags:  CVE-2022-2852

Tags:  CVE-2022-2856

Tags:  CVE-2022-2854

Tags:  CVE-2022-2853

Tags:  UAF

Tags:  heap buffer overflow

Google issued an update that includes 11 security fixes. One of the vulnerabilities is labeled as “Critical” and one of the vulnerabilities that is labeled as “High” exists in the wild.



(Read more...)




The post Update Chrome now! Google issues patch for zero day spotted in the wild appeared first on Malwarebytes Labs.

Google updated the Stable channel for Chrome to 104.0.5112.101 for Mac and Linux and 104.0.5112.102/101 for Windows which will roll out over the coming days/weeks. Extended stable channel has been updated to 104.0.5112.101 for Mac and 104.0.5112.102 for Windows , which will roll out over the coming days/weeks.

This update includes 11 security fixes. One of the vulnerabilities is labeled as “Critical” and one of the vulnerabilities that is labeled as “High” exists in the wild.

**Vulnerabilities**

Publicly disclosed computer security flaws are listed in the Common Vulnerabilities and Exposures (CVE) database. Its goal is to make it easier to share data across separate vulnerability capabilities (tools, databases, and services). We discuss some of the CVE’s included in this update below.

CVE-2022-2852: a critical use after free vulnerability in FedCM. Use after free (UAF) vulnerabilities occur because of the incorrect use of dynamic memory during a program’s operation. If after freeing a memory location, a program does not clear the pointer to that memory, an attacker can use the error to manipulate the program. The Federated Credential Management API (FedCM) allows the browser to understand the context in which the relying party (for example a website) and the identity provider (a third party authentication service) exchange information.

CVE-2022-2856: Insufficient validation of untrusted input in Intents. Chrome intents are the deep linking replacement for URI schemes on the Android device within the Chrome browser. Google’s Threat Analysis Group submitted the vulnerability and technical details will not be released until everyone has had ample opportunity to update.

Google is aware that an exploit for CVE-2022-2856 exists in the wild. A remote attacker can trick the victim to open a specially crafted web page and execute arbitrary code on the target system.

CVE-2022-2854: a UAF vulnerability in SwiftShader. SwiftShader is a an open source library that provides a software 3D renderer. The attacker would have to trick the victim to visit a specially crafted website.

CVE-2022-2853: a heap buffer overflow in Downloads. A buffer overflow is a type of software vulnerability that exists when an area of memory within a software application reaches its address boundary and writes into an adjacent memory region. In software exploit code, two common areas that are targeted for overflows are the stack and the heap. The heap is the portion of memory where dynamically allocated memory resides.

**How to protect yourself**

The easiest way to update Chrome is to allow it to update automatically, which basically uses the same method as outlined below but does not require your attention. But you can end up lagging behind if you never close the browser or if something goes wrong—such as an extension stopping you from updating the browser.

So, it doesn’t hurt to check now and then. And now would be a good time, given the severity of the vulnerabilities in this batch. My preferred method is to have Chrome open the page _chrome://settings/help_ which you can also find by clicking Settings > About Chrome.

If there is an update available, Chrome will notify you and start downloading it. Then all you have to do is relaunch the browser in order for the update to complete.

After the update the version should be 104.0.5112.101 or later.

Stay safe, everyone!

Update Chrome now! Google issues patch for zero day spotted in the wild

XPDF commit ffaf11c was discovered to contain a heap-buffer overflow via DCTStream::readHuffSym(DCTHuffTable*) at /xpdf/Stream.cc.

Hi, in the lastest version of this code \[ ps: commit id ffaf11c\] I found something unusual.

**crash sample**

8id0\_heap-buffer-overflow\_in\_readHuffSym.zip

**command to reproduce**

./pdftops -q [crash sample] /dev/null

**crash detail**

    =================================================================
    ==108391==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x620000001782 at pc 0x000000759029 bp 0x7ffd51edc550 sp 0x7ffd51edc548
    READ of size 2 at 0x620000001782 thread T0
        #0 0x759028 in DCTStream::readHuffSym(DCTHuffTable*) /home/bupt/Desktop/xpdf/xpdf/Stream.cc:3119:16
        #1 0x7548ba in DCTStream::readDataUnit(DCTHuffTable*, DCTHuffTable*, int*, int*) /home/bupt/Desktop/xpdf/xpdf/Stream.cc:2624:17
        #2 0x751b27 in DCTStream::readMCURow() /home/bupt/Desktop/xpdf/xpdf/Stream.cc:2392:9
        #3 0x750d6e in DCTStream::getChar() /home/bupt/Desktop/xpdf/xpdf/Stream.cc:2316:12
        #4 0x6899e3 in Object::streamGetChar() /home/bupt/Desktop/xpdf/xpdf/./Object.h:288:20
        #5 0x6899e3 in Lexer::getChar() /home/bupt/Desktop/xpdf/xpdf/Lexer.cc:92:42
        #6 0x6899e3 in Lexer::getObj(Object*) /home/bupt/Desktop/xpdf/xpdf/Lexer.cc:124:14
        #7 0x6a8fc5 in Parser::Parser(XRef*, Lexer*, int) /home/bupt/Desktop/xpdf/xpdf/Parser.cc:33:10
        #8 0x581742 in Gfx::display(Object*, int) /home/bupt/Desktop/xpdf/xpdf/Gfx.cc:641:16
        #9 0x6a76a1 in Page::displaySlice(OutputDev*, double, double, int, int, int, int, int, int, int, int, int (*)(void*), void*) /home/bupt/Desktop/xpdf/xpdf/Page.cc:360:10
        #10 0x6d5f6e in PSOutputDev::checkPageSlice(Page*, double, double, int, int, int, int, int, int, int, int, int (*)(void*), void*) /home/bupt/Desktop/xpdf/xpdf/PSOutputDev.cc:3276:11
        #11 0x6a7172 in Page::displaySlice(OutputDev*, double, double, int, int, int, int, int, int, int, int, int (*)(void*), void*) /home/bupt/Desktop/xpdf/xpdf/Page.cc:328:13
        #12 0x6a6f81 in Page::display(OutputDev*, double, double, int, int, int, int, int (*)(void*), void*) /home/bupt/Desktop/xpdf/xpdf/Page.cc:308:3
        #13 0x6af9b4 in PDFDoc::displayPage(OutputDev*, int, double, double, int, int, int, int, int (*)(void*), void*) /home/bupt/Desktop/xpdf/xpdf/PDFDoc.cc:384:27
        #14 0x6af9b4 in PDFDoc::displayPages(OutputDev*, int, int, double, double, int, int, int, int, int (*)(void*), void*) /home/bupt/Desktop/xpdf/xpdf/PDFDoc.cc:397:5
        #15 0x796d81 in main /home/bupt/Desktop/xpdf/xpdf/pdftops.cc:342:10
        #16 0x7f3b180d3c86 in __libc_start_main /build/glibc-CVJwZb/glibc-2.27/csu/../csu/libc-start.c:310
        #17 0x41d5d9 in _start (/home/bupt/Desktop/xpdf/xpdf/pdftops+0x41d5d9)
    
    0x620000001782 is located 2314 bytes to the right of 3576-byte region [0x620000000080,0x620000000e78)
    allocated by thread T0 here:
        #0 0x4f5768 in operator new(unsigned long) /home/bupt/Desktop/tools/llvm-12.0.1/llvm/projects/compiler-rt/lib/asan/asan_new_delete.cpp:99
        #1 0x7259bc in Stream::makeFilter(char*, Stream*, Object*, int) /home/bupt/Desktop/xpdf/xpdf/Stream.cc:269:11
        #2 0x72459a in Stream::addFilters(Object*, int) /home/bupt/Desktop/xpdf/xpdf/Stream.cc:141:11
        #3 0x6ad41e in Parser::makeStream(Object*, unsigned char*, CryptAlgorithm, int, int, int, int) /home/bupt/Desktop/xpdf/xpdf/Parser.cc:214:14
        #4 0x6ab6f6 in Parser::getObj(Object*, int, unsigned char*, CryptAlgorithm, int, int, int, int) /home/bupt/Desktop/xpdf/xpdf/Parser.cc:101:18
        #5 0x781a3a in XRef::fetch(int, int, Object*, int) /home/bupt/Desktop/xpdf/xpdf/XRef.cc:1028:13
        #6 0x6a7611 in Page::displaySlice(OutputDev*, double, double, int, int, int, int, int, int, int, int, int (*)(void*), void*) /home/bupt/Desktop/xpdf/xpdf/Page.cc:357:12
        #7 0x6d5f6e in PSOutputDev::checkPageSlice(Page*, double, double, int, int, int, int, int, int, int, int, int (*)(void*), void*) /home/bupt/Desktop/xpdf/xpdf/PSOutputDev.cc:3276:11
    
    SUMMARY: AddressSanitizer: heap-buffer-overflow /home/bupt/Desktop/xpdf/xpdf/Stream.cc:3119:16 in DCTStream::readHuffSym(DCTHuffTable*)
    Shadow bytes around the buggy address:
      0x0c407fff82a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c407fff82b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c407fff82c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c407fff82d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c407fff82e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
    =>0x0c407fff82f0:[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c407fff8300: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c407fff8310: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c407fff8320: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c407fff8330: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c407fff8340: 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
      Shadow gap:              cc
    ==108391==ABORTING

CVE-2022-38229: heap-buffer-overflow_in_readHuffSym · Issue #3 · jhcloos/xpdf

XPDF commit ffaf11c was discovered to contain a heap-buffer overflow via DCTStream::lookChar() at /xpdf/Stream.cc.

Hi, in the lastest version of this code \[ ps: commit id ffaf11c\] I found something unusual.

**crash sample**

8id148\_heap\_buffer\_overflow\_in\_lookChar.zip

**command to reproduce**

./pdftops -q [crash sample] /dev/null

**crash detail**

    =================================================================
    ==115813==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x631000038800 at pc 0x000000754566 bp 0x7ffe27e56210 sp 0x7ffe27e56208
    READ of size 4 at 0x631000038800 thread T0
        #0 0x754565 in DCTStream::lookChar() /home/bupt/Desktop/xpdf/xpdf/Stream.cc:2331:12
        #1 0x68a82a in Object::streamLookChar() /home/bupt/Desktop/xpdf/xpdf/./Object.h:291:20
        #2 0x68a82a in Lexer::lookChar() /home/bupt/Desktop/xpdf/xpdf/Lexer.cc:108:17
        #3 0x68a82a in Lexer::getObj(Object*) /home/bupt/Desktop/xpdf/xpdf/Lexer.cc:458:17
        #4 0x6ab867 in Parser::getObj(Object*, int, unsigned char*, CryptAlgorithm, int, int, int, int) /home/bupt/Desktop/xpdf/xpdf/Parser.cc
        #5 0x6aa214 in Parser::getObj(Object*, int, unsigned char*, CryptAlgorithm, int, int, int, int) /home/bupt/Desktop/xpdf/xpdf/Parser.cc:69:21
        #6 0x582f60 in Gfx::go(int) /home/bupt/Desktop/xpdf/xpdf/Gfx.cc:757:13
        #7 0x581775 in Gfx::display(Object*, int) /home/bupt/Desktop/xpdf/xpdf/Gfx.cc:642:3
        #8 0x6a76a1 in Page::displaySlice(OutputDev*, double, double, int, int, int, int, int, int, int, int, int (*)(void*), void*) /home/bupt/Desktop/xpdf/xpdf/Page.cc:360:10
        #9 0x6d5f6e in PSOutputDev::checkPageSlice(Page*, double, double, int, int, int, int, int, int, int, int, int (*)(void*), void*) /home/bupt/Desktop/xpdf/xpdf/PSOutputDev.cc:3276:11
        #10 0x6a7172 in Page::displaySlice(OutputDev*, double, double, int, int, int, int, int, int, int, int, int (*)(void*), void*) /home/bupt/Desktop/xpdf/xpdf/Page.cc:328:13
        #11 0x6a6f81 in Page::display(OutputDev*, double, double, int, int, int, int, int (*)(void*), void*) /home/bupt/Desktop/xpdf/xpdf/Page.cc:308:3
        #12 0x6af9b4 in PDFDoc::displayPage(OutputDev*, int, double, double, int, int, int, int, int (*)(void*), void*) /home/bupt/Desktop/xpdf/xpdf/PDFDoc.cc:384:27
        #13 0x6af9b4 in PDFDoc::displayPages(OutputDev*, int, int, double, double, int, int, int, int, int (*)(void*), void*) /home/bupt/Desktop/xpdf/xpdf/PDFDoc.cc:397:5
        #14 0x796d81 in main /home/bupt/Desktop/xpdf/xpdf/pdftops.cc:342:10
        #15 0x7f3e6975dc86 in __libc_start_main /build/glibc-CVJwZb/glibc-2.27/csu/../csu/libc-start.c:310
        #16 0x41d5d9 in _start (/home/bupt/Desktop/xpdf/xpdf/pdftops+0x41d5d9)
    
    0x631000038800 is located 0 bytes to the right of 65536-byte region [0x631000028800,0x631000038800)
    allocated by thread T0 here:
        #0 0x4afba0 in malloc /home/bupt/Desktop/tools/llvm-12.0.1/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:145
        #1 0x7aa7fa in gmalloc /home/bupt/Desktop/xpdf/goo/gmem.cc:102:13
        #2 0x7aa7fa in gmallocn /home/bupt/Desktop/xpdf/goo/gmem.cc:168:10
    
    SUMMARY: AddressSanitizer: heap-buffer-overflow /home/bupt/Desktop/xpdf/xpdf/Stream.cc:2331:12 in DCTStream::lookChar()
    Shadow bytes around the buggy address:
      0x0c627ffff0b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c627ffff0c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c627ffff0d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c627ffff0e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c627ffff0f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    =>0x0c627ffff100:[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c627ffff110: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c627ffff120: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c627ffff130: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c627ffff140: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c627ffff150: 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
      Shadow gap:              cc
    ==115813==ABORTING

CVE-2022-38238: heap_buffer_overflow_in_lookChar · Issue #15 · jhcloos/xpdf

XPDF commit ffaf11c was discovered to contain a heap-buffer overflow via DCTStream::getChar() at /xpdf/Stream.cc.

Hi, in the lastest version of this code \[ ps: commit id ffaf11c\] I found something unusual.

**crash sample**

8id93\_heap\_buffer\_overflow\_in\_getChar.zip

**command to reproduce**

./pdftops -q [crash sample] /dev/null

**crash detail**

    =================================================================
    ==115941==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7f54608ff800 at pc 0x000000750e7c bp 0x7ffdad0d6050 sp 0x7ffdad0d6048
    READ of size 4 at 0x7f54608ff800 thread T0
        #0 0x750e7b in DCTStream::getChar() /home/bupt/Desktop/xpdf/xpdf/Stream.cc:2302:9
        #1 0x6899e3 in Object::streamGetChar() /home/bupt/Desktop/xpdf/xpdf/./Object.h:288:20
        #2 0x6899e3 in Lexer::getChar() /home/bupt/Desktop/xpdf/xpdf/Lexer.cc:92:42
        #3 0x6899e3 in Lexer::getObj(Object*) /home/bupt/Desktop/xpdf/xpdf/Lexer.cc:124:14
        #4 0x6ab867 in Parser::getObj(Object*, int, unsigned char*, CryptAlgorithm, int, int, int, int) /home/bupt/Desktop/xpdf/xpdf/Parser.cc
        #5 0x582f60 in Gfx::go(int) /home/bupt/Desktop/xpdf/xpdf/Gfx.cc:757:13
        #6 0x581775 in Gfx::display(Object*, int) /home/bupt/Desktop/xpdf/xpdf/Gfx.cc:642:3
        #7 0x6a76a1 in Page::displaySlice(OutputDev*, double, double, int, int, int, int, int, int, int, int, int (*)(void*), void*) /home/bupt/Desktop/xpdf/xpdf/Page.cc:360:10
        #8 0x6d5f6e in PSOutputDev::checkPageSlice(Page*, double, double, int, int, int, int, int, int, int, int, int (*)(void*), void*) /home/bupt/Desktop/xpdf/xpdf/PSOutputDev.cc:3276:11
        #9 0x6a7172 in Page::displaySlice(OutputDev*, double, double, int, int, int, int, int, int, int, int, int (*)(void*), void*) /home/bupt/Desktop/xpdf/xpdf/Page.cc:328:13
        #10 0x6a6f81 in Page::display(OutputDev*, double, double, int, int, int, int, int (*)(void*), void*) /home/bupt/Desktop/xpdf/xpdf/Page.cc:308:3
        #11 0x6af9b4 in PDFDoc::displayPage(OutputDev*, int, double, double, int, int, int, int, int (*)(void*), void*) /home/bupt/Desktop/xpdf/xpdf/PDFDoc.cc:384:27
        #12 0x6af9b4 in PDFDoc::displayPages(OutputDev*, int, int, double, double, int, int, int, int, int (*)(void*), void*) /home/bupt/Desktop/xpdf/xpdf/PDFDoc.cc:397:5
        #13 0x796d81 in main /home/bupt/Desktop/xpdf/xpdf/pdftops.cc:342:10
        #14 0x7f5463589c86 in __libc_start_main /build/glibc-CVJwZb/glibc-2.27/csu/../csu/libc-start.c:310
        #15 0x41d5d9 in _start (/home/bupt/Desktop/xpdf/xpdf/pdftops+0x41d5d9)
    
    0x7f54608ff800 is located 0 bytes to the right of 131072-byte region [0x7f54608df800,0x7f54608ff800)
    allocated by thread T0 here:
        #0 0x4afba0 in malloc /home/bupt/Desktop/tools/llvm-12.0.1/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:145
        #1 0x7aa7fa in gmalloc /home/bupt/Desktop/xpdf/goo/gmem.cc:102:13
        #2 0x7aa7fa in gmallocn /home/bupt/Desktop/xpdf/goo/gmem.cc:168:10
    
    SUMMARY: AddressSanitizer: heap-buffer-overflow /home/bupt/Desktop/xpdf/xpdf/Stream.cc:2302:9 in DCTStream::getChar()
    Shadow bytes around the buggy address:
      0x0feb0c117eb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0feb0c117ec0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0feb0c117ed0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0feb0c117ee0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0feb0c117ef0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    =>0x0feb0c117f00:[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0feb0c117f10: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0feb0c117f20: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0feb0c117f30: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0feb0c117f40: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0feb0c117f50: 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
      Shadow gap:              cc
    ==115941==ABORTING

CVE-2022-38231: heap_buffer_overflow_in_getChar · Issue #11 · jhcloos/xpdf

XPDF commit ffaf11c was discovered to contain a heap-buffer overflow via DCTStream::readScan() at /xpdf/Stream.cc.

Hi, in the lastest version of this code \[ ps: commit id ffaf11c\] I found something unusual.

**crash sample**

8id103\_heap\_buffer\_overflow\_in\_readScan.zip

**command to reproduce**

./pdftops -q [crash sample] /dev/null

**crash detail**

    =================================================================
    ==115797==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7fcb48dd5800 at pc 0x00000074635f bp 0x7ffcc31156f0 sp 0x7ffcc31156e8
    READ of size 4 at 0x7fcb48dd5800 thread T0
        #0 0x74635e in DCTStream::readScan() /home/bupt/Desktop/xpdf/xpdf/Stream.cc:2549:18
        #1 0x7401e0 in DCTStream::reset() /home/bupt/Desktop/xpdf/xpdf/Stream.cc:2257:7
        #2 0x68912e in Object::streamReset() /home/bupt/Desktop/xpdf/xpdf/./Object.h:282:13
        #3 0x68912e in Lexer::Lexer(XRef*, Object*) /home/bupt/Desktop/xpdf/xpdf/Lexer.cc:74:12
        #4 0x581714 in Gfx::display(Object*, int) /home/bupt/Desktop/xpdf/xpdf/Gfx.cc:641:33
        #5 0x6a76a1 in Page::displaySlice(OutputDev*, double, double, int, int, int, int, int, int, int, int, int (*)(void*), void*) /home/bupt/Desktop/xpdf/xpdf/Page.cc:360:10
        #6 0x6d5f6e in PSOutputDev::checkPageSlice(Page*, double, double, int, int, int, int, int, int, int, int, int (*)(void*), void*) /home/bupt/Desktop/xpdf/xpdf/PSOutputDev.cc:3276:11
        #7 0x6a7172 in Page::displaySlice(OutputDev*, double, double, int, int, int, int, int, int, int, int, int (*)(void*), void*) /home/bupt/Desktop/xpdf/xpdf/Page.cc:328:13
        #8 0x6a6f81 in Page::display(OutputDev*, double, double, int, int, int, int, int (*)(void*), void*) /home/bupt/Desktop/xpdf/xpdf/Page.cc:308:3
        #9 0x6af9b4 in PDFDoc::displayPage(OutputDev*, int, double, double, int, int, int, int, int (*)(void*), void*) /home/bupt/Desktop/xpdf/xpdf/PDFDoc.cc:384:27
        #10 0x6af9b4 in PDFDoc::displayPages(OutputDev*, int, int, double, double, int, int, int, int, int (*)(void*), void*) /home/bupt/Desktop/xpdf/xpdf/PDFDoc.cc:397:5
        #11 0x796d81 in main /home/bupt/Desktop/xpdf/xpdf/pdftops.cc:342:10
        #12 0x7fcb4b949c86 in __libc_start_main /build/glibc-CVJwZb/glibc-2.27/csu/../csu/libc-start.c:310
        #13 0x41d5d9 in _start (/home/bupt/Desktop/xpdf/xpdf/pdftops+0x41d5d9)
    
    0x7fcb48dd5800 is located 0 bytes to the right of 131072-byte region [0x7fcb48db5800,0x7fcb48dd5800)
    allocated by thread T0 here:
        #0 0x4afba0 in malloc /home/bupt/Desktop/tools/llvm-12.0.1/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:145
        #1 0x7aa7fa in gmalloc /home/bupt/Desktop/xpdf/goo/gmem.cc:102:13
        #2 0x7aa7fa in gmallocn /home/bupt/Desktop/xpdf/goo/gmem.cc:168:10
    
    SUMMARY: AddressSanitizer: heap-buffer-overflow /home/bupt/Desktop/xpdf/xpdf/Stream.cc:2549:18 in DCTStream::readScan()
    Shadow bytes around the buggy address:
      0x0ff9e91b2ab0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0ff9e91b2ac0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0ff9e91b2ad0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0ff9e91b2ae0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0ff9e91b2af0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    =>0x0ff9e91b2b00:[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0ff9e91b2b10: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0ff9e91b2b20: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0ff9e91b2b30: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0ff9e91b2b40: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0ff9e91b2b50: 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
      Shadow gap:              cc
    ==115797==ABORTING

CVE-2022-38237: heap_buffer_overflow_in_readScan · Issue #14 · jhcloos/xpdf

XPDF commit ffaf11c was discovered to contain a global-buffer overflow via Lexer::getObj(Object*) at /xpdf/Lexer.cc.

Hi, in the lastest version of this code \[ ps: commit id ffaf11c\] I found something unusual.

**crash sample**

8id65\_global\_buffer\_overflow\_in\_getObj.zip

**command to reproduce**

./pdftops -q [crash sample] /dev/null

**crash detail**

    ==115893==ERROR: AddressSanitizer: global-buffer-overflow on address 0x00000093aadc at pc 0x000000689c9a bp 0x7ffe79eed770 sp 0x7ffe79eed768
    READ of size 1 at 0x00000093aadc thread T0
        #0 0x689c99 in Lexer::getObj(Object*) /home/bupt/Desktop/xpdf/xpdf/Lexer.cc:132:16
        #1 0x6a8fc5 in Parser::Parser(XRef*, Lexer*, int) /home/bupt/Desktop/xpdf/xpdf/Parser.cc:33:10
        #2 0x581742 in Gfx::display(Object*, int) /home/bupt/Desktop/xpdf/xpdf/Gfx.cc:641:16
        #3 0x6a76a1 in Page::displaySlice(OutputDev*, double, double, int, int, int, int, int, int, int, int, int (*)(void*), void*) /home/bupt/Desktop/xpdf/xpdf/Page.cc:360:10
        #4 0x6d5f6e in PSOutputDev::checkPageSlice(Page*, double, double, int, int, int, int, int, int, int, int, int (*)(void*), void*) /home/bupt/Desktop/xpdf/xpdf/PSOutputDev.cc:3276:11
        #5 0x6a7172 in Page::displaySlice(OutputDev*, double, double, int, int, int, int, int, int, int, int, int (*)(void*), void*) /home/bupt/Desktop/xpdf/xpdf/Page.cc:328:13
        #6 0x6a6f81 in Page::display(OutputDev*, double, double, int, int, int, int, int (*)(void*), void*) /home/bupt/Desktop/xpdf/xpdf/Page.cc:308:3
        #7 0x6af9b4 in PDFDoc::displayPage(OutputDev*, int, double, double, int, int, int, int, int (*)(void*), void*) /home/bupt/Desktop/xpdf/xpdf/PDFDoc.cc:384:27
        #8 0x6af9b4 in PDFDoc::displayPages(OutputDev*, int, int, double, double, int, int, int, int, int (*)(void*), void*) /home/bupt/Desktop/xpdf/xpdf/PDFDoc.cc:397:5
        #9 0x796d81 in main /home/bupt/Desktop/xpdf/xpdf/pdftops.cc:342:10
        #10 0x7f2de419dc86 in __libc_start_main /build/glibc-CVJwZb/glibc-2.27/csu/../csu/libc-start.c:310
        #11 0x41d5d9 in _start (/home/bupt/Desktop/xpdf/xpdf/pdftops+0x41d5d9)
    
    0x00000093aadc is located 4 bytes to the left of global variable 'specialChars' defined in 'Lexer.cc:26:13' (0x93aae0) of size 256
    0x00000093aadc is located 55 bytes to the right of global variable '<string literal>' defined in 'Lexer.cc:471:52' (0x93aaa0) of size 5
      '<string literal>' is ascii string 'null'
    SUMMARY: AddressSanitizer: global-buffer-overflow /home/bupt/Desktop/xpdf/xpdf/Lexer.cc:132:16 in Lexer::getObj(Object*)
    Shadow bytes around the buggy address:
      0x00008011f500: f9 f9 f9 f9 00 00 04 f9 f9 f9 f9 f9 00 00 00 00
      0x00008011f510: 02 f9 f9 f9 f9 f9 f9 f9 00 00 00 f9 f9 f9 f9 f9
      0x00008011f520: 00 00 00 00 00 02 f9 f9 f9 f9 f9 f9 00 00 06 f9
      0x00008011f530: f9 f9 f9 f9 00 00 00 02 f9 f9 f9 f9 00 00 07 f9
      0x00008011f540: f9 f9 f9 f9 05 f9 f9 f9 f9 f9 f9 f9 06 f9 f9 f9
    =>0x00008011f550: f9 f9 f9 f9 05 f9 f9 f9 f9 f9 f9[f9]00 00 00 00
      0x00008011f560: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x00008011f570: 00 00 00 00 00 00 00 00 00 00 00 00 f9 f9 f9 f9
      0x00008011f580: f9 f9 f9 f9 00 00 00 00 00 00 00 00 00 00 00 00
      0x00008011f590: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x00008011f5a0: 00 00 00 00 00 00 06 f9 f9 f9 f9 f9 02 f9 f9 f9
    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
    ==115893==ABORTING

Tag

#buffer_overflow