Gentoo Linux Security Advisory 202208-4 - Multiple vulnerabilities in libmcpp could result in a denial of service condition. Versions less than 2.7.2_p5 are affected.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -  
Gentoo Linux Security Advisory                           GLSA 202208-04  
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -  
                                           https://security.gentoo.org/  
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

 Severity: Low  
    Title: libmcpp: Denial of service  
     Date: August 04, 2022  
     Bugs: #718808  
       ID: 202208-04

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Synopsis  
=======  
Multiple vulnerabilities in libmcpp could result in a denial of service  
condition.

Background  
=========  
libmcpp is a portable C/C++ preprocessor.

Affected packages  
================  
    -------------------------------------------------------------------  
     Package              /     Vulnerable     /            Unaffected  
    -------------------------------------------------------------------  
  1  dev-cpp/libmcpp            < 2.7.2_p5                >= 2.7.2_p5

Description  
==========  
A buffer overflow and an out-of-bounds read vulnerability have been  
discovered in libmcpp, which could be exploited for denial of service.

Impact  
=====  
An attacker that can provide crafted input to libmcpp could achieve denial of service.

Workaround  
=========  
There is no known workaround at this time.

Resolution  
=========  
All libmcpp users should upgrade to the latest version:

  # emerge --sync  
  # emerge --ask --oneshot --verbose ">Þv-cpp/libmcpp-2.7.2_p5"

References  
=========  
[ 1 ] CVE-2019-14274  
      https://nvd.nist.gov/vuln/detail/CVE-2019-14274

Availability  
===========  
This GLSA and any updates to it are available for viewing at  
the Gentoo Security Website:

 https://security.gentoo.org/glsa/202208-04

Concerns?  
========  
Security is a primary focus of Gentoo Linux and ensuring the  
confidentiality and security of our users' machines is of utmost  
importance to us. Any security concerns should be addressed to  
security@gentoo.org or alternatively, you may file a bug at  
https://bugs.gentoo.org.

License  
======  
Copyright 2022 Gentoo Foundation, Inc; referenced text  
belongs to its owner(s).

The contents of this document are licensed under the  
Creative Commons - Attribution / Share Alike license.

https://creativecommons.org/licenses/by-sa/2.5

Gentoo Linux Security Advisory 202208-04

A stack overflow was discovered in the _TIFFVGetField function of Tiffsplit v4.4.0. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted TIFF file.

**Summary**

A stack overflow occurs when tiffsplit processes a craft file.

**Version**

LIBTIFF, Version 4.4.0, master b2d61984

**Steps to reproduce**

Download the poc file from here and run cmd $ tiffsplit $POC

**Platform**

Ubuntu 16.04.3 LTS, x86\_64, Clang-12

**ASAN report**

    $ ./bin_asan/bin/tiffsplit ./poc-tiffsplit-b2d61984-_TIFFVGetField-stackoverflow
    TIFFReadDirectoryCheckOrder: Warning, Invalid TIFF directory; tags are not sorted in ascending order.
    TIFFReadDirectory: Warning, Unknown field with tag 317 (0x13d) encountered.
    TIFFReadDirectory: Warning, Unknown field with tag 34893 (0x884d) encountered.
    TIFFReadDirectory: Warning, Unknown field with tag 31350 (0x7a76) encountered.
    TIFFReadDirectory: Warning, Unknown field with tag 59310 (0xe7ae) encountered.
    TIFFReadDirectory: Warning, Unknown field with tag 520 (0x208) encountered.
    TIFFFetchNormalTag: Warning, IO error during reading of "DocumentName"; tag ignored.
    TIFFFetchNormalTag: Warning, Incorrect count for "PhotometricInterpretation"; tag ignored.
    ./poc-tiffsplit-b2d61984-_TIFFVGetField-stackoverflow: ZSTD compression support is not configured.
    =================================================================
    ==21665==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffcf0f98d50 at pc 0x0000004ddb2d bp 0x7ffcf0f98a90 sp 0x7ffcf0f98a88
    WRITE of size 4 at 0x7ffcf0f98d50 thread T0
        #0 0x4ddb2c in _TIFFVGetField /opt/disk/marsman/libtiff/b2d61984/build_asan/libtiff/../../code/libtiff/tif_dir.c:1164:31
        #1 0x4cd95e in TIFFVGetField /opt/disk/marsman/libtiff/b2d61984/build_asan/libtiff/../../code/libtiff/tif_dir.c:1302:6
        #2 0x4cd95e in TIFFGetField /opt/disk/marsman/libtiff/b2d61984/build_asan/libtiff/../../code/libtiff/tif_dir.c:1286:11
        #3 0x4c9c58 in tiffcp /opt/disk/marsman/libtiff/b2d61984/build_asan/tools/../../code/tools/tiffsplit.c:260:2
        #4 0x4c9c58 in main /opt/disk/marsman/libtiff/b2d61984/build_asan/tools/../../code/tools/tiffsplit.c:160:8
        #5 0x7f221a17f83f in __libc_start_main /build/glibc-S7Ft5T/glibc-2.23/csu/../csu/libc-start.c:291
        #6 0x41ce88 in _start (/opt/disk/marsman/libtiff/b2d61984/bin_asan/bin/tiffsplit+0x41ce88)
    
    Address 0x7ffcf0f98d50 is located in stack of thread T0 at offset 144 in frame
        #0 0x4c8fbf in main /opt/disk/marsman/libtiff/b2d61984/build_asan/tools/../../code/tools/tiffsplit.c:97
    
      This frame has 18 object(s):
        [32, 40) 'bytecounts.i371.i' (line 316)
        [64, 72) 'bytecounts.i.i' (line 354)
        [96, 98) 'bitspersample.i' (line 237)
        [112, 114) 'samplesperpixel.i' (line 237)
        [128, 130) 'compression.i' (line 237)
        [144, 146) 'shortv.i' (line 237) <== Memory access at offset 144 partially overflows this variable
        [160, 168) 'shortav.i' (line 237)
        [192, 196) 'w.i' (line 238)
        [208, 212) 'l.i' (line 238)
        [224, 228) 'floatv.i' (line 239)
        [240, 248) 'stringv.i' (line 240)
        [272, 276) 'longv.i' (line 241)
        [288, 292) 'count.i' (line 252)
        [304, 312) 'table.i' (line 253)
        [336, 344) 'red.i' (line 280)
        [368, 376) 'green.i' (line 280)
        [400, 408) 'blue.i' (line 280)
        [432, 434) 'shortv2.i' (line 284)
    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 /opt/disk/marsman/libtiff/b2d61984/build_asan/libtiff/../../code/libtiff/tif_dir.c:1164:31 in _TIFFVGetField
    Shadow bytes around the buggy address:
      0x10001e1eb150: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x10001e1eb160: 00 00 00 00 f1 f1 f1 f1 00 00 00 f3 f3 f3 f3 f3
      0x10001e1eb170: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x10001e1eb180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x10001e1eb190: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 f8 f2 f2 f2
    =>0x10001e1eb1a0: f8 f2 f2 f2 02 f2 02 f2 02 f2[02]f2 00 f2 f2 f2
      0x10001e1eb1b0: 04 f2 04 f2 04 f2 00 f2 f2 f2 04 f2 f8 f2 f8 f2
      0x10001e1eb1c0: f2 f2 f8 f2 f2 f2 f8 f2 f2 f2 f8 f2 f2 f2 f8 f3
      0x10001e1eb1d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x10001e1eb1e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x10001e1eb1f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    Shadow byte legend (one shadow byte represents 8 application bytes):
      Addressable:           00
      Partially addressable: 01 02 03 04 05 06 07 
      Heap left redzone:       fa
      Freed heap region:       fd
      Stack left redzone:      f1
      Stack mid redzone:       f2
      Stack right redzone:     f3
      Stack after return:      f5
      Stack use after scope:   f8
      Global redzone:          f9
      Global init order:       f6
      Poisoned by user:        f7
      Container overflow:      fc
      Array cookie:            ac
      Intra object redzone:    bb
      ASan internal:           fe
      Left alloca redzone:     ca
      Right alloca redzone:    cb
      Shadow gap:              cc
    ==21665==ABORTING

**GDB report**

    Starting program: /opt/disk/marsman/libtiff/b2d61984/bin_normal/bin/tiffsplit ./poc-tiffsplit-b2d61984-_TIFFVGetField-stackoverflow 
    [Thread debugging using libthread_db enabled]
    Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
    TIFFReadDirectoryCheckOrder: Warning, Invalid TIFF directory; tags are not sorted in ascending order.
    TIFFReadDirectory: Warning, Unknown field with tag 317 (0x13d) encountered.
    TIFFReadDirectory: Warning, Unknown field with tag 34893 (0x884d) encountered.
    TIFFReadDirectory: Warning, Unknown field with tag 31350 (0x7a76) encountered.
    TIFFReadDirectory: Warning, Unknown field with tag 59310 (0xe7ae) encountered.
    TIFFReadDirectory: Warning, Unknown field with tag 520 (0x208) encountered.
    TIFFFetchNormalTag: Warning, IO error during reading of "DocumentName"; tag ignored.
    TIFFFetchNormalTag: Warning, Incorrect count for "PhotometricInterpretation"; tag ignored.
    ./poc-tiffsplit-b2d61984-_TIFFVGetField-stackoverflow: ZSTD compression support is not configured.
    
    Program received signal SIGSEGV, Segmentation fault.
    _TIFFVGetField (tif=<optimized out>, tag=<optimized out>, ap=0x7fffffffdaa0) at ../../code/libtiff/tif_dir.c:1167
    1167                                                    *va_arg(ap, const void **) = tv->value;
    (gdb) bt
    #0  _TIFFVGetField (tif=<optimized out>, tag=<optimized out>, ap=0x7fffffffdaa0) at ../../code/libtiff/tif_dir.c:1167
    #1  0x0000000000407dc4 in TIFFGetField (tif=tif@entry=0x671010, tag=tag@entry=317) at ../../code/libtiff/tif_dir.c:1286
    #2  0x0000000000402f76 in tiffcp (out=0x6722e0, in=0x671010) at ../../code/tools/tiffsplit.c:260
    #3  main (argc=<optimized out>, argv=<optimized out>) at ../../code/tools/tiffsplit.c:160

CVE-2022-34526: tiffsplit: stack-buffer-overflow in _TIFFVGetField() (#433) · Issues · libtiff / libtiff · GitLab

sqclass.cpp in Squirrel through 2.2.5 and 3.x through 3.1 allows an out-of-bounds read (in the core interpreter) that can lead to Code Execution. If a victim executes an attacker-controlled squirrel script, it is possible for the attacker to break out of the squirrel script sandbox even if all dangerous functionality such as File System functions has been disabled. An attacker might abuse this bug to target (for example) Cloud services that allow customization via SquirrelScripts, or distribute malware through video games that embed a Squirrel Engine.

  Overview

Squirrel is a high level imperative, object-oriented programming language, designed to be a light-weight scripting language that fits in the size, memory bandwidth, and real-time requirements of applications like video games. Although Squirrel offers a wide range of features like:

*   Open Source MIT licence
*   dynamic typing
*   delegation
*   classes & inheritance
*   higher order functions
*   lexical scoping
*   generators
*   cooperative threads(coroutines) 
*   tail recursion
*   exception handling
*   automatic memory management (CPU bursts free; mixed approach ref counting/GC)
*   both compiler and virtual machine fit together in about 7k lines of C++ code and add only around 100kb-150kb the executable size.
*   optional 16bits characters strings
*   powerful embedding api
    
    *   eg. function/classes can be defined by scripts or in C
    *   eg. objects can fully exist in the VM or be bound to native code
    *   eg. classes created in C can be extended by scripts or vice-versa
    *   and more
    
    Squirrel is inspired by languages like Python,Javascript and especially Lua(The API is very similar and the table code is based on the Lua one)
    
      
    
    What Does it look like?  
    squirrel's syntax is similar to C/C++/Java etc... but the language has a very dynamic nature like Python/Lua etc...
    
    local table = {
    	a = "10"
    	subtable = {
    		array = \[1,2,3\]
    	},
    	\[10 + 123\] = "expression index"
    }
     
    local array=\[ 1, 2, 3, { a = 10, b = "string" } \];
     
    foreach (i,val in array)
    {
    	::print("the type of val is"+typeof val);
    }
     
    /////////////////////////////////////////////
     
    class Entity
    {	
    	constructor(etype,entityname)
    	{
    		name = entityname;
    		type = etype;
    	}
    									
    	x = 0;
    	y = 0;
    	z = 0;
    	name = null;
    	type = null;
    }
     
    function Entity::MoveTo(newx,newy,newz)
    {
    	x = newx;
    	y = newy;
    	z = newz;
    }
     
    class Player extends Entity {
    	constructor(entityname)
    	{
    		base.constructor("Player",entityname)
    	}
    	function DoDomething()
    	{
    		::print("something");
    	}
    	
    }
     
    local newplayer = Player("da playar");
     
    newplayer.MoveTo(100,200,300);			
    
      
    Development state  
    
    The current stable release is 3.2  
    The project has been compiled and run on Windows(x86 & x64), Linux(x86 & x64), Illumos(x86 & x64), Mac OS X, FreeBSD, iOS and Android.  
    Has been tested with the following compilers:
    
    > MS Visual C++ 6.0,7.0,7.1,8.0,9.0 and 10.0(x86 & x64)  
    > MinGW gcc 3.2 (mingw special 20020817-1)  
    > Cygwin gcc 3.2  
    > Linux gcc 3.x  
    > Linux gcc 4.x  
    > Illumos gcc 4.x  
    > XCode 4  
    
    The documentation has to be improved.  
    
    I'd like to have some feed back and maybe help to design/port/test it.
    
      
    Work in Progress
    
    In the next release(3.2.x stable):
    
    *   more compact bytecode
    *   performance tuning
    *   additional documentation
    
      
    Documentation  
    **Squirrel 3.2**
    
    Online Squirrel 3.2 reference manual and Standard Libraries manual)
    
    Offline Squirrel 3.2 Reference Manual (PDF)  
    Offline Squirrel 3.2 Standard Libraries Manual (PDF)
    
    both manuals are included in the language distribution
    
      
    **Squirrel 3.0.x**
    
    Squirrel 3.0 reference manual(PDF/HtmlHelp/Html Online)
    
    Squirrel 3.0 Standard Libraries manual(PDF/HtmlHelp/Html Online)
    
    both manuals are included in the language distribution
    
      
    **Squirrel 2.x**
    
    Squirrel 2.0 reference manual(PDF/HtmlHelp/Html Online)
    
    Squirrel 2.0 Standard Libraries manual(PDF/HtmlHelp/Html Online)
    
    both manuals are included in the language distribution
    
      
    Download  
    **stable release**
    
    You can download Squirrel 3.2 stable here  
    _Released February 10, 2022._
    
    **GitHub Repository**
    
    Squirrel's GitHub repository is here
    
    **older 3.x release**
    
    You can download Squirrel 3.0.7 stable here  
    _Released January 10, 2015._
    
    **older 2.x stable release**
    
    You can download Squirrel 2.2.5 stable here  
    _Released November 28, 2011._
    
    My name is Alberto Demichelis if you want to know more about me, this is my personal homepage

CVE-2021-41556: Squirrel - The Programming Language

Rizin v0.4.0 and below was discovered to contain an integer overflow via the function get_long_object(). This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted binary.

**Crash**

In Rizin of the current version, an integer overflow is found in get\_long\_object(). It further leads to a heap buffer overflow. The attacker can launch the DoS attack with a malformed binary.

**Work environment**

Questions

Answers

OS/arch/bits (mandatory)

Linux 5.18.6-arch1-1

File format of the file you reverse (mandatory)

malformed

Architecture/bits of the file (mandatory)

malformed

rizin -v full output, **not truncated** (mandatory)

rizin 0.5.0 @ linux-x86-64 commit: 74e499a, build: 2022-06-25\_\_09:14:00

**Expected behavior**

run normally

**Actual behavior**

crash

**Steps to reproduce the behavior**

Open the attached file (after unzip) with Rizin.

**Additional Logs, screenshots, source code, configuration dump, ...**

input.zip

ERROR: Undefined type in free\_object (0)
ERROR: Undefined type in get\_object (0x0)
ERROR: Undefined type in get\_object (0x0)
ERROR: Undefined type in get\_object (0x14)
ERROR: Undefined type in get\_object (0x0)
ERROR: Undefined type in get\_object (0x2)
ERROR: Undefined type in get\_object (0x0)
ERROR: Undefined type in get\_object (0x0)
ERROR: Undefined type in get\_object (0x40)
ERROR: Undefined type in get\_object (0x0)
ERROR: Undefined type in get\_object (0x0)
ERROR: Undefined type in get\_object (0x40)
ERROR: Undefined type in get\_object (0x0)
ERROR: Undefined type in get\_object (0x0)
ERROR: Copy not implemented for type 7b
../librz/bin/format/pyc/marshal.c:202:18: runtime error: signed integer overflow: 1162871039 \* 15 cannot be represented in type 'int'
=================================================================
==2965413==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7fa62f4647ff at pc 0x7fa63e73190d bp 0x7fffe4547ef0 sp 0x7fffe4547ee0
WRITE of size 1 at 0x7fa62f4647ff thread T0
    #0 0x7fa63e73190c in get\_long\_object ../librz/bin/format/pyc/marshal.c:219
    #1 0x7fa63e73190c in get\_object ../librz/bin/format/pyc/marshal.c:1099
    #2 0x7fa63e7332e5 in get\_code\_object ../librz/bin/format/pyc/marshal.c:948
    #3 0x7fa63e7305a3 in get\_object ../librz/bin/format/pyc/marshal.c:1054
    #4 0x7fa63e7342a6 in get\_sections\_symbols\_from\_code\_objects ../librz/bin/format/pyc/marshal.c:1204
    #5 0x7fa63e439e26 in symbols ../librz/bin/p/bin\_pyc.c:126
    #6 0x7fa63e30551b in rz\_bin\_object\_set\_items ../librz/bin/bobj.c:419
    #7 0x7fa63e30a21d in rz\_bin\_object\_new ../librz/bin/bobj.c:282
    #8 0x7fa63e2e5ca4 in rz\_bin\_file\_new\_from\_buffer ../librz/bin/bfile.c:277
    #9 0x7fa63e2f2675 in rz\_bin\_open\_buf ../librz/bin/bin.c:283
    #10 0x7fa63e2f3f72 in rz\_bin\_open\_io ../librz/bin/bin.c:341
    #11 0x7fa63c5fe1a3 in core\_file\_do\_load\_for\_io\_plugin ../librz/core/cfile.c:727
    #12 0x7fa63c5fe1a3 in rz\_core\_bin\_load ../librz/core/cfile.c:974
    #13 0x7fa645326b1d in rz\_main\_rizin ../librz/main/rizin.c:1147
    #14 0x7fa64482928f  (/usr/lib/libc.so.6+0x2928f)
    #15 0x7fa644829349 in \_\_libc\_start\_main (/usr/lib/libc.so.6+0x29349)
    #16 0x55c82ec2f964 in \_start (/usr/local/bin/rizin+0x2964)

0x7fa62f4647ff is located 1 bytes to the left of 65799105-byte region \[0x7fa62f464800,0x7fa633324bc1)
allocated by thread T0 here:
    #0 0x7fa6460bfa89 in \_\_interceptor\_malloc /usr/src/debug/gcc/libsanitizer/asan/asan\_malloc\_linux.cpp:69
    #1 0x7fa63e72e907 in get\_long\_object ../librz/bin/format/pyc/marshal.c:205
    #2 0x7fa63e72e907 in get\_object ../librz/bin/format/pyc/marshal.c:1099
    #3 0x7fa63e7332e5 in get\_code\_object ../librz/bin/format/pyc/marshal.c:948
    #4 0x7fa63e7305a3 in get\_object ../librz/bin/format/pyc/marshal.c:1054
    #5 0x7fa63e7342a6 in get\_sections\_symbols\_from\_code\_objects ../librz/bin/format/pyc/marshal.c:1204
    #6 0x7fa63e439e26 in symbols ../librz/bin/p/bin\_pyc.c:126
    #7 0x7fa63e30551b in rz\_bin\_object\_set\_items ../librz/bin/bobj.c:419
    #8 0x7fa63e30a21d in rz\_bin\_object\_new ../librz/bin/bobj.c:282
    #9 0x7fa63e2e5ca4 in rz\_bin\_file\_new\_from\_buffer ../librz/bin/bfile.c:277
    #10 0x7fa63e2f2675 in rz\_bin\_open\_buf ../librz/bin/bin.c:283
    #11 0x7fa63e2f3f72 in rz\_bin\_open\_io ../librz/bin/bin.c:341
    #12 0x7fa63c5fe1a3 in core\_file\_do\_load\_for\_io\_plugin ../librz/core/cfile.c:727
    #13 0x7fa63c5fe1a3 in rz\_core\_bin\_load ../librz/core/cfile.c:974
    #14 0x7fa645326b1d in rz\_main\_rizin ../librz/main/rizin.c:1147
    #15 0x7fa64482928f  (/usr/lib/libc.so.6+0x2928f)

SUMMARY: AddressSanitizer: heap-buffer-overflow ../librz/bin/format/pyc/marshal.c:219 in get\_long\_object
Shadow bytes around the buggy address:
  0x0ff545e848a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0ff545e848b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0ff545e848c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0ff545e848d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0ff545e848e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=>0x0ff545e848f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa\[fa\]
  0x0ff545e84900: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ff545e84910: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ff545e84920: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ff545e84930: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ff545e84940: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==2965413==ABORTING

CVE-2022-34612: An integer overflow is found in get_long_object() · Issue #2738 · rizinorg/rizin

An issue was discovered in mjs(mJS: Restricted JavaScript engine), ES6 (JavaScript version 6). There is stack buffer overflow at 0x7fffe9049390.

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

Clingto opened this issue

May 19, 2021

· 0 comments

**Comments**

System info:  
Ubuntu 16.04.6 LTS, X64, gcc 5.4.0, mjs (latest master 4c870e5)  
Compile Command:

    $ gcc -fsanitize=address -fno-omit-frame-pointer -DMJS_MAIN mjs.c -ldl -g -o mjs
    

Run Command:

POC file:  
https://github.com/Clingto/POC/blob/master/MSA/mjs/mjs-module-stack-overflow

ASAN info:

ASAN:SIGSEGV
=================================================================
==10560\==ERROR: AddressSanitizer: stack-overflow on address 0x7fffe9049390 (pc 0x7fffe9049390 bp 0x00000042572b sp 0x7fffe9049348 T0)
    #0 0x7fffe904938f  (<unknown module>)

SUMMARY: AddressSanitizer: stack-overflow ??:0 ??
==10560\==ABORTING

1 participant

CVE-2021-33448: AddressSanitizer: stack-buffer-overflow in <unknown module> · Issue #170 · cesanta/mjs

An issue was discovered in mjs (mJS: Restricted JavaScript engine), ES6 (JavaScript version 6). There are memory leaks in frozen_cb() in mjs.c.

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

Clingto opened this issue

May 19, 2021

· 0 comments

**Comments**

System info:  
Ubuntu 16.04.6 LTS, X64, gcc 5.4.0, mjs (latest master 4c870e5)  
Compile Command:

    $ gcc -fsanitize=address -fno-omit-frame-pointer -DMJS_MAIN mjs.c -ldl -g -o mjs
    

Run Command:

POC file:  
https://github.com/Clingto/POC/blob/master/MSA/mjs/mjs-5794-frozen\_cb-memory-leak

ASAN info:

\==29407\==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 37331 byte(s) in 1 object(s) allocated from:
    #0 0x7f151fe52602 in malloc (/usr/lib/x86\_64-linux-gnu/libasan.so.2+0x98602)
    #1 0x42ffcd in frozen\_cb  test/mjs-uaf/build\_asan/mjs.c:12025
    #2 0x4092c4 in json\_parse\_string  test/mjs-uaf/build\_asan/mjs.c:5898
    #3 0x40b482 in json\_parse\_value  test/mjs-uaf/build\_asan/mjs.c:5993
    #4 0x40aa25 in json\_parse\_array  test/mjs-uaf/build\_asan/mjs.c:5958
    #5 0x40b4c4 in json\_parse\_value  test/mjs-uaf/build\_asan/mjs.c:6000
    #6 0x40b863 in json\_parse\_pair  test/mjs-uaf/build\_asan/mjs.c:6058
    #7 0x40bc63 in json\_parse\_object  test/mjs-uaf/build\_asan/mjs.c:6070
    #8 0x40b4a3 in json\_parse\_value  test/mjs-uaf/build\_asan/mjs.c:5996
    #9 0x40c135 in json\_doit  test/mjs-uaf/build\_asan/mjs.c:6083
    #10 0x40f2aa in json\_walk  test/mjs-uaf/build\_asan/mjs.c:6466
    #11 0x4309d9 in mjs\_json\_parse  test/mjs-uaf/build\_asan/mjs.c:12133
    #12 0x430f11 in mjs\_op\_json\_parse  test/mjs-uaf/build\_asan/mjs.c:12193
    #13 0x42572a in mjs\_execute  test/mjs-uaf/build\_asan/mjs.c:9648
    #14 0x4265f1 in mjs\_exec\_internal  test/mjs-uaf/build\_asan/mjs.c:9866
    #15 0x426873 in mjs\_exec\_file  test/mjs-uaf/build\_asan/mjs.c:9889
    #16 0x431348 in main  test/mjs-uaf/build\_asan/mjs.c:12228
    #17 0x7f151f80c82f in \_\_libc\_start\_main (/lib/x86\_64-linux-gnu/libc.so.6+0x2082f)

SUMMARY: AddressSanitizer: 37331 byte(s) leaked in 1 allocation(s).

1 participant

CVE-2021-33437: AddressSanitizer: 1 memory leaks of frozen_cb() · Issue #160 · cesanta/mjs

As many as 207 websites have been infected with malicious code designed to launch a cryptocurrency miner by leveraging WebAssembly (Wasm) on the browser.
Web security company Sucuri, which published details of the campaign, said it launched an investigation after one of its clients had their computer slowed down significantly every time upon navigating to their own WordPress portal.
This

As many as 207 websites have been infected with malicious code designed to launch a cryptocurrency miner by leveraging WebAssembly (Wasm) on the browser.

Web security company Sucuri, which published details of the campaign, said it launched an investigation after one of its clients had their computer slowed down significantly every time upon navigating to their own WordPress portal.

This uncovered a compromise of a theme file to inject malicious JavaScript code from a remote server -- hxxps://wm.bmwebm\[.\]org/auto.js -- that's loaded whenever the website's page is accessed.

"Once decoded, the contents of auto.js immediately reveal the functionality of a cryptominer which starts mining when a visitor lands on the compromised site," Sucuri malware researcher Cesar Anjos said.

What's more, the deobfuscated auto.js code makes use of WebAssembly to run low-level binary code directly on the browser.

WebAssembly, which is supported by all major browsers, is a binary instruction format that offers performance improvements over JavaScript, allowing applications written in languages like C, C++, and Rust to be compiled into a low-level assembly-like language that can be directly run on the browser.

"When used in a web browser, Wasm runs in its own sandboxed execution environment," Anjos said. "As it is already compiled into an assembly format, the browser can read and execute its operations at a speed JavaScript itself can't match."

The actor-controlled domain, wm.bmwebm\[.\]org, is said to have been registered in January 2021, implying the infrastructure continued to remain active for more than 1.5 years without attracting any attention.

On top of that, the domain also comes with the ability to automatically generate JavaScript files that masquerade as seemingly harmless files or legitimate services like that of Google Ads (e.g., adservicegoogle.js, wordpresscore.js, and facebook-sdk.js) to conceal its malicious behavior.

"This functionality also makes it possible for the bad actor to inject the scripts in multiple locations on the compromised website and still maintain the appearance that injections 'belong' within the environment," Anjos noted.

This is not the first time WebAssembly's ability to run high-performance applications on web pages has raised potential security red flags.

Setting aside the fact that Wasm's binary format makes detection and analysis by conventional antivirus engines more challenging, the technique could open the door to more sophisticated browser-based attacks such as e-skimming that can fly under the radar for extended periods of time.

Complicating matters further is the lack of integrity checks for Wasm modules, effectively making it impossible to determine if an application has been tampered with.

To help illustrate the security weaknesses of WebAssembly, a 2020 study by a group of academics from the University of Stuttgart and Bundeswehr University Munich unearthed security issues that could be used to write to arbitrary memory, overwrite sensitive data, and hijack control flow.

Subsequent research published in November 2021 based on a translation of 4,469 C programs with known buffer overflow vulnerabilities to Wasm found that "compiling an existing C program to WebAssembly without additional precautions may hamper its security."

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

Hackers Increasingly Using WebAssembly Coded Cryptominers to Evade Detection

Luna, Black Basta add to rapidly growing list of malware tools targeted at virtual machines deployed on VMware's bare-metal hypervisor technology.

The latest confirmations of the growing attacker interest in VMware ESXi environments are two ransomware variants that surfaced in recent weeks and have begun hitting targets worldwide.

One of the malware tools, dubbed Luna, is written in Rust and can encrypt data on ESXi virtual machines (VMs) in addition to data on Linux and Window systems. The other is Black Basta, a rapidly proliferating ransomware variant written in C++ that, like Luna, targets ESXi VMs and also works on Windows and Linux systems as well.

They add to a collection of ransomware variants aimed at ESXi, VMware's bare-metal hypervisor for running virtual machines. Numerous organizations use the technology to deploy multiple VMs on a single host system or across a cluster of host systems, making the environment an ideal target for attackers looking to cause widespread damage.

"Infrastructure services like networking equipment and hosting infrastructure like ESXi can't easily be patched on demand," says Tim McGuffin, director of adversarial engineering at Lares Consulting. "Attacking these services provides a one-stop shop for impact since a large number of servers can be encrypted or attacked at once."

Other recent examples of malware targeting ESXi environments include Cheerscrypt, LockBit, RansomEXX, and Hive.

**The Cross-Platform Ransomware Threat**

Researchers from Kaspersky first spotted Luna in the wild last month. Their analysis shows the malware to fall into the trend of several other recent variants that are written in platform-agnostic languages like Rust and Golang, so they can be easily ported across different operating systems. The researchers also found the malware to employ a somewhat rare combination of AES and x25519 cryptographic protocols to encrypt data on victim systems. The security vendor assessed the operator of the malware to be likely based in Russia.

Kaspersky's analysis of a recent version of Black Basta — a ransomware variant it has been tracking since February — shows the malware has been tweaked so it can now encrypt specific directories, or the entire “/vmfs/volumes” folder, on ESXi VMs. The malware uses the ChaCha20 256-bit cipher to encrypt files on victim systems. It also uses multithreading to speed up the encryption process by getting all processors on the infected systems to work at the same time on the task.

Since surfacing in February, the operators of Black Basta have managed to compromise at least 40 organizations worldwide. Victims include organizations in the manufacturing and electronics sectors in the US and multiple other countries. Available telemetry suggests the threat actor could soon chalk up other hits across Europe, United States, and Asia, according to Kaspersky.

**A Target for Inflicting Wide Damage**

The proliferation of ransomware targeting ESXi systems poses a major threat to organizations using the technology, security experts have noted. An attacker that gains access to an EXSi host system can infect all virtual machines running on it and the host itself. If the host is part of a larger cluster with shared storage volumes, an attacker can infect all VMs in the cluster as well, causing widespread damage.

"If a VMware guest server is encrypted at the operating system level, recovery from VMware backups or snapshots can be fairly easy," McGuffin says. '\[But\] if the VMware server itself is used to encrypt the guests, those backups and snapshots are likely encrypted as well." Recovering from such an attack would require first recovering the infrastructure and then the virtual machines. "Organizations should consider truly offline storage for backups where they will be unavailable for attackers to encrypt," McGuffin adds.

Vulnerabilities are another factor that is likely fueling attacker interest in ESXi. VMware has disclosed multiple vulnerabilities in recent months. In February, for instance, the company disclosed five flaws — including important and critical ones — that affected ESXi (CVE-2021-22040, CVE-2021-22041, CVE-2021-22042, CVE-2021-22043, and CVE-2021-22050). The same month, VMware announced a heap overflow vulnerability in the technology (CVE-2021-22045), and there have been multiple other moderate to low severity flaws the company has disclosed over the past year or so, including a critical remote code execution flaw.

"In recent months, VMware ESXi had several notable vulnerability disclosures and patches, which might be why attackers have an increased interest in targeting those environments," says Joseph Carson, chief security scientist and advisory CISO at Delinea. Most of these virtual environments tend to have a strong backup and snapshot strategy. However, attackers can cause a significant impact if they can also deploy ransomware on the backup systems as well, he says.

Carson advocates that organizations running VMware conduct risk assessments and consistently check for known vulnerabilities and misconfigurations to ensure they are patched and configured correctly. They also need to ensure that Internet-facing systems have strong access controls in place to ensure only authorized employees have access to those systems.

Matthew Warner, chief technology officer and co-founder at Blumira, points to the Log4j vulnerability as another likely reason for the mushrooming attacker interest in ESXi environments. "VMware has an incredibly wide range of solutions that utilized Log4i and were impacted by this vulnerability," he says. VMware itself acted quickly to provide mitigation guidance. But it's likely that many ignored the mitigation advice and are now targets of ransomware purveyors, he says.

"There is almost never a situation where VMware Horizon should be Internet-facing," Warner says. "It opens up untold amounts of risk to the infrastructure." Blumira has run into several instances where VMware Horizon servers were exposed due to access control issues on the firewalls, not to purposeful exposure. "This serves as a good reminder that your DMZ and Internet exposure must be monitored on an ongoing basis within your environment," he advocates.

Snowballing Ransomware Variants Highlight Growing Threat to VMware ESXi Environments

Apple Security Advisory Safari - Safari 15.6 addresses code execution and out of bounds write vulnerabilities.

-----BEGIN PGP SIGNED MESSAGE-----  
Hash: SHA256

Safari 15.6 addresses the following issues.  
Information about the security content is also available at  
https://support.apple.com/HT213341.

Safari Extensions  
Available for: macOS Big Sur and macOS Catalina  
Impact: Visiting a maliciously crafted website may leak sensitive  
data  
Description: The issue was addressed with improved UI handling.  
CVE-2022-32784: Young Min Kim of CompSec Lab at Seoul National  
University

WebKit  
Available for: macOS Big Sur and macOS Catalina  
Impact: Processing maliciously crafted web content may lead to  
arbitrary code execution  
Description: An out-of-bounds write issue was addressed with improved  
input validation.  
WebKit Bugzilla: 240720  
CVE-2022-32792: Manfred Paul (@_manfp) working with Trend Micro Zero  
Day Initiative

WebRTC  
Available for: macOS Big Sur and macOS Catalina  
Impact: Processing maliciously crafted web content may lead to  
arbitrary code execution.  
Description: A memory corruption issue was addressed with improved  
state management.  
WebKit Bugzilla: 242339  
CVE-2022-2294: Jan Vojtesek of Avast Threat Intelligence team

Safari 15.6 may be obtained from the Mac App Store.  
All information is also posted on the Apple Security Updates  
web site: https://support.apple.com/en-us/HT201222.

This message is signed with Apple's Product Security PGP key,  
and details are available at:  
https://www.apple.com/support/security/pgp/  
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEePiLW1MrMjw19XzoeC9qKD1prhgFAmLYeuUACgkQeC9qKD1p  
rhh3QA//cN/O9LcDr67uACD/222GDWGZnm80emLeEmJaczyRYZNswciqGhAc7EPd  
qfyVvzq2DHAvFm64gGSGX6rzOzZbY9QRvkQ4TodqugeBoAIO0VM2moLTO/KR74fE  
SwWeWHTrPYD9k6/zCL7o3XdrwTcqvlbYD9AXSIJ1lI4BmmbDIjjLFjH5NfrsBixy  
vthQmj99twepLofgo1Wfjg1AfwUMrr6BVnZcpxEyBBjrjpBD5FVEZWJ+RB4nUaKP  
6aM4CPpXqPbou0w3bgMt0K8x2qpudolxOFfStu2FsSFVnw2B5khgcCL0C2qIO9Hb  
5n5NDb1FuPI7sDNcREIbBGjHqcjpQv5wkF7lz1EK6UQk3D4Rp8RJXFKYDWgwKNVA  
GcMEBXW8XmI3UrfpRJi/B8o/rMA9y75hVnPujl+KN9jX/6Ey7p09OK3hJavaFDuY  
heZyqdlfAa81Gwf+VBoF8bkYKZj2GCGOOL+zsuPLrtyEL8y28P5ZIBc5ALSzDgK5  
Fv4VnaE4adu8NIqU3DimQeD44G4IpZAhhS4BMiTVosZ+KUjtnX3hmFR+wI8bV2I1  
oBYtwRZOUyMHAfRSLtJFriqy5N5XK4NRD4Xb9q5auOOeyhWcgGY0K+9kSTNdDP6o  
hR93N6uOYQt7htOmiXF7ztUDMikh2i7A9NScLyX/k3y9uvtWMmw=  
=bU24  
-----END PGP SIGNATURE-----

Apple Security Advisory 2022-07-20-7

QPDF v8.4.2 was discovered to contain a heap buffer overflow via the function QPDF::processXRefStream. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted PDF file.

Hi, I have found a heap-buffer-overflow in QPDF 8.4.2 using ASAN, which has not been reported yet. But after d71f05c, the heap-buffer-overflow seems to disappear. I don't know exactly how the commit mitigate the problem since it was intended to fix sign and conversion warnings.

To reproduce, compile QPDF with address sanitizer

export CC=clang
export CXX=clang++
export CFLAGS="\-g -fsanitize=address"
export CPPFLAGS="\-g -fsanitize=address"
export LDFLAGS="\-fsanitize=address"

Download the testcase HeapBOF-processXRefStream.zip

qpdf ./HeapBOF-processXRefStream -

Then after some warnings, ASAN should complain about heap-buffer-overflow.

    ❯ ./install/bin/qpdf ./HeapBOF-processXRefStream -
    WARNING: ./HeapBOF-processXRefStream (xref stream: object 24 0, offset 127): unknown token while reading object; treating as string
    WARNING: ./HeapBOF-processXRefStream (xref stream: object 24 0, offset 189): invalid character (i) in hexstring
    WARNING: ./HeapBOF-processXRefStream (xref stream: object 24 0, offset 201): unknown token while reading object; treating as string
    WARNING: ./HeapBOF-processXRefStream (xref stream: object 24 0, offset 235): unexpected >
    WARNING: ./HeapBOF-processXRefStream (xref stream: object 24 0, offset 269): unknown token while reading object; treating as string
    WARNING: ./HeapBOF-processXRefStream (xref stream: object 24 0, offset 273): unknown token while reading object; treating as string
    WARNING: ./HeapBOF-processXRefStream (xref stream: object 24 0, offset 302): unknown token while reading object; treating as string
    WARNING: ./HeapBOF-processXRefStream (xref stream: object 24 0, offset 320): unexpected )
    WARNING: ./HeapBOF-processXRefStream (xref stream: object 24 0, offset 380): treating unexpected array close token as null
    WARNING: ./HeapBOF-processXRefStream (xref stream: object 24 0, offset 127): expected dictionary key but found non-name object; inserting key /QPDFFake1
    WARNING: ./HeapBOF-processXRefStream (xref stream: object 24 0, offset 127): expected dictionary key but found non-name object; inserting key /QPDFFake2
    WARNING: ./HeapBOF-processXRefStream (xref stream: object 24 0, offset 127): expected dictionary key but found non-name object; inserting key /QPDFFake3
    WARNING: ./HeapBOF-processXRefStream (xref stream: object 24 0, offset 127): expected dictionary key but found non-name object; inserting key /QPDFFake4
    WARNING: ./HeapBOF-processXRefStream (xref stream: object 24 0, offset 127): expected dictionary key but found non-name object; inserting key /QPDFFake5
    WARNING: ./HeapBOF-processXRefStream (xref stream: object 24 0, offset 127): expected dictionary key but found non-name object; inserting key /QPDFFake6
    WARNING: ./HeapBOF-processXRefStream (xref stream: object 24 0, offset 127): expected dictionary key but found non-name object; inserting key /QPDFFake7
    WARNING: ./HeapBOF-processXRefStream (xref stream: object 24 0, offset 127): expected dictionary key but found non-name object; inserting key /QPDFFake8
    WARNING: ./HeapBOF-processXRefStream (xref stream: object 24 0, offset 124): /Length key in stream dictionary is not an integer
    WARNING: ./HeapBOF-processXRefStream (xref stream: object 24 0, offset 391): attempting to recover stream length
    WARNING: ./HeapBOF-processXRefStream (xref stream: object 24 0, offset 391): recovered stream length: 31
    WARNING: ./HeapBOF-processXRefStream (xref stream, offset 116): Cross-reference stream data has the wrong size; expected = 35; actual = 38
    =================================================================
    ==2770728==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x604000008936 at pc 0x561e09240f1c bp 0x7ffc29847050 sp 0x7ffc29847048
    READ of size 1 at 0x604000008936 thread T0
        #0 0x561e09240f1b in QPDF::processXRefStream(long long, QPDFObjectHandle&) qpdf/qpdf-8.4.2/libqpdf/QPDF.cc:1132:33
        #1 0x561e092362f4 in QPDF::read_xrefStream(long long) qpdf/qpdf-8.4.2/libqpdf/QPDF.cc:970:20
        #2 0x561e0922415a in QPDF::read_xref(long long) qpdf/qpdf-8.4.2/libqpdf/QPDF.cc:598:20
        #3 0x561e09220faf in QPDF::parse(char const*) qpdf/qpdf-8.4.2/libqpdf/QPDF.cc:403:2
        #4 0x561e0921f54a in QPDF::processFile(char const*, char const*) qpdf/qpdf-8.4.2/libqpdf/QPDF.cc:204:5
        #5 0x561e091d759f in PointerHolder<QPDF> do_process_once<char const*>(void (QPDF::*)(char const*, char const*), char const*, char const*, Options&, bool) qpdf/qpdf-8.4.2/qpdf/qpdf.cc:4005:9
        #6 0x561e091c69cd in PointerHolder<QPDF> do_process<char const*>(void (QPDF::*)(char const*, char const*), char const*, char const*, Options&, bool) qpdf/qpdf-8.4.2/qpdf/qpdf.cc:4043:16
        #7 0x561e091c69cd in process_file(char const*, char const*, Options&) qpdf/qpdf-8.4.2/qpdf/qpdf.cc:4105:12
        #8 0x561e091bd6de in realmain(int, char**) qpdf/qpdf-8.4.2/qpdf/qpdf.cc:5062:13
        #9 0x561e091d73f8 in main qpdf/qpdf-8.4.2/qpdf/qpdf.cc:5143:12
        #10 0x7f9220def30f in __libc_start_call_main libc-start.c
        #11 0x7f9220def3c0 in __libc_start_main@GLIBC_2.2.5 (/usr/lib/libc.so.6+0x2d3c0)
        #12 0x561e0908ce84 in _start (qpdf/qpdf-8.4.2/install/bin/qpdf+0x72e84)
    
    0x604000008936 is located 0 bytes to the right of 38-byte region [0x604000008910,0x604000008936)
    allocated by thread T0 here:
        #0 0x561e09171491 in operator new[](unsigned long) (qpdf/qpdf-8.4.2/install/bin/qpdf+0x157491)
        #1 0x561e09415c90 in Buffer::init(unsigned long, unsigned char*, bool) qpdf/qpdf-8.4.2/libqpdf/Buffer.cc:45:22
        #2 0x561e09415c90 in Buffer::Buffer(unsigned long) qpdf/qpdf-8.4.2/libqpdf/Buffer.cc:12:5
        #3 0x561e094201bf in Pl_Buffer::getBuffer() qpdf/qpdf-8.4.2/libqpdf/Pl_Buffer.cc:72:21
        #4 0x561e09378e16 in QPDF_Stream::getStreamData(qpdf_stream_decode_level_e) qpdf/qpdf-8.4.2/libqpdf/QPDF_Stream.cc:171:16
        #5 0x561e092b4495 in QPDFObjectHandle::getStreamData(qpdf_stream_decode_level_e) qpdf/qpdf-8.4.2/libqpdf/QPDFObjectHandle.cc:1041:31
        #6 0x561e0923e592 in QPDF::processXRefStream(long long, QPDFObjectHandle&) qpdf/qpdf-8.4.2/libqpdf/QPDF.cc:1086:41
        #7 0x561e092362f4 in QPDF::read_xrefStream(long long) qpdf/qpdf-8.4.2/libqpdf/QPDF.cc:970:20
        #8 0x561e0922415a in QPDF::read_xref(long long) qpdf/qpdf-8.4.2/libqpdf/QPDF.cc:598:20
        #9 0x561e09220faf in QPDF::parse(char const*) qpdf/qpdf-8.4.2/libqpdf/QPDF.cc:403:2
        #10 0x561e0921f54a in QPDF::processFile(char const*, char const*) qpdf/qpdf-8.4.2/libqpdf/QPDF.cc:204:5
        #11 0x561e091d759f in PointerHolder<QPDF> do_process_once<char const*>(void (QPDF::*)(char const*, char const*), char const*, char const*, Options&, bool) qpdf/qpdf-8.4.2/qpdf/qpdf.cc:4005:9
        #12 0x561e091c69cd in PointerHolder<QPDF> do_process<char const*>(void (QPDF::*)(char const*, char const*), char const*, char const*, Options&, bool) qpdf/qpdf-8.4.2/qpdf/qpdf.cc:4043:16
        #13 0x561e091c69cd in process_file(char const*, char const*, Options&) qpdf/qpdf-8.4.2/qpdf/qpdf.cc:4105:12
        #14 0x561e091bd6de in realmain(int, char**) qpdf/qpdf-8.4.2/qpdf/qpdf.cc:5062:13
        #15 0x561e091d73f8 in main qpdf/qpdf-8.4.2/qpdf/qpdf.cc:5143:12
        #16 0x7f9220def30f in __libc_start_call_main libc-start.c
    
    SUMMARY: AddressSanitizer: heap-buffer-overflow qpdf/qpdf-8.4.2/libqpdf/QPDF.cc:1132:33 in QPDF::processXRefStream(long long, QPDFObjectHandle&)
    Shadow bytes around the buggy address:
      0x0c087fff90d0: fa fa fd fd fd fd fd fa fa fa fd fd fd fd fd fa
      0x0c087fff90e0: fa fa fd fd fd fd fd fa fa fa fd fd fd fd fd fa
      0x0c087fff90f0: fa fa fd fd fd fd fd fa fa fa fd fd fd fd fd fa
      0x0c087fff9100: fa fa fd fd fd fd fd fa fa fa fd fd fd fd fd fa
      0x0c087fff9110: fa fa fd fd fd fd fd fa fa fa fd fd fd fd fd fa
    =>0x0c087fff9120: fa fa 00 00 00 00[06]fa fa fa fa fa fa fa fa fa
      0x0c087fff9130: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c087fff9140: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c087fff9150: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c087fff9160: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c087fff9170: 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
    ==2770728==ABORTING
    

I find https://github.com/qpdf/qpdf/blob/release-qpdf-8.4.2/libqpdf/QPDF.cc#L1111-L1134 responsible for this heap-buffer-overflow.

After reading and debugging this code, I try to explain the reason as below.

data points to a piece of previously allocated buf with size of 38, which equals to actual_size. expected_size = entry_size \* num_entries = 5 \* 7 = 35, and the expected\_size < actual\_size is just warn and will not throw an exception.

In each time of the first loop, entry += entry_size, then p = entry. The second loop iterates j in range(0,3), the innermost loop and then increase W\[j\] to p, the final overflow exceeds the size of 38, triggering heap-buffer-overflow.

Tag

#c++