Categories: News
Tags: POS

Tags:  malware

Tags:  credit card

Tags:  credit identity theft

Tags:  C2

Tags:  MajikPOS

Tags:  Treasure Hunter

Researchers have discovered the theft of 167,000 sets of credit card detials by MajikPOS and Treasure Hunter POS malware



(Read more...)




The post Point-of-sale malware used to steal 167,000 credit cards appeared first on Malwarebytes Labs.

In the 19 months between February 2021 and September 2022, two point-of-sale (POS) malware operators have stolen more than 167,000 payment records, mainly from the US, according to researchers at Group-IB. The researchers were able to retrieve information about infected machines and compromised credit cards by analyzing a command and control (C2) server used by the malware.

POS malware is designed to steal debit and credit card data from POS machines in retail stores. It does this by harvesting the temporarily unencrypted card data from the machine’s memory. Due to improved security measures against this type of theft in most countries, this type of malware isn't as widely used as it once was, although it never disappeared completely.

**The malware**

The researchers found badly configured control panels for two different strains of POS malware, MajikPOS and Treasure Hunter. A possible explanation is that the operatros started out using Treasure Hunter and adapted MajikPOS at a later time. This is likely because the source code for MajikPOS has been circulating on the Dark Web and it offers additional features compared to Treasure Hunter.

The basic ability of all POS malware is the same—to steal sensitive card payment details from the RAM of a POS device where the data can be found in an unencrypted form. But different families offer other options when it comes to persistence and processing stolen data.

The machines targeted by the malware were found by scanning for remote desktop applications like RDP and VNC, and then guessing their passwords. Successfully guessing their passwords gave the attackers the same access to those computers as they would get if they were actually sat in front of them.

During the investigation, Group-IB specialists analyzed around 77,400 unique card dumps from the MajikPOS panel and about 90,000 from the Treasure Hunter panel. Most of the stolen cards were issued by US banks, and most of the infected POS terminals are located in the US.

The average price for a single card dump is around $20, so if the threat actors were able to sell the stolen dumps on an underground market, they could have made in excessive of $3 million.

**Credit identity theft**

Credit identity theft happens when a scammer steals your credit card data and uses it to make fraudulent purchases or obtains a credit card or loan under your name. According to the FTC, people who suspect they are the victim of credit identity theft should contact their bank or credit card company to cancel their card and request a new one. If you get a new card, don’t forget to update any automatic payments with your new card number.

To find out if you are a vicitm:

*   Review your transactions regularly, to make sure no one has misused your card.
*   If you find fraudulent charges, call the fraud department and get them removed.
*   Check your credit report at annualcreditreport.com.

**Mitigation**

All the usual, basic (and effective) security advice applies to POS device owners. If you operate POS machines:

*   Implement a plan for patching software in a timely manner
*   Protect passwords with two-factor authentication, preferably FIDO 2
*   Use a strong password policy and rate limiting to further protect passwords
*   Run endpoint security software with EDR to detect malware and intruders
*   Assign access rights according to the Principle of Least Privilege
*   Segment networks to slow down lateral movement

Point-of-sale malware used to steal 167,000 credit cards

Your anti-malware software may not work if you upgraded to the new operating system. But Apple says a fix is on the way.

The release of Apple's new macOS 13 Ventura operating system on October 24 brought a host of new features to Mac users, but it's also causing problems for those who rely on third-party security programs like malware scanners and monitoring tools. 

In the process of patching a vulnerability in the 11th Ventura developer beta, released on October 11, Apple accidentally introduced a flaw that cuts off third-party security products from the access they need to do their scans. And while there is a workaround to grant the permission, those who upgrade their Macs to Ventura may not realize that anything is amiss or have the information needed to fix the problem. 

Apple told WIRED that it will resolve the issue in the next macOS software update but declined to say when that would be. In the meantime, users could be unaware that their Mac security tools aren't functioning as expected. The confusion has left third-party security vendors scrambling to understand the scope of the problem.

“Of course, all of this coincided with us releasing a beta that was supposed to be compatible with Ventura,” says Thomas Reed, director of Mac and mobile platforms at the antivirus maker Malwarebytes. “So we were getting bug reports from customers that something was wrong, and we were like, ‘crap, we just released a flawed beta.’ We even pulled our beta out of circulation temporarily. But then we started seeing reports about other products, too, after people upgraded to Ventura, so we were like, ‘uh oh, this is bad.’”

Security monitoring tools need system visibility, known as full disk access, to conduct their scans and detect malicious activity. This access is significant and should be granted only to trusted programs, because it could be abused in the wrong hands. As a result, Apple requires users to go through multiple steps and authenticate before they grant permission to an antivirus service or system monitoring tool. This makes it much less likely that an attacker could somehow circumvent these hurdles or trick a user into unknowingly granting access to a malicious program. 

Longtime macOS security researcher Csaba Fitzl found, though, that while these setup protections were robust, he could exploit a vulnerability in the macOS user privacy protection known as Transparency, Consent, and Control to easily deactivate or revoke the permission once granted. In other words, an attacker could potentially disable the very tools users rely on to warn them about suspicious activity. 

Apple attempted to fix the flaw multiple times throughout 2022, but each time, Fitzl says, he was able to find a workaround for the company's patch. Finally, Apple took a bigger step in Ventura and made more comprehensive changes to how it manages the permission for security services. In doing that, though, the company made a different mistake that's now causing the current issues.

“Apple fixed it, and then I bypassed the fix, so they fixed it again, and I bypassed it again,” Fitzl says. “We went back and forth like three times, and eventually they decided that they will redesign the whole concept, which I think was the right thing to do. But it was a bit unfortunate that it came out in the Ventura beta so close to the public release, just two weeks before. There wasn't time to be aware of the issue. It just happened.”

If you use a security scanner on your Mac and you update to macOS Ventura, check the program directly to see if it's flagging an error. The workaround to fix the problem is simple once you know to do it. In System Preferences go to Security & Privacy, then the Privacy tab, and then Full Disk Access. Click the lock icon in the lower-left corner of the screen and authenticate with your system password to allow changes. Then uncheck the box next to any security services that are malfunctioning, to let the system know you want to disable their permission. Click the lock in the lower-left corner again to save the change, then redo the process and recheck the relevant boxes to freshly enable the permission without the flaw.

“Once you upgrade to Ventura, you could run a Malwarebytes scan, but it wouldn’t scan everything that it could if it had full disk access, and all of the real-time protection features are completely disabled,” Malwarebytes' Reed says. “We get handicapped if we don’t get full disk access. And there are a number of ways that you could tell if Malwarebytes is not functioning properly, but if you’re not looking in the right places or you disabled certain settings, you might not notice. With other security clients, it's probably similar—if you’re not interacting with it, you might not know.”

Researchers noticed—and Apple confirmed to WIRED—that the bug doesn't happen when large organizations use Apple's “mobile device management” program to upgrade their fleet of devices to Ventura. This is significant, because if the bug carried over to managed enterprise devices, it would mean yet another reason for companies to put off important software updates. 

MacOS security researcher Patrick Wardle, founder of the Objective-See Foundation, says that he still recommends regular users upgrade their Macs to Ventura to get the new operating system's other security and privacy protections. In the meantime, though, Wardle says he has been deluged by bug reports about his free, open source malware monitoring tool, BlockBlock. The Ventura bug even makes it appear that security services like BlockBlock and Malwarebytes have been granted extra system access beyond what these programs request, including the accessibility permission, access to input monitoring, and even screen recording. 

“Users were understandably asking me, ‘Why does your tool need that?!’ And I'm like, ‘Uh, I have no idea. It doesn't!’” Wardle says. “It shows that when Apple is pushing out security fixes for reported bugs, they're still struggling to do that comprehensively and successfully without breaking other things. And in this case, they’re shipping a version of their operating system that is breaking security tools for millions, if not tens of millions, of users. It's frustrating and disheartening.”

Independent researcher Fitzl, who presented his original disabling permission vulnerability findings at Black Hat Asia in May and Wardle's Objective-See Mac and iOS security conference at the beginning of October, says that he's sympathetic about the misstep. 

“Apple was trying to redesign this thing to fix all of my bypasses, and they made a mistake—it happens,” he says. But he adds, ruefully, that the whole situation has played out in an unfortunate way. “I felt a bit weird about all of these issues and knowing that I pushed Apple into this because I was trying to get something else fixed.”

Apple MacOS Ventura Bug Breaks Third-Party Security Tools

Chrome's Stable Channel 107 rollout includes security fixes from a slew of independent researchers, racking up nearly $60,000 in bounties.

Google Chrome's rollout of its latest browser update includes 14 individual security fixes — three high-severity — found by independent researchers who earned bug bounty payouts totaling more than $57,000. 

There is still one high-severity bug with a payout amount listed as "TBD," meaning the final collective tally could top $60,000. 

The latest update, Chrome 107 for Windows, Mac, and Linux, will roll out over the coming days, Google announced, along with the new version's security improvements. 

"We would also like to thank all security researchers that worked with us during the development cycle to prevent security bugs from ever reaching the stable channel," the Chrome team said about the update's release. 

Keep up with the latest cybersecurity threats, newly-discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

Subscribe

Google Chrome Pays $57K (and Counting) in Bug Bounties for Latest Update

The manufacturing segment was especially hard hit by cyberattacks in the third quarter of 2022.

Ransomware gangs are hitting the industrial sector hard — and especially manufacturing companies, with significant spikes in cyberattack activity against US organizations spotted in the third quarter. Meanwhile, emerging ransomware groups are bursting onto the scene, threatening to push the rate of attacks up even higher.

According to a Dragos Q3 analysis of ransomware attacks on industrial organizations, 36% of the recorded cases globally hit North America (46 incidents). This is a significant 10% increase over last quarter, when a quarter of cases affected the region.

However, the analysis also found that the rate of attacks globally remained flat quarter over quarter — 128 incidents for Q3 vs. 125 in Q2.

The majority (68%) of observed incidents were aimed at the manufacturing sector. Out of the confirmed attacks (i.e., those publicly reported, seen in the firm's telemetry, or confirmed on the Dark Web), 88 were against that segment, especially those producing metal products (12 attacks).

Stephen Banda, senior manager of security solutions at Lookout, noted that the manufacturing sector, like everyone else, is moving to the cloud; digitizing manufacturing, inventory tracking, operations, and maintenance increases agility and efficiency, with less production downtime and a greater nimbleness. But it also opens up new attack surfaces.

"To remain competitive, manufacturers are investing in intellectual property and new technologies like digital twins," he tells Dark Reading. "In short, manufacturers are transforming the way they produce and deliver goods - moving toward industrial automation and the flexible factory. This transformation, known as Industry 4.0, puts pressure on mobile devices and cloud solutions."

Yet for most manufacturers, security solutions still remain on-premises, he adds.

"This creates efficacy and scalability challenges when tasked with protecting productivity solutions that have moved to the cloud," he notes. "Security therefore must also move to the cloud to adequately safeguard manufacturing operations."

As for other industrial segments, 9% of attacks targeted the food and beverage sector (12 incidents), followed by oil and natural gas (6%, or eight incidents) and the energy and pharmaceuticals sectors (collectively making up 10% of attacks, with seven and six incidents respectively). The chemical, mining, engineering, and water and wastewater systems segments had just one attack each.  

**Different Threat Actors Target Different Industrial Segments**

In terms of the actors on the industrial stage, the LockBit gang was behind more than a third of all global incidents (35%), while some other known names focused on the energy sector (Ragnar Locker and BlackCat/AlphaV, notably). But the quarter also saw the rise of some emerging actors, like Sparta Blog, BianLian, Donuts, Onyx, and the slow-burning Yanluowang.

In all cases, various groups seemed to have specialties, Dragos noted, including:

*   Ragnar Locker has been targeting mainly energy.
*   Cl0p Leaks has been targeting only water and wastewater.
*   Karakurt has targeted only manufacturing in Q3, while in Q2, it only targeted transportation entities.
*   LockBit 3.0 is the only group that targeted chemicals, drilling, industrial supplies, and interior design.
*   Stormous has only targeted Vietnam.
*   Lorenz has only targeted the United States.
*   Sparta Blog has only targeted Spain.
*   Black Basta and Hive mainly targeted the transportation sector.

Bud Broomhead, CEO at Viakoo, noted that specific ransomware strains targeting specific industries should galvanize intelligence sharing.

"This should spur more industry-level coordination to protect against those threats, specifically between companies that otherwise would compete in the marketplace," he says. "Rather than every organization individually mounting defenses, industry-wide responses are needed (put another way, cybercriminals are attacking an industry which requires industry-level responses). Threat actors don’t exist in silos, so why should the response to them be siloed?"

That coordination could be vitally important, given that going forward, Dragos researchers warned that more new ransomware groups will appear in the next quarter, as either new or reformed ones, due to the changes in ransomware groups and the leaking of the LockBit 3.0 builder — all of which could lead to greater attack volumes.

"\[We have\] high confidence that ransomware will continue to disrupt industrial operations, whether through the integration of \[operational technology\] OT kill processes into ransomware strains, flattened networks allowing for ransomware to spread into OT environments, or through precautionary shutdowns of OT environments by operators to prevent ransomware from spreading to OT systems," Dragos researchers said in the Wednesday report.

Broomhead noted that ramped up attacks are likely being driven by twin engines, including the Russia-Ukraine conflict.

"The rise in ransomware attacks against industrial organizations who rely on OT systems is likely coming from threat actors viewing such organizations as easier victims because OT systems and devices are much more vulnerable than traditional IT systems," he says. "While there may be a rise in targeting industrial organizations because of the conflict in Ukraine, those organizations have been targeted for a long time by several foreign adversaries, therefore this increase is a combination of industrial OT systems being easier to exploit and increased activity due to Ukraine."

Ransomware Gangs Ramp Up Industrial Attacks in US

Older bugs in the AnyConnect Secure Mobility Client are being targeted in the wild, showcasing patch-management failures.

A pair of known security vulnerabilities in the Cisco AnyConnect Secure Mobility Client for Windows is being actively exploited in the wild, despite being patched for two-plus years.

The networking giant is warning that cybercrime groups are pressing two local privilege escalation (LPE) bugs into service, with active exploit chains against the VPN platform being observed starting this month.

The first flaw (CVE-2020-3153, with a CVSS score of 6.5) would allow a logged-in user to send a specially crafted IPC message to the AnyConnect process to perform DLL hijacking and execute arbitrary code on the affected machine with SYSTEM privileges. The second issue (CVE-2020-3433, with a CVSS score of 7.8) could allow a logged-in user to copy arbitrary files to system-level directories with SYSTEM privileges.

"In October 2022, the Cisco Product Security Incident Response Team became aware of additional attempted exploitation of this vulnerability in the wild," Cisco noted in the updated advisories.

The situation showcases the danger that older vulnerabilities continue to pose to companies and individuals. LPE patches are often de-prioritized in the glut of updates that businesses are faced with every month, but exploit chains often combine a remote code execution (RCE) bug for initial access with an LPE exploit for burrowing deeper into corporate networks and uncovering sensitive information.

The US Cybersecurity and Infrastructure Security Agency (CISA) also this week added the bugs to its Known Exploited Vulnerabilities (KEV) catalog, along with four even older bugs in Cisco's Gigabyte gaming and graphics drivers (CVE-2018-19320, CVE-2018-19321, CVE-2018-19322, CVE-2018-19323). Sophos flagged exploitation of the latter earlier in the month by the BlackByte ransomware gang.

Keep up with the latest cybersecurity threats, newly-discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

Subscribe

Cisco Warns AnyConnect VPNs Under Active Cyberattack

As more of the software stack consists of third-party code, it's time for a more-advanced open source vetting system.

Cyberattacks' frequency and severity remain a growing concern for organizations large and small. Hardly a day goes by without news about a major breach or break-in. Yet it's also clear that methods are evolving and becoming stealthier. One of the more disturbing trends is attackers embedding malware in legitimate products and supply chains.

The SolarWinds attack in 2020 demonstrated just how devastating supply chain attacks can be and how far they can reach. As customers of security firm FireEye downloaded and installed legitimate patches for its Orion IT-monitoring platform, malware hidden in open source software (OSS) code infiltrated their systems.

**No Simple Task**

Gaining control of the software supply chain is vital, yet it's no simple task. OSS has emerged as an essential part of the business world and increasingly delivers critical building blocks used to produce proprietary and commercial software. A growing array of products rooted in the physical world — vehicles, airplanes, medical devices, consumer electronics, and industrial machinery, to name a few — rely on OSS to operate. Hacks and attacks on these systems represent a serious and even potentially fatal risk, ranging from ransomware to sabotage.

Yet the problem is broader. Most software developed today, including applications and code embedded in physical products, contains third-party code that falls into two separate categories:

*   **Pre-built components** that perform a specific function and are available for purchase off-the-shelf, and
*   **Commissioned code** that is developed on an outsourced basis for use in the purchasing company's product.

Both of these types of third-party code can contain embedded and undocumented OSS, which may harbor security vulnerabilities.

**Can You Trust Your Partners?**

Avoiding software supply chain risks is increasingly difficult. Much of the software any organization uses derives from a trusted vendor or partner — or it's a mash-up based on numerous sources. When patches and updates come from trusted sources and appear authentic, there's typically no reason to inspect them. However, if attackers successfully plant malware in legitimate software and it goes undetected through final release production, it can become a mass malware-dissemination tool.

As the SolarWinds attack showed, an organization's defenses are only as good as the supply chain's weakest link. An enterprise can take numerous steps to ensure that the OSS it utilizes is secure, yet it's next-to-impossible to guarantee that the third-party code a partner or vendor supplies is equally vetted. Unfortunately, everyone relies on different techniques, tests, and standards.

While open source code isn't inherently more dangerous than proprietary code, the widespread adoption of OSS means that the same code components can wind up in numerous applications, products, and systems. In fact, roughly 70% to 90% of any software "stack" consists of third-party code. This includes industries and sectors as diverse as public transportation, consumer electronics, telecom, and major software applications used by universities, government agencies, and others.

Moreover, open source code risks are on the rise. Hackers and attackers use several highly effective methods to target resources such as Python repositories (i.e., Python Package Index, or PyPI) and JavaScript package manager npm. This can lead to malware that installs cryptomining software or steals credentials and authentication tokens. An attack can also embed malware in seemingly legitimate code, such as a recent case where 186 npm typosquatting packages appeared in open source code for Linux systems.

**Cracking Down on Bad Code**

Recently, a group of organizations joined together under the umbrella of the Linux Foundation to build a framework for verifying open source code.

This group — OpenSSF (Open Source Security Foundation) — includes heavyweights such as AWS, Google, IBM, and Microsoft, as well as specialized vendors such as Akamai, Indeed, and Socket Security. Its 10-point plan \[PDF\] aims to create more consistent open source code production methods, improve vulnerability discovery and remediation, and reduce patching response times for open source software.

OpenSSF hopes to achieve these results via expanded use of digital signatures on software releases; replacing non-memory-safe languages; standard third-party code reviews; improved education and training for developers and others; and improved tools and best practices for the software supply chain.

All of this leads to a best practice referred to as a software bill of materials (SBOM). It delivers a catalog of OSS as well as other software that's present in third-party (building block) code. It also displays any security vulnerabilities that this software may contain.

**An Eye on Observability**

Getting to a more-advanced open source vetting framework also requires a closer look at the code itself. This is particularly important because organizations not only rely on OSS but also a hybrid approach that revolves around pre-built, off-the-shelf components and custom building blocks, developed internally or by outsourcing partners.

Nearly 60% of software products today contain third-party code, according to VDC Research, most of which uses open source components under the hood. Gaining the needed insight into this code is difficult because conventional software composition analysis (SCA) has inherent limitations. While SCA remains a useful tool for decomposition of software and spotting vulnerabilities, there's also the need to examine and analyze binary files. This makes it possible to scan the code that runs, rather than inspecting only the pieces in the build environment.

Binary SCA finds vulnerabilities in third-party code and OSS without actual source software; it provides deep semantic matching; it's equipped to conduct analysis on real-time code; and it delivers crucial elements such as audit logging, risk reporting, API analysis, and SBOM generation and output, including formats such as PDF, CSV, SPDX, JSON, and CycloneDX. It's a best-practice framework that delivers a comprehensive view of OSS components and other code.

With these pieces in place, it's possible to improve vulnerability detection across all sources of the software in an application or product, boost audit and compliance capabilities, and establish a coveted SBOM. There's no way to stop crooks and cybergangs from attacking organizations through the software supply chain, but the combination of an industry framework and the right inspection technology minimizes the risks and maximizes the gains of open source software.

Open Source Is Just the Tip of the Iceberg in Software Supply Chain Security

New service from BlackBerry's Threat Research and Intelligence Team reduces unknowns to enhance detection and response.

**NEW YORK, Oct. 26, 2022 /PRNewswire/** — Today, at the BlackBerry Security Summit, BlackBerry Limited (NYSE: BB; TSX: BB) announced the release of its new Cyber Threat Intelligence (CTI) offering, a professional threat intelligence service to help customers prevent, detect, and effectively respond to cyberattacks.

Delivered on a quarterly subscription basis, BlackBerry's new CTI service  
provides actionable intelligence on targeted attacks and cybercrime-motivated  
threat actors and campaigns, as well as intelligence reports specific to  
industries, regions, and countries. BlackBerry's CTI will save organizations  
time and resources by focusing on specific areas of interest relevant to a  
company's security goals.

"Being cyber resilient means making the right decisions at the right time," said  
Ismael Valenzuela, Vice President, Threat Research and Intelligence at  
BlackBerry. "Cyberattacks are becoming more sophisticated and threat actors move  
quickly. BlackBerry's Cyber Threat Intelligence delivers the details needed to  
improve detection and response, so organizations can stay on top of cyber threat  
activity and anticipate any next moves."

"More businesses are recognizing the value of threat intelligence and the  
distinctive benefits it brings to security teams," said Chris Kissel, Vice  
President, Security and Trust Products at IDC Research. "Curated threat  
intelligence from credible experts in the space provides businesses and their  
front line security personnel with timely insights, enabling them to better  
detect, triage, and investigate threats. Integrating this service with existing  
security ecosystems helps businesses stay one step ahead of cyber threats as  
digital attack surfaces evolve and expand."

The Threat Research and Intelligence Team has released numerous first-to-market  
research reports over the past year leveraging BlackBerry's data-driven digital  
ecosystem and analytical capabilities. These research reports have revealed new  
developments in the ransomware and malware space, and targeted, state-sponsored  
APT activity, including Symbiote, DCRat, Chaos Yashma ransomware and LokiLocker,  
all of which have been well-received by BlackBerry's customer base and the  
broader security community.

The service will launch in December.

For more information on how BlackBerry's Cyber Threat Intelligence service can  
support your organization, please visit BlackBerry.com to connect with one of  
our experts.

**About BlackBerry**  
BlackBerry (NYSE: BB; TSX: BB) provides intelligent security software and  
services to enterprises and governments around the world. The company secures  
more than 500M endpoints including 215M vehicles. Based in Waterloo, Ontario,  
the company leverages AI and machine learning to deliver innovative solutions in  
the areas of cybersecurity, safety, and data privacy solutions, and is a leader  
in the areas of endpoint security, endpoint management, encryption, and embedded  
systems. BlackBerry's vision is clear — to secure a connected future you can  
trust.

BlackBerry. Intelligent Security. Everywhere.

For more information, visit BlackBerry.com and follow @BlackBerry.

Trademarks, including but not limited to BLACKBERRY and EMBLEM Design are the  
trademarks or registered trademarks of BlackBerry Limited, and the exclusive  
rights to such trademarks are expressly reserved. All other trademarks are the  
property of their respective owners. BlackBerry is not responsible for any  
third-party products or services.

**SOURCE:** BlackBerry Limited

BlackBerry Launches Cyber Threat Intelligence Service to Strengthen Cyber Defenses

The mission to run any containerized application on any infrastructure makes security a challenge on Kubernetes.

Kubernetes is the de facto container management platform in the modern cloud-native world. It makes it possible to develop, deploy, and manage microservices flexibly and scalably. Kubernetes works with various cloud providers, container runtime interfaces, authentication providers, and extensible integration points.

However, Kubernetes still has one major drawback: security. The integrator approach of Kubernetes to run any containerized application on any infrastructure makes it challenging to create holistic security around Kubernetes and the application stack living on it.

According to Red Hat's 2022 "State of Kubernetes" security report, the majority of Kubernetes users had their delivery halted due to unaddressed security concerns. In addition, over the course of the previous 12 months, almost every Kubernetes user in the study experienced at least one security incident. Therefore, it is fair to say that Kubernetes environments are not secure by default and are open to risks.

This article discusses the top 10 security risks with real-life examples and tips on how to avoid them.

**1\. Kubernetes Secrets**

Secrets are one of the core building blocks of Kubernetes for storing sensitive data like passwords, certificates, or tokens and using them inside containers. There are three critical issues related to Kubernetes secrets:

*   Secrets store sensitive data as base-64 encoded strings, but they are not encrypted by default. Kubernetes does offer encryption of the resources for storage, but you need to configure it. Furthermore, the biggest threat about secrets is that any pod — and any applications running inside the pod — in the same namespace can access and read them.
*   Role-based access control (RBAC) allows you to regulate who is granted access to Kubernetes resources. You need to properly configure RBAC rules so that only the relevant people and applications will have access to secrets.
*   Secrets and ConfigMaps are the two methods of passing data to running containers. If there are old and unused secrets or ConfigMap resources, it can create confusion and leak vulnerable data. For instance, if you delete your back-end application deployment but forget to delete the secret that has your database passwords, any malicious pod can use them in the future.

**2\. Container Images With Vulnerabilities**

Kubernetes is a container orchestration platform that distributes and runs containers on the worker nodes. However, it does not check the contents of containers for whether they have security vulnerabilities or exposures.

Therefore, it is necessary to scan the images before deployment to ensure that only images from trusted registries with no critical vulnerabilities (like remote code execution) will run on the cluster. Container image scanning should also be integrated into CI/CD systems for automation and detecting flaws earlier.

**3\. Runtime Threats**

Kubernetes workloads — namely, containers — run on the worker nodes, and the containers are controlled by the host operating system in the runtime. If there are permissive policies or container images with vulnerabilities, they can open backdoors into your whole cluster. Therefore, OS-level runtime protection is required to enforce security in runtime, and the most important protection against runtime threats and vulnerabilities is to implement the least-privileged principle throughout Kubernetes.

Open source and widely accepted tools like Seccomp, SELinux, and AppArmor in the Linux kernel level are available to implement policies and restrict access. These tools are not internal to Kubernetes and require external configuration and effort to enable protection against runtime threats. In order to secure Kubernetes in an automated fashion, try employing the Kubernetes Security Posture Management (KSPM) approach. KSPM leverages automation tools to detect, fix, and alert security, configuration, and compliance issues using a holistic approach.

**4\. Cluster Misconfiguration and Default Settings**

The Kubernetes API and its components consist of a complex set of resource definitions and configuration options. Therefore, Kubernetes offers default values for most of its configuration parameters and tries to remove the burden of creating long YAML files.

However, you need to be careful about three critical issues related to cluster and resource configuration:

*   Default Kubernetes configurations are helpful, as they try to increase flexibility and agility, but they are not always the most secure options.
*   Online examples for Kubernetes resources are helpful to get started, but it is necessary to double-check what these example resource definitions will deploy to your cluster.
*   It is customary to make changes to Kubernetes resources using "kubectl edit" commands while working on the clusters. However, if you forget to update the source files, the changes will be overwritten in the next deployment, and the untracked modifications could lead to unpredictable behavior.

**5\. Kubernetes RBAC Policies**

RBAC is the Kubernetes-native method of managing and controlling authorization to Kubernetes resources. Therefore, configuring and maintaining RBAC policies is essential to secure the clusters from unwanted access.

There are two critical points to consider while working with RBAC policies. First, some RBAC policies are too permissive, such as the cluster\_admin role, which can do basically everything in the cluster. These roles are assigned to regular developers to make them more agile. However, in the event of a security breach, attackers quickly get high-level access to the clusters using cluster\_admin. To avoid this, you should configure RBAC policies for specific resources and assign them to particular user groups.

Second, in general, various environments, like development, testing, staging, and production, exist in the software development life cycle. In addition, there are multiple teams with different focuses, such as developers, testers, operators, and cloud admins. RBAC policies should be assigned correctly for each group and each environment to limit exposure.

**6\. Network Access**

In Kubernetes, a pod can connect to other pods and external addresses outside the cluster; others can connect to this pod from inside the cluster by default. Network policies are the Kubernetes-native resources to manage and restrict the network access between pods, namespaces, and IP blocks.

Network policies can also work with the labels on the pods, so inefficient use of labels could lead to unwanted access. In addition, when the clusters live in cloud providers, the cluster network should also be isolated from the rest of the virtual private cloud (VPC).

**7\. Holistic Monitoring and Audit Logging**

When you deploy an application to a Kubernetes cluster, it's not sufficient to only monitor the application metrics. You must also watch the Kubernetes cluster's status, cloud infrastructure, and cloud controllers to have a holistic view of the complete stack. It is also important to watch for breaches and detect anomalies since intruders will be testing to access your clusters from every possible opening.

Kubernetes provides out-of-the-box audit logs for security-related incidents in the cluster. Still, you also need to collect the records from various applications and monitor their health in a central place.

**8\. Kubernetes API**

Kubernetes API is the core of the entire system, where all internal and external clients connect and communicate with Kubernetes. If you deploy and manage Kubernetes components in-house, you need to be more careful because the Kubernetes API server and its components are open source tools with potential — and actual — vulnerabilities. Therefore, you should use the latest stable version of Kubernetes and patch live clusters as early as possible.

If you use cloud providers, the Kubernetes control plane is in control of the provider itself, so the cloud infrastructure updates and patches automatically. However, users are responsible for upgrading worker nodes in most cases. Therefore, you can use automation and resource provisioning tools to upgrade nodes easily or replace them with new ones.

**9\. Kubernetes Resource Requests and Limits**

In addition to scheduling and running containers, Kubernetes can also limit the resource usage of containers in terms of CPU and memory. Although Kubernetes users mostly neglect them, resource requests and limits are critical for two reasons:

*   **Security:** When the pods and namespaces are not restricted, even a single container with a security vulnerability could access sensitive data inside your cluster.
*   **Cost:** When the requested resources are more than the actual usage, the nodes will run out of available resources. This will lead to an increase in the node pool if autoscaling is enabled, and the new nodes will increase your cloud bill inevitably.

When the resource requests are calculated and assigned correctly, the whole cluster works efficiently in terms of CPU and memory. In addition, when resource limits are set, both faulty applications and intruders will be limited in terms of resource usage. For instance, if there are no resource limitations, a malicious container could consume nearly all of the resources in the node and make your application unusable.

**10\. Data and Storage**

Although containers are designed to be ephemeral, Kubernetes makes it possible to run stateful containerized applications scalably and reliably. With the StatefulSet resource, you can deploy databases, data analytics tools, and machine-learning applications into Kubernetes quickly. The data will be accessible to the pods as volumes attached to the containers.

However, it is critical to limit access by policies and labels to avoid unwanted access by other pods in the cluster. In addition, storage in Kubernetes is provided by external systems, so you should consider using encryption for critical data in the cluster. If you manage your storage plugins, you should also check the security parameters to ensure that they are enabled.

**Conclusion**

Kubernetes is the indisputable container management platform for running microservice applications. However, holistic security is still one of its drawbacks, as it is not the core focus of the project. Therefore, you need to take extra steps to make your clusters and applications more secure.

Top 10 Kubernetes Security Risks Every DevSecOps Pro Should Know

Red Hat Security Advisory 2022-7171-01 - The kernel packages contain the Linux kernel, the core of any Linux operating system. Issues addressed include privilege escalation and use-after-free vulnerabilities.

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

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

Synopsis:          Important: kernel security and bug fix update  
Advisory ID:       RHSA-2022:7171-01  
Product:           Red Hat Enterprise Linux  
Advisory URL:      https://access.redhat.com/errata/RHSA-2022:7171  
Issue date:        2022-10-25  
CVE Names:         CVE-2022-2588  
====================================================================  
1. Summary:

An update for kernel is now available for Red Hat Enterprise Linux 7.6  
Advanced Update Support, Red Hat Enterprise Linux 7.6 Telco Extended Update  
Support, and Red Hat Enterprise Linux 7.6 Update Services for SAP  
Solutions.

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

2. Relevant releases/architectures:

Red Hat Enterprise Linux Server AUS (v. 7.6) - noarch, x86_64  
Red Hat Enterprise Linux Server E4S (v. 7.6) - noarch, ppc64le, x86_64  
Red Hat Enterprise Linux Server Optional AUS (v. 7.6) - x86_64  
Red Hat Enterprise Linux Server Optional E4S (v. 7.6) - ppc64le, x86_64  
Red Hat Enterprise Linux Server Optional TUS (v. 7.6) - x86_64  
Red Hat Enterprise Linux Server TUS (v. 7.6) - noarch, x86_64

3. Description:

The kernel packages contain the Linux kernel, the core of any Linux  
operating system.

Security Fix(es):

* a use-after-free in cls_route filter implementation may lead to privilege  
escalation (CVE-2022-2588)

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

Bug Fix(es):

* backports from upstream for netfilter (BZ#2120635)

4. Solution:

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

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

The system must be rebooted for this update to take effect.

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

2114849 - CVE-2022-2588 kernel: a use-after-free in cls_route filter implementation may lead to privilege escalation

6. Package List:

Red Hat Enterprise Linux Server AUS (v. 7.6):

Source:  
kernel-3.10.0-957.99.1.el7.src.rpm

noarch:  
kernel-abi-whitelists-3.10.0-957.99.1.el7.noarch.rpm  
kernel-doc-3.10.0-957.99.1.el7.noarch.rpm

x86_64:  
bpftool-3.10.0-957.99.1.el7.x86_64.rpm  
kernel-3.10.0-957.99.1.el7.x86_64.rpm  
kernel-debug-3.10.0-957.99.1.el7.x86_64.rpm  
kernel-debug-debuginfo-3.10.0-957.99.1.el7.x86_64.rpm  
kernel-debug-devel-3.10.0-957.99.1.el7.x86_64.rpm  
kernel-debuginfo-3.10.0-957.99.1.el7.x86_64.rpm  
kernel-debuginfo-common-x86_64-3.10.0-957.99.1.el7.x86_64.rpm  
kernel-devel-3.10.0-957.99.1.el7.x86_64.rpm  
kernel-headers-3.10.0-957.99.1.el7.x86_64.rpm  
kernel-tools-3.10.0-957.99.1.el7.x86_64.rpm  
kernel-tools-debuginfo-3.10.0-957.99.1.el7.x86_64.rpm  
kernel-tools-libs-3.10.0-957.99.1.el7.x86_64.rpm  
perf-3.10.0-957.99.1.el7.x86_64.rpm  
perf-debuginfo-3.10.0-957.99.1.el7.x86_64.rpm  
python-perf-3.10.0-957.99.1.el7.x86_64.rpm  
python-perf-debuginfo-3.10.0-957.99.1.el7.x86_64.rpm

Red Hat Enterprise Linux Server E4S (v. 7.6):

Source:  
kernel-3.10.0-957.99.1.el7.src.rpm

noarch:  
kernel-abi-whitelists-3.10.0-957.99.1.el7.noarch.rpm  
kernel-doc-3.10.0-957.99.1.el7.noarch.rpm

ppc64le:  
kernel-3.10.0-957.99.1.el7.ppc64le.rpm  
kernel-bootwrapper-3.10.0-957.99.1.el7.ppc64le.rpm  
kernel-debug-3.10.0-957.99.1.el7.ppc64le.rpm  
kernel-debug-debuginfo-3.10.0-957.99.1.el7.ppc64le.rpm  
kernel-debuginfo-3.10.0-957.99.1.el7.ppc64le.rpm  
kernel-debuginfo-common-ppc64le-3.10.0-957.99.1.el7.ppc64le.rpm  
kernel-devel-3.10.0-957.99.1.el7.ppc64le.rpm  
kernel-headers-3.10.0-957.99.1.el7.ppc64le.rpm  
kernel-tools-3.10.0-957.99.1.el7.ppc64le.rpm  
kernel-tools-debuginfo-3.10.0-957.99.1.el7.ppc64le.rpm  
kernel-tools-libs-3.10.0-957.99.1.el7.ppc64le.rpm  
perf-3.10.0-957.99.1.el7.ppc64le.rpm  
perf-debuginfo-3.10.0-957.99.1.el7.ppc64le.rpm  
python-perf-3.10.0-957.99.1.el7.ppc64le.rpm  
python-perf-debuginfo-3.10.0-957.99.1.el7.ppc64le.rpm

x86_64:  
kernel-3.10.0-957.99.1.el7.x86_64.rpm  
kernel-debug-3.10.0-957.99.1.el7.x86_64.rpm  
kernel-debug-debuginfo-3.10.0-957.99.1.el7.x86_64.rpm  
kernel-debug-devel-3.10.0-957.99.1.el7.x86_64.rpm  
kernel-debuginfo-3.10.0-957.99.1.el7.x86_64.rpm  
kernel-debuginfo-common-x86_64-3.10.0-957.99.1.el7.x86_64.rpm  
kernel-devel-3.10.0-957.99.1.el7.x86_64.rpm  
kernel-headers-3.10.0-957.99.1.el7.x86_64.rpm  
kernel-tools-3.10.0-957.99.1.el7.x86_64.rpm  
kernel-tools-debuginfo-3.10.0-957.99.1.el7.x86_64.rpm  
kernel-tools-libs-3.10.0-957.99.1.el7.x86_64.rpm  
perf-3.10.0-957.99.1.el7.x86_64.rpm  
perf-debuginfo-3.10.0-957.99.1.el7.x86_64.rpm  
python-perf-3.10.0-957.99.1.el7.x86_64.rpm  
python-perf-debuginfo-3.10.0-957.99.1.el7.x86_64.rpm

Red Hat Enterprise Linux Server TUS (v. 7.6):

Source:  
kernel-3.10.0-957.99.1.el7.src.rpm

noarch:  
kernel-abi-whitelists-3.10.0-957.99.1.el7.noarch.rpm  
kernel-doc-3.10.0-957.99.1.el7.noarch.rpm

x86_64:  
bpftool-3.10.0-957.99.1.el7.x86_64.rpm  
kernel-3.10.0-957.99.1.el7.x86_64.rpm  
kernel-debug-3.10.0-957.99.1.el7.x86_64.rpm  
kernel-debug-debuginfo-3.10.0-957.99.1.el7.x86_64.rpm  
kernel-debug-devel-3.10.0-957.99.1.el7.x86_64.rpm  
kernel-debuginfo-3.10.0-957.99.1.el7.x86_64.rpm  
kernel-debuginfo-common-x86_64-3.10.0-957.99.1.el7.x86_64.rpm  
kernel-devel-3.10.0-957.99.1.el7.x86_64.rpm  
kernel-headers-3.10.0-957.99.1.el7.x86_64.rpm  
kernel-tools-3.10.0-957.99.1.el7.x86_64.rpm  
kernel-tools-debuginfo-3.10.0-957.99.1.el7.x86_64.rpm  
kernel-tools-libs-3.10.0-957.99.1.el7.x86_64.rpm  
perf-3.10.0-957.99.1.el7.x86_64.rpm  
perf-debuginfo-3.10.0-957.99.1.el7.x86_64.rpm  
python-perf-3.10.0-957.99.1.el7.x86_64.rpm  
python-perf-debuginfo-3.10.0-957.99.1.el7.x86_64.rpm

Red Hat Enterprise Linux Server Optional AUS (v. 7.6):

x86_64:  
kernel-debug-debuginfo-3.10.0-957.99.1.el7.x86_64.rpm  
kernel-debuginfo-3.10.0-957.99.1.el7.x86_64.rpm  
kernel-debuginfo-common-x86_64-3.10.0-957.99.1.el7.x86_64.rpm  
kernel-tools-debuginfo-3.10.0-957.99.1.el7.x86_64.rpm  
kernel-tools-libs-devel-3.10.0-957.99.1.el7.x86_64.rpm  
perf-debuginfo-3.10.0-957.99.1.el7.x86_64.rpm  
python-perf-debuginfo-3.10.0-957.99.1.el7.x86_64.rpm

Red Hat Enterprise Linux Server Optional E4S (v. 7.6):

ppc64le:  
kernel-debug-debuginfo-3.10.0-957.99.1.el7.ppc64le.rpm  
kernel-debug-devel-3.10.0-957.99.1.el7.ppc64le.rpm  
kernel-debuginfo-3.10.0-957.99.1.el7.ppc64le.rpm  
kernel-debuginfo-common-ppc64le-3.10.0-957.99.1.el7.ppc64le.rpm  
kernel-tools-debuginfo-3.10.0-957.99.1.el7.ppc64le.rpm  
kernel-tools-libs-devel-3.10.0-957.99.1.el7.ppc64le.rpm  
perf-debuginfo-3.10.0-957.99.1.el7.ppc64le.rpm  
python-perf-debuginfo-3.10.0-957.99.1.el7.ppc64le.rpm

x86_64:  
kernel-debug-debuginfo-3.10.0-957.99.1.el7.x86_64.rpm  
kernel-debuginfo-3.10.0-957.99.1.el7.x86_64.rpm  
kernel-debuginfo-common-x86_64-3.10.0-957.99.1.el7.x86_64.rpm  
kernel-tools-debuginfo-3.10.0-957.99.1.el7.x86_64.rpm  
kernel-tools-libs-devel-3.10.0-957.99.1.el7.x86_64.rpm  
perf-debuginfo-3.10.0-957.99.1.el7.x86_64.rpm  
python-perf-debuginfo-3.10.0-957.99.1.el7.x86_64.rpm

Red Hat Enterprise Linux Server Optional TUS (v. 7.6):

x86_64:  
kernel-debug-debuginfo-3.10.0-957.99.1.el7.x86_64.rpm  
kernel-debuginfo-3.10.0-957.99.1.el7.x86_64.rpm  
kernel-debuginfo-common-x86_64-3.10.0-957.99.1.el7.x86_64.rpm  
kernel-tools-debuginfo-3.10.0-957.99.1.el7.x86_64.rpm  
kernel-tools-libs-devel-3.10.0-957.99.1.el7.x86_64.rpm  
perf-debuginfo-3.10.0-957.99.1.el7.x86_64.rpm  
python-perf-debuginfo-3.10.0-957.99.1.el7.x86_64.rpm

These packages are GPG signed by Red Hat for security.  Our key and  
details on how to verify the signature are available from  
https://access.redhat.com/security/team/key/

7. References:

https://access.redhat.com/security/cve/CVE-2022-2588  
https://access.redhat.com/security/updates/classification/#important

8. Contact:

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

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

iQIVAwUBY1gohNzjgjWX9erEAQh9jxAAo0hX0U836zHymb/7X8cI2lgKfgeq8NPl  
lmjvq+JVJ60emyzSrM/tU6/pWrr59SuMN2YuSLU9WgMOFn5q3kMzF0Puht0Vg299  
Uv7UOMhzgJgJIPcZIjfSKULD++vINonnMSEKg5mxEr9YXKHx+wxnYG+1quullwif  
bhxPZFpeNaaovzgGDTIEvAAih04pgoG+4CYbGsN5FtcIbaz6AsON3UruY8fKOftQ  
ZvwzwteOFc6D90ERu/x+NArx9tNhiwjxtFs2gBPOXQ4dDkJZI8NVygbuRh0aqmr9  
lxiFlQqTTXBcwhbCTv7LXYBcGesqpKIaYWMSiWf6s5Vv9qcUOiXKsn7tDJyZUmj3  
0AO6/S5CZZ/i6ziBtUIh5oH4wjcBSNzOzZX6fmDrgq7DSzPeZ/q2BIA13z7bq4w6  
POPMaCsSA/wNotnxlvR3voUDxBAlZ8QgrEt435AmV0nOvncdMgZYqhz18SPe/n7x  
tjBwSfYRzcTJm0oGk5WgDcMofLsQELk4iliqJDL2Td4havr4O+Om0xDQ9oxIX1s5  
GdQ+dHc8Qp0QCCAn74DoI+yz0xLubAFWUF+wKiaVaDAdAe0JWJX4kqaL/I3NqRpO  
gWZDffXyPHnvcEpsOIU7g1q7Mo7ufuFAvKT17CEXSkvJbL4J2JKkxnJWGBWgkVj6  
PdiJqkwxhgQmoq  
-----END PGP SIGNATURE-----  
--  
RHSA-announce mailing list  
RHSA-announce@redhat.com  
https://listman.redhat.com/mailman/listinfo/rhsa-announce

Red Hat Security Advisory 2022-7171-01

Red Hat Security Advisory 2022-7192-01 - The device-mapper-multipath packages provide tools that use the device-mapper multipath kernel module to manage multipath devices. Issues addressed include a bypass vulnerability.

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

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

Synopsis:          Important: device-mapper-multipath security update  
Advisory ID:       RHSA-2022:7192-01  
Product:           Red Hat Enterprise Linux  
Advisory URL:      https://access.redhat.com/errata/RHSA-2022:7192  
Issue date:        2022-10-25  
CVE Names:         CVE-2022-41974  
====================================================================  
1. Summary:

An update for device-mapper-multipath is now available for Red Hat  
Enterprise Linux 8.

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

2. Relevant releases/architectures:

Red Hat CodeReady Linux Builder (v. 8) - aarch64, ppc64le, s390x, x86_64  
Red Hat Enterprise Linux BaseOS (v. 8) - aarch64, ppc64le, s390x, x86_64

3. Description:

The device-mapper-multipath packages provide tools that use the  
device-mapper multipath kernel module to manage multipath devices.

Security Fix(es):

* device-mapper-multipath: Authorization bypass, multipathd daemon listens  
for client connections on an abstract Unix socket (CVE-2022-41974)

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

4. Solution:

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

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

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

2133988 - CVE-2022-41974 device-mapper-multipath: Authorization bypass, multipathd daemon listens for client connections on an abstract Unix socket

6. Package List:

Red Hat Enterprise Linux BaseOS (v. 8):

Source:  
device-mapper-multipath-0.8.4-22.el8_6.2.src.rpm

aarch64:  
device-mapper-multipath-0.8.4-22.el8_6.2.aarch64.rpm  
device-mapper-multipath-debuginfo-0.8.4-22.el8_6.2.aarch64.rpm  
device-mapper-multipath-debugsource-0.8.4-22.el8_6.2.aarch64.rpm  
device-mapper-multipath-libs-0.8.4-22.el8_6.2.aarch64.rpm  
device-mapper-multipath-libs-debuginfo-0.8.4-22.el8_6.2.aarch64.rpm  
kpartx-0.8.4-22.el8_6.2.aarch64.rpm  
kpartx-debuginfo-0.8.4-22.el8_6.2.aarch64.rpm  
libdmmp-0.8.4-22.el8_6.2.aarch64.rpm  
libdmmp-debuginfo-0.8.4-22.el8_6.2.aarch64.rpm

ppc64le:  
device-mapper-multipath-0.8.4-22.el8_6.2.ppc64le.rpm  
device-mapper-multipath-debuginfo-0.8.4-22.el8_6.2.ppc64le.rpm  
device-mapper-multipath-debugsource-0.8.4-22.el8_6.2.ppc64le.rpm  
device-mapper-multipath-libs-0.8.4-22.el8_6.2.ppc64le.rpm  
device-mapper-multipath-libs-debuginfo-0.8.4-22.el8_6.2.ppc64le.rpm  
kpartx-0.8.4-22.el8_6.2.ppc64le.rpm  
kpartx-debuginfo-0.8.4-22.el8_6.2.ppc64le.rpm  
libdmmp-0.8.4-22.el8_6.2.ppc64le.rpm  
libdmmp-debuginfo-0.8.4-22.el8_6.2.ppc64le.rpm

s390x:  
device-mapper-multipath-0.8.4-22.el8_6.2.s390x.rpm  
device-mapper-multipath-debuginfo-0.8.4-22.el8_6.2.s390x.rpm  
device-mapper-multipath-debugsource-0.8.4-22.el8_6.2.s390x.rpm  
device-mapper-multipath-libs-0.8.4-22.el8_6.2.s390x.rpm  
device-mapper-multipath-libs-debuginfo-0.8.4-22.el8_6.2.s390x.rpm  
kpartx-0.8.4-22.el8_6.2.s390x.rpm  
kpartx-debuginfo-0.8.4-22.el8_6.2.s390x.rpm  
libdmmp-0.8.4-22.el8_6.2.s390x.rpm  
libdmmp-debuginfo-0.8.4-22.el8_6.2.s390x.rpm

x86_64:  
device-mapper-multipath-0.8.4-22.el8_6.2.x86_64.rpm  
device-mapper-multipath-debuginfo-0.8.4-22.el8_6.2.i686.rpm  
device-mapper-multipath-debuginfo-0.8.4-22.el8_6.2.x86_64.rpm  
device-mapper-multipath-debugsource-0.8.4-22.el8_6.2.i686.rpm  
device-mapper-multipath-debugsource-0.8.4-22.el8_6.2.x86_64.rpm  
device-mapper-multipath-libs-0.8.4-22.el8_6.2.i686.rpm  
device-mapper-multipath-libs-0.8.4-22.el8_6.2.x86_64.rpm  
device-mapper-multipath-libs-debuginfo-0.8.4-22.el8_6.2.i686.rpm  
device-mapper-multipath-libs-debuginfo-0.8.4-22.el8_6.2.x86_64.rpm  
kpartx-0.8.4-22.el8_6.2.x86_64.rpm  
kpartx-debuginfo-0.8.4-22.el8_6.2.i686.rpm  
kpartx-debuginfo-0.8.4-22.el8_6.2.x86_64.rpm  
libdmmp-0.8.4-22.el8_6.2.i686.rpm  
libdmmp-0.8.4-22.el8_6.2.x86_64.rpm  
libdmmp-debuginfo-0.8.4-22.el8_6.2.i686.rpm  
libdmmp-debuginfo-0.8.4-22.el8_6.2.x86_64.rpm

Red Hat CodeReady Linux Builder (v. 8):

aarch64:  
device-mapper-multipath-debuginfo-0.8.4-22.el8_6.2.aarch64.rpm  
device-mapper-multipath-debugsource-0.8.4-22.el8_6.2.aarch64.rpm  
device-mapper-multipath-devel-0.8.4-22.el8_6.2.aarch64.rpm  
device-mapper-multipath-libs-debuginfo-0.8.4-22.el8_6.2.aarch64.rpm  
kpartx-debuginfo-0.8.4-22.el8_6.2.aarch64.rpm  
libdmmp-debuginfo-0.8.4-22.el8_6.2.aarch64.rpm

ppc64le:  
device-mapper-multipath-debuginfo-0.8.4-22.el8_6.2.ppc64le.rpm  
device-mapper-multipath-debugsource-0.8.4-22.el8_6.2.ppc64le.rpm  
device-mapper-multipath-devel-0.8.4-22.el8_6.2.ppc64le.rpm  
device-mapper-multipath-libs-debuginfo-0.8.4-22.el8_6.2.ppc64le.rpm  
kpartx-debuginfo-0.8.4-22.el8_6.2.ppc64le.rpm  
libdmmp-debuginfo-0.8.4-22.el8_6.2.ppc64le.rpm

s390x:  
device-mapper-multipath-debuginfo-0.8.4-22.el8_6.2.s390x.rpm  
device-mapper-multipath-debugsource-0.8.4-22.el8_6.2.s390x.rpm  
device-mapper-multipath-devel-0.8.4-22.el8_6.2.s390x.rpm  
device-mapper-multipath-libs-debuginfo-0.8.4-22.el8_6.2.s390x.rpm  
kpartx-debuginfo-0.8.4-22.el8_6.2.s390x.rpm  
libdmmp-debuginfo-0.8.4-22.el8_6.2.s390x.rpm

x86_64:  
device-mapper-multipath-debuginfo-0.8.4-22.el8_6.2.i686.rpm  
device-mapper-multipath-debuginfo-0.8.4-22.el8_6.2.x86_64.rpm  
device-mapper-multipath-debugsource-0.8.4-22.el8_6.2.i686.rpm  
device-mapper-multipath-debugsource-0.8.4-22.el8_6.2.x86_64.rpm  
device-mapper-multipath-devel-0.8.4-22.el8_6.2.i686.rpm  
device-mapper-multipath-devel-0.8.4-22.el8_6.2.x86_64.rpm  
device-mapper-multipath-libs-debuginfo-0.8.4-22.el8_6.2.i686.rpm  
device-mapper-multipath-libs-debuginfo-0.8.4-22.el8_6.2.x86_64.rpm  
kpartx-debuginfo-0.8.4-22.el8_6.2.i686.rpm  
kpartx-debuginfo-0.8.4-22.el8_6.2.x86_64.rpm  
libdmmp-debuginfo-0.8.4-22.el8_6.2.i686.rpm  
libdmmp-debuginfo-0.8.4-22.el8_6.2.x86_64.rpm

These packages are GPG signed by Red Hat for security.  Our key and  
details on how to verify the signature are available from  
https://access.redhat.com/security/team/key/

7. References:

https://access.redhat.com/security/cve/CVE-2022-41974  
https://access.redhat.com/security/updates/classification/#important

8. Contact:

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

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

iQIVAwUBY1go0tzjgjWX9erEAQi1Vg/+Jqqq7oYlPu31HClxrkeh1hRVpKM4wtlL  
dhaxdCntvKop7SGOoivxAy8PwnvdeSS8792yx2UJoErMoDCMvks7wKszTiNsI1Yp  
xZdysfmVj78bnkyMfdYSm9Rqwl4I4bC2endGCz8efVREGAAHKIW/ly3rGqRZnNnG  
N1HMy4v+XSvFtGWX1TDyxLNPkxDDdEKVC/cvns+UDUnIRgQHuO3RJ36ZHnYlF8Ye  
HfDIxt1ux1fS8C5JcVBdsKj1pQ0oUs9qkUsW+qxunSTIaGgSQyT2/L8K3NzrcR5d  
ZZimoDWX65binEYUhvKGNChp3cV3lwEJogcGmyeMpP+bF6WsTMCYB3aYsIeDMB8i  
SBmzsJZlI1Eb1Xk69SNGk55MyURpK2+97op51OTdJlhqQnGxqX0UEDXWv7a1Yt4+  
pXNnEWXRDz621bkJKImYYocvsqeX3xwCFEBJuJphuqK0gtReZb1zWbjNQoh97/Vk  
enZoPwjJVakn228vjq19bcxqtAX6kKLe2aHX3PuX2Dz8v8D4qk4nHRao8mHPfkae  
jBr263ltp8DyKOkpuQM67y84xSpyaaYzgNjlSQcmAC9dNmaVOxB+3p7qINxDnj4e  
rMXIohPsciENFDLa7vFSKhC5bcYiMzd+xat75AuB2V5ExqJioh+GtVVlGNhy756m  
47fa2KnK5Ag=in8Z  
-----END PGP SIGNATURE-----  
--  
RHSA-announce mailing list  
RHSA-announce@redhat.com  
https://listman.redhat.com/mailman/listinfo/rhsa-announce

Tag

#mac