On the eve of their federal criminal trial for allegedly stealing vast swaths of Internet addresses for use in large-scale email spam campaigns, three current or former executives at online advertising firm Adconion Direct have agreed to plead guilty to lesser misdemeanor charges of fraud and misrepresentation via email.

At the outset of their federal criminal trial for hijacking vast swaths of Internet addresses for use in large-scale email spam campaigns, three current or former executives at online advertising firm **Adconion Direct** (now **Amobee**) have pleaded guilty to lesser misdemeanor charges of fraud and misrepresentation via email.

In October 2018, prosecutors in the Southern District of California named four Adconion employees — **Jacob Bychak**, **Mark Manoogian**, **Petr Pacas**, and **Mohammed Abdul Qayyum** —  in a ten-count indictment (PDF) on felony charges of conspiracy, wire fraud, and electronic mail fraud.

The government alleged that between December 2010 and September 2014, the defendants engaged in a conspiracy to identify or pay to identify blocks of Internet Protocol (IP) addresses that were registered to others but which were otherwise inactive.

Prosecutors said the men also sent forged letters to an Internet hosting firm claiming they had been authorized by the registrants of the inactive IP addresses to use that space for their own purposes.

All four defendants pleaded not guilty when they were charged back in 2018, but this week Bychak, Manoogian and Qayyum each entered a plea deal.

“The defendants’ jobs with Adconion were to acquire fresh IP addresses and employ other measures to circumvent the spam filters,” reads a statement released today by the U.S. Attorney for the Southern District of California, which said the defendants would pay $100,000 in fines each and perform 100 hours of community service.

“To conceal Adconion’s ties to the stolen IP addresses and the spam sent from these IP addresses, the defendants used a host of DBAs, virtual addresses, and fake names provided by the company,” the statement continues. “While defendants touted ties to well-known name brands, the email marketing campaigns associated with the hijacked IP addresses included advertisements such as ‘BigBeautifulWomen,’ ‘iPhone4S Promos,’ and ‘LatinLove\[Cost-per-Click\].'”

None of the three plea agreements are currently available on PACER, the online federal court document clearinghouse. However, PACER does show that on June 7 — the same day the pleas were entered by the defendants —  the government submitted to the court a superseding set of just two misdemeanor charges (PDF) of fraud in connection with email.

Another document filed in the case says the fourth defendant — Pacas — accepted a deferred prosecution deal, which includes a probationary period and a required $50,000 “donation” to a federal “crime victims fund.”

There are fewer than four billion so-called “Internet Protocol version 4” or IPv4 addresses available for use, but the vast majority of them have already been allocated. The global dearth of available IP addresses has turned them into a commodity wherein each IP can fetch between $15-$25 on the open market.

This has led to boom times for those engaged in the acquisition and sale of IP address blocks, but it has likewise emboldened those who specialize in absconding with and spamming from dormant IP address blocks without permission from the rightful owners.

In May, prosecutors published information about the source of some IP address ranges from which the Adconion employees allegedly spammed. For example, the government found the men leased some of their IP address ranges from a Dutch company that’s been tied to a scandal involving more than four million addresses siphoned from the **African Network Information Centre** (AFRINIC), the nonprofit responsible for overseeing IP address allocation for African organizations.

In 2019, AFRINIC fired a top employee after it emerged that in 2013 he quietly commandeered millions of IPs from defunct African entities or from those that were long ago acquired by other firms, and then conspired to sell an estimated $50 million worth of the IPs to marketers based outside Africa.

“Exhibit A” in a recent government court filing shows that in 2013 Adconion leased more than 65,000 IP addresses from **Inspiring Networks**, a Dutch network services company. In 2020, Inspiring Networks and its director **Maikel Uerlings** were named in a dogged, multi-part investigation by South African news outlet **MyBroadband.co.za** and researcher Ron Guilmette as one of two major beneficiaries of the four million IP addresses looted from AFRINIC by its former employee.

Exhibit A, from a May 2022 filing by U.S. federal prosecutors.

The address block in the above image — 196.246.0.0/16 — was reportedly later reclaimed by AFRINIC following an investigation. Inspiring Networks has not responded to requests for comment.

Prosecutors allege the Adconion employees also obtained hijacked IP address blocks from **Daniel Dye**, another man tied to this case who was charged separately. For many years, Dye was a system administrator for **Optinrealbig**, a Colorado company that relentlessly pimped all manner of junk email, from mortgage leads and adult-related services to counterfeit products and Viagra. In 2018, Dye pleaded guilty to violations of the CAN-SPAM Act.

Optinrealbig’s CEO was the spam king Scott Richter, who changed the name of the company to Media Breakaway after being successfully sued for spamming by **AOL,** **Microsoft**, **MySpace**, and the New York Attorney General Office, among others. In 2008, this author penned a column for The Washington Post detailing how Media Breakaway had hijacked tens of thousands of IP addresses from a defunct San Francisco company for use in its spamming operations.

The last-minute plea deals by the Adconion employees were reminiscent of another recent federal criminal prosecution for IP address sleight-of-hand. In November 2021, the CEO of South Carolina technology firm **Micfo** pleaded guilty just two days into his trial, admitting 20 counts of wire fraud in connection with an elaborate network of phony companies set up to obtain more than 700,000 IPs from the **American Registry for Internet Numbers** (ARIN) — AFRINIC’s counterpart in North America.

Adconion was acquired in June 2014 by **Amobee**, a Redwood City, Calif. online ad platform that has catered to some of the world’s biggest brands. Amobee’s parent firm — Singapore-based communications giant Singtel — bought Amobee for $321 million in March 2012.

But as _Reuters_ reported in 2021, Amobee cost Singtel nearly twice as much in the last year alone — $589 million — in a “non-cash impairment charge” Singtel disclosed to investors. Marketing industry blog **Digiday.com** reported in February that Singtel was seeking to part ways with its ad tech subsidiary.

One final note about Amobee: In response to my 2019 story on the criminal charges against the Adconion executives, Amobee issued a statement saying “Amobee has fully cooperated with the government’s investigation of this 2017 matter which pertains to alleged activities that occurred years prior to Amobee’s acquisition of the company.”

Yet as the government’s indictment points out, the alleged hijacking activities took place up until September 2014, which was _after_ Amobee’s acquisition of Adconion Direct in June 2014. Also, the IP address ranges that the Adconion executives were prosecuted for hijacking were all related to incidents in 2013 and 2014, which is hardly “years prior to Amobee’s acquisition of the company.”

Amobee has not yet responded to requests for comment.

Adconion Execs Plead Guilty in Federal Anti-Spam Case

By Owais Sultan
If you own a WordPress website this article is for you because it addresses WordPress security and protection…
This is a post from HackRead.com Read the original post: How To Secure WordPress Website From Cyber Attacks?

****If you own a WordPress website this article is for you because it addresses WordPress security and protection against cyber attacks.****

WordPress is a widely used CMS (content management system), powering a significant proportion of all available websites. Unfortunately, it also attracts cyber criminals who take advantage of the platform’s security flaws.

It does not mean that WordPress’s security mechanism is ineffective. Security issues can also occur due to the absence of security measures from the users’ side such as outdated or malware-infected plugins. Therefore, it is crucial to take security measures before your WordPress website becomes a target of a malicious attack.

Although you can maintain network security while transferring files by understanding the TCP vs UDP comparison and selecting the best one for web security, some valuable yet small details might help you secure your website in the long run.

*   **What Is the Importance of WordPress Website Security?**

A hacked WordPress site can significantly harm your company’s income and credibility. Cybercriminals can access passwords and user information and even exploit the site to spread malware or harvest login credentials and banking card information. Therefore, providing a secure platform for your website’s users/visitors is a must.

Also, keeping a high-end website requires maintaining your WordPress website’s safety. Website security has a direct impact on search engine visibility. And the most straightforward strategy to improve your search ranking is to improve your security. Thus, the importance of WordPress website security cannot be denied whatsoever.

*   **Is WordPress a Safe Platform?**

If this question always pops up in your mind, you are not alone. It is one of the most frequently asked questions. And the answer to this question is “Yes, it is safe.” It is safe for the most part as long as you take all necessary security precautions seriously.

*   **Avoid “Admin” Username**

The disclosure of a username may not appear to be particularly harmful. Still, it might set off a chain reaction of security flaws that can lead to account identity theft, hijacking, or financial harm.

If you have named the site’s administrator as admin, it is recommended to change it because cyber criminals are good at exploiting platforms with default setups. They understand that “admin” is frequently used as an administrator account. They may exploit that username in a “brute force” attack. Avoid the “Admin” username and save your WordPress website from such attacks.

*   **WordPress Must Be Updated Regularly**

WordPress publishes software updates regularly to enhance security and speed. These upgrades also help in keeping your site safe from cyber attacks. The most straightforward approach to improving your WordPress website’s security is to update your WordPress version. 

To see if you own the most recent WordPress version, go to Dashboard, then click on Updates.

Stay updated on the release dates for new upgrades to guarantee that your site isn’t running an old WordPress version. Moreover, try to update the plugins and themes on your WordPress site. Older plugins and themes might cause conflicts with the newly updated WordPress software, resulting in problems and security vulnerabilities.

*   **Limit the Number of Log In Times**

Cybercriminals may try to guess your admin password via a brute force attack or use leaked credentials to log in to the site. You can reduce their chances of winning by limiting the number of times they can try to log in. As a result, if someone continuously enters the incorrect password, they will be blocked for hours, months, or even years depending on what options you select.

Thus, Limit Login Attempts is a plugin that you may use to secure your website. It works by allowing you to set up a significant number of wrong passwords that may be entered before the IP address of the person who entered the wrong password is locked out.

*    **All Hotlinking Should Be Disabled**

Rather than downloading the file, putting it on your server, and providing a correct citation. Hotlinking or Inline linking is a technique of linking to a file stored on another site. It is most commonly used for images, but it may also be used for videos, music files, flash animations, and other digital content.

If you want to keep your WordPress website secure, hotlinking should be disabled. Otherwise, you’ll notice slower loading times, the possibility of more server expenses, and an increased risk of being hacked.

Although there are several manual methods for avoiding hotlinking, the most straightforward solution is to use a WordPress security plugin. The All-in-One WP Security and Firewall plugin, for example, has built-in solutions for preventing all hotlinking.

*   **Use Two-Factor Authentication**

Two-factor authentication, often known as 2FA, dual-factor authentication, or two-step verification, is a security method in which users validate their identity using two independent authentication factors. This is another smart step to include in your security strategies.

The authentication can be a conventional password followed by a security question, a combination of letters, a hidden code, or the Google Authenticator application delivering a secret code to your phone. The person who has your phone may log in to your website. It is used to safeguard a user’s credentials and the information they have access to.

**Conclusion**

Malicious actors are continuously coming up with new ways to use a company’s online presence against them, while cyber security specialists are always coming up with new ways to resist them.

This is the never-ending cycle of cybersecurity, and we’re all trapped in its center. Your WordPress site is just like any other website on the internet when it comes to cyber-attacks. However, by following the above-recommended tips and hacks, you can secure your WordPress website from cyber criminals or at least reduce the risk of being attacked. 

**More WordPress Security News**

1.  7 Tips to Increase Your WordPress Security
2.  5 WordPress Security Solutions with Free SSL Certificates
3.  Critical WordPress plugin vulnerability allowed wiping databases
4.  Flaws in 2 famous WordPress plugins put millions of websites at risk
5.  WordPress security: Steps to assess employee before granting admin access

How To Secure WordPress Website From Cyber Attacks?

Humio for Falcon provides long-term, cost-effective data retention with powerful index-free search and analysis of enriched security telemetry across enterprise environments

**AUSTIN, Texas and RSA Conference 2022, SAN FRANCISCO – June 6, 2022 –** CrowdStrike (Nasdaq: CRWD), a leader in cloud-delivered protection of endpoints, cloud workloads, identity and data, today introduced Humio for Falcon, a new capability that extends data retention of CrowdStrike Falcon telemetry for up to one year or longer, enhancing threat analytics and threat hunting abilities for organizations while helping them meet compliance requirements.

Humio for Falcon brings together an industry-leading security platform in CrowdStrike Falcon, with the powerful search capabilities of CrowdStrike’s centralized logging offering, Humio. The new capability gives security teams the ability to store security and IT telemetry from the Falcon platform, which is enriched and contextualized across endpoints, workloads and identities to address the challenge of operationalizing the ever-growing volumes of data. Humio for Falcon helps security teams analyze and act on all data – both real-time and historical data – in their environment. With longer data retention due to advanced compression of ingested data, security teams can uncover and detect potential threats within their environments with deep, contextual analytics and sub-second search results at any scale through a modern, index-free architecture.

“While the data available to threat hunters and incident responders grows at an exponential rate, they are routinely forced to reduce the duration they can store this information,” said Michael Sentonas, chief technology officer at CrowdStrike. “Humio for Falcon solves this problem by delivering scalable and cost-effective data retention that enables threat hunters and incident responders to look back and see if and when an adversary was active in an IT environment and reconcile every system they touched. It’s truly a game-changer in the industry.”

Humio for Falcon provides:

*   **Threat hunting and troubleshooting at unprecedented scale:** By retaining Falcon data for extended periods of time, security teams can proactively search and uncover hidden threats in the environment with sub second speed, remove advanced persistent threats (APTs) by sifting through the data to detect irregularities that might suggest potential malicious behavior and better prioritize and address vulnerabilities before they can be weaponized.
*   **Longer data retention to help meet compliance requirements and reduced cost:** With scalable storage and advanced compression techniques, customers can store and manage Falcon data for one or multiple years, based on customer requirements. This wealth of real-time and historical data enables completeness and accuracy of investigation and analysis, resulting in faster threat remediation.
*   **New user interface (UI) dashboard visualization for fast and custom search:** Feature-rich query language and index-free searches allows security teams to run queries on Falcon data and get immediate answers. Get the ability to seamlessly ingest, aggregate and search through massive security and IT telemetry and gain valuable, contextual insights with sub-second latency searches for meeting real-world security requirements, including advanced threat and vulnerability investigations.

  
“With Humio for Falcon, we were able to save approximately $150,000 in the first year,” said Tom Sipes, director, IT security and compliance at Tuesday Morning. “Also, the ability to save data for an extended time period is critical. When we detect an indicator of compromise, we can go back in time and analyze the entire attack chain to accelerate investigations and pinpoint issues more quickly.”

**Additional Resources**

*   For more information on Humio for Falcon, please visit our blog.
*   To watch a Humio for Falcon demo, please visit this page.
*   Did you know? Humio can ingest over one petabyte of data per day. Humio was also named “Log Analytics Solution of the Year” by the Data Breakthrough Awards for 2022.

  
**About CrowdStrike**  
CrowdStrike (Nasdaq: CRWD), a global cybersecurity leader, has redefined modern security with one of the world’s most advanced cloud-native platforms for protecting critical areas of enterprise risk – endpoints and cloud workloads, identity and data.

Powered by the CrowdStrike Security Cloud and world-class AI, the CrowdStrike Falcon® platform leverages real-time indicators of attack, threat intelligence, evolving adversary tradecraft and enriched telemetry from across the enterprise to deliver hyper-accurate detections, automated protection and remediation, elite threat hunting and prioritized observability of vulnerabilities.

Purpose-built in the cloud with a single lightweight-agent architecture, the Falcon platform delivers rapid and scalable deployment, superior protection and performance, reduced complexity and immediate time-to-value.

CrowdStrike Introduces Humio for Falcon, Redefining Threat Hunting with Unparalleled Scale and Speed

There is an assertion failure in SingleComponentLSScan::ParseMCU in singlecomponentlsscan.cpp in libjpeg before 1.64 via an empty JPEG-LS scan.

    ─────────────────────────────────────────────────────────────────────────────────────
    pwndbg> bt
    #0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
    #1  0x00007ffff7053859 in __GI_abort () at abort.c:79
    #2  0x00007ffff7053729 in __assert_fail_base (fmt=0x7ffff71e9588 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x5555564a4120 <str> "lines > 0", file=0x5555564a4040 <str> "singlecomponentlsscan.cpp", line=100, function=<optimized out>) at assert.c:92
    #3  0x00007ffff7064fd6 in __GI___assert_fail (assertion=0x5555564a4120 <str> "lines > 0", file=0x5555564a4040 <str> "singlecomponentlsscan.cpp", line=100, function=0x5555564a4080 <__PRETTY_FUNCTION__._ZN21SingleComponentLSScan8ParseMCUEv> "virtual bool SingleComponentLSScan::ParseMCU()") at assert.c:101
    #4  0x00005555558189f0 in SingleComponentLSScan::ParseMCU (this=0x624000002120) at singlecomponentlsscan.cpp:100
    #5  0x000055555567a528 in JPEG::ReadInternal (this=<optimized out>, this@entry=0x61b000000098, tags=tags@entry=0x7fffffffd5a0) at jpeg.cpp:345
    #6  0x0000555555677709 in JPEG::Read (this=0x61b000000098, tags=0x7fffffffce10) at jpeg.cpp:210
    #7  0x000055555560ff53 in Reconstruct (infile=<optimized out>, outfile=<optimized out>, colortrafo=<optimized out>, alpha=<optimized out>, upsample=<optimized out>) at reconstruct.cpp:121
    #8  0x00005555555c350e in main (argc=<optimized out>, argv=<optimized out>) at main.cpp:747
    #9  0x00007ffff7055083 in __libc_start_main (main=0x5555555bafe0 <main(int, char**)>, argc=3, argv=0x7fffffffe318, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffe308) at ../csu/libc-start.c:308
    #10 0x00005555555b55ae in _start ()

CVE-2022-32978: Abort in SingleComponentLSScan::ParseMCU  · Issue #75 · thorfdbg/libjpeg

In 1985, a group of klezmer musicians from the US rendezvoused with underground dissidents in Tbilisi, Georgia. This is the story of how they pulled it off with homebrew cryptography.

RSA CONFERENCE 2022 — Not all activists carry a picket sign. Some carry a soprano saxophone and a music notebook.

"1985 was a really rough go of it for people who were human-rights activists," said Dr. Merryl Goldberg, music professor at California State University San Marcos, at a keynote at RSA Conference 2022 on Wednesday. "Dissidents, human rights activists, refuseniks, Helsinki Monitors had formed — in Tbilisi, Georgia, of all places — a group, a musical group, to band together, literally." This was the Phantom Orchestra, which she would travel across the world to meet.

Her own band was Klezmer Conservatory Band. Goldberg and bandmates Hankus Netsky, Rosalie Gerut, and Jeff Warschauer traveled together to the USSR, according to a 1986 article. Activist groups in the United States, particularly Action for Soviet Jewry, conceived their mission as a way to bring international notice to a group of dissidents who otherwise could be disposed of namelessly. If the world knows these people exist and are facing persecution, the thinking went, the Soviet government would not have as free a hand.

"That's when some people in Boston had the idea, 'Maybe we should go in and support them — but also find out if there was information that should come out as well,'" Goldberg said. So this group of four young musicians volunteered to take a trip to the Soviet Union, during the Cold War.

    

Dr. Merryl Goldberg (Source: RSA Conference screengrab)

Despite the cloak-and-dagger feel, this wasn't a spy mission. The information they were seeking to smuggle out was simple personal information like names, family relationships, and birth dates. The information simple but essential if a Soviet citizen wanted to get an invitation to travel outside the USSR — and from there defect.

"There were a couple of people who wanted to be invited, and so we coded all of their information in order to bring that out so they could receive an invitation," Goldberg said. "Most of the folks ended up emigrating, which is really good, but what they had to put up with in order to emigrate was really something."

Don't worry. This ties into cryptography.

**What Music Can Mean, Literally**

Because of the precarious position of the people Goldberg and her bandmates were hoping to meet, the Americans had to encode the contact information for the Georgian dissidents.

"We couldn't write down the names of people or their addresses or things like that because it would put them in jeopardy if at customs they saw that," she said. "And it would put us in jeopardy as well."

So she found a way to write things down without making them explicit: using musical notation as an alphabet, essentially. Goldberg didn't go into the details of her code, though she did lead the audience through the directions to a dissident's apartment, shown in the image above.

Britta Glade, senior director of content and curation for RSA Conference, interviewed Goldberg. "Let's jump into some of your coding," she said.

The first Phantom Orchestra members they were to meet were the Goldsteins, brothers Isai and Grigory. 

"You're seeing directions to get to one of the apartments. So we knew we had to go on the Orange line \[subway\], stop at the end, Cross Street — that's the name of the street," Goldberg explained. "On the bottom line, I couldn't figure out a way to write it out, so I actually drew where the apartment was in the building. That's what that is. There's a little tiny square in the top square, and that was where the apartment was."

For the more complex information, like names and other personal information, Goldberg had to come up with a flexible alphabet that couldn't be read at a glance. "What I did — without giving away the story of the whole code — is I just assigned certain notes to certain letters, and then I played around with some decoy stuff in terms of the clefs," she said.

Glade is also a musician — she played one of Goldberg's encoded songs on a keyboard set up on the stage. "There's a scientific, predictable way music is gonna sound," Glade said. "It's just like programming, right?" And this programming sounded ... kinda bad.

"If you study music, like modern music, you would hear music like this, perhaps," Goldberg said, laughing. "One of the cool things about music and coding is people invent notation anyway. And they write crazy things." That made it difficult for anyone to look at even that awkward sheet music and see any real grounds for suspicion.

**What Music Can Mean, Metaphorically**

As technologist Bruce Schneier said during his RSA keynote, any system can be a code. Goldberg used her system — music — to encode directions that helped her and her bandmates connect with musicians in the USSR and to bring home information that would allow some of those dissidents to emigrate. So for those refuseniks, music meant freedom.

"Before I met the people in the Phantom Orchestra, I understood the power of music – I'm a musician. I play, and when I play, I get into this other space," Goldberg said. "When we played with the Phantom Orchestra, the power of our playing together and the freedom in our brains was something that I'll never forget. It has become a part of me."

She had to choke back some emotion to say, "But while we're playing, I understood: You can be imprisoned, you can be put wherever, and ultimately we were interrogated many more times and put under arrest, \[but\] in your brain you can still feel free. And I hadn't understood that power of music until then."

Glade brought it back to cybersecurity. "We're constantly getting pounded, pounded, pounded – you're under attack from this, this is happening here – we need to be taken, transformed, put in a \[new\] place," she said. "What does music offer us?"

Goldberg answered.

"Music is used as a way to center and ground yourself. The act and the discipline to practicing music enables you to listen better," she said. "A lot of what you do, from my understanding, is really dealing with people and understanding people and how they make decisions. They do problem-solving, right? The arts, music, but also visual arts, teach you how to solve problems, how to work well with each other."

**'Long Shadows of the Cold War'**

The invasion of Ukraine is casting "some long shadows of the Cold War that are maybe bringing up some emotions," Glade said. "What's in your heart and your head?"

"I really admire the musicians and the activists who are in Ukraine, who stay — Denys \[Karachevtsev\], who's the cellist you've seen," she answered.

Glade added, "The little girl singing in the subway."

"Yes," Goldberg said. "I also think about Brittney Griner. And I think, 'I hope she can ... keep her brain free, even though she's not.' Because that makes such a difference."

"I really think about what's going on and how people are coping," she added.

Glade and Goldberg closed out with one good way to cope: a klezmer song called "Broyges Tantz" — Yiddish for "angry dance."

How 4 Young Musicians Hacked Sheet Music to Help Fight the Cold War

**What are Kubernetes Operators?**

A Kubernetes operator is a method of packaging, deploying and managing a Kubernetes application. A Kubernetes application is both deployed on Kubernetes and managed using the Kubernetes API. Operators automate the management of applications or service life cycles on behalf of a human operator, providing for the ability to automate at every level of the stack—from managing the parts that make up the platform all the way to applications that are provided as a managed service.

Engineering teams can use the power of Operators, which offer autonomous management by exposing configuration natively through Kubernetes objects, for quicker installation and more frequent, robust updates. In addition to the automation advantages of Operators for managing the platform, Red Hat OpenShift makes it easier to find, install and manage Operators running on clusters.

**Using Operators in Red Hat OpenShift**

OpenShift is an enterprise Kubernetes platform with full-stack automated operations to manage hybrid cloud deployments.

Included in Red Hat OpenShift is the embedded OperatorHub, a registry of operators from various software vendors and open source projects. Within the OperatorHub you can browse and install a library of operators that have been verified to work with Red Hat OpenShift and that have been packaged for easier lifecycle management. 

OpenShift offers two different systems to manage operators depending on their purpose:

*   **Platform Operators**, which are managed by the Cluster Version Operator (CVO), are installed by default to perform cluster functions.
    
*   **Add-on Operators**, which are managed by Operator Lifecycle Manager (OLM), can be made accessible for users to run in their applications.
    

Additionally, suitably privileged users can manage operators through other means such as using YAML files or helm charts.

**Why is security important to Operators?**

More engineering teams are moving toward using Operators to deploy in their production environments. While the full potential of Operators hasn’t yet been reached, it’s important to not lose sight of the benefits of building in more secure code and practices as early as possible in the development process. 

**Good security practices for Operators****Minimize cluster-scope and namespace-scope permissions**

There are two types of classification for Operators:

*   **Namespace-scoped** — Operator watches and manages resources within a namespace and requires permissions within these namespace to do so
    
    *   There are subtypes within this:
        
        *   in a single, prenamed namespace determined by the developer
            
        *   in a single namespace provided at installation time
            
        *   in multiple namespaces (e.g. using the MultiNamespace install mode type in the OperatorGroup)
            
*   **Cluster-scoped** — watches and manages resources across or all namespaces within a cluster and requires cluster-scoped permissions to achieve this
    

Generally speaking, following the Principle of Least Privilege (PoLP), you should restrict access as much as possible while still allowing your Operator to function. Permissions can be granted by creating role bindings and cluster role bindings that bind the Operator’s service account to the required roles and cluster roles. This can be achieved using  Operator Lifecycle Manager (OLM) bundle deployment architecture.

Apart from the Operator image itself, an Operator bundle is an OLM-prescribed format for holding metadata about an Operator. The metadata contains everything that Kubernetes needs to know in order to use the Operator — its custom resource definitions (CRDs), role-based access control (RBAC) roles and bindings required, dependency tree and other information as outlined in Deploying Operators with OLM bundles.

A benefit of using OLM is that it manages the permissions needed to install and run the Operator. OLM uses the cluster-admin role to do the installation and separates the install time requirements, for example the APIService and CustomResourceDefinition resources are always created by OLM using the cluster-admin role, thus reducing the overall permissions surface. 

Using OLM, cluster administrators can choose to specify a service account for an Operator group so that all Operators associated with the group are deployed and run with the privileges granted to the service account. A service account associated with an Operator group should never be granted privileges to write these resources. Any Operator tied to this Operator group is now confined to the permissions granted to the specified service account. If the Operator asks for permissions that are outside the scope of the service account, the install fails with appropriate errors.

**Reduce the usage of cluster-scope permissions**

The use of cluster-scoped Operators should be justified. If not necessary, the recommendation is to run namespaced-scoped Operators with the minimal permissions required.

Cluster-scoped Operators require access to resources across the entire cluster, including the control plane, using permissions obtained by using cluster roles and cluster role bindings.

Namespace-scoped Operators require access only to resources in single namespaces and these permissions can be obtained by using roles and role bindings. Exception to this is where a namespace-scoped operator must create a CustomResourceDefinition (CRD) which is a cluster-scoped resource.

If there are static cluster-scoped resources whose definition won’t change based on the inputs given to the Operators, you can move the creation of those resources to the Operator Lifecycle Manager (OLM) catalog. For example, you can move CRD creation from your Operator to OLM since it doesn’t change throughout the Operator’s lifecycle.

**RBAC permissions**

Both Kubernetes and OpenShift platforms offer authorization through role-based access control (RBAC). The security context is an essential element of pod and container definitions in Kubernetes. Note that this is different to the OpenShift security feature called security context constraint (SCC).

Kubernetes Operators also define permissions granted to the Operator, generally in a YAML definition called role.yaml. Roles are assigned at the namespace level, so any escalation of privilege is inherently limited by the namespace itself. However, ClusterRole needs to be checked more carefully because they apply cluster wide. 

One possible way that privileges could be escalated is if a non-privileged user (with system:authenticated role) gets access to the service account token used by the operator. A common way of reducing this risk is to deploy the Operator in a separate namespace from its Operands, in which the non-privileged user doesn’t have access to read secrets, or if deployed in a namespace shared with non-privileged users, those users should not have access to read secrets in that namespace. It is recommended that Operators are never deployed in a shared namespace, especially one that allows non-privileged users access.

We recommend that code reviews should include looking for RBAC roles that can leverage themselves to gain extra privileges. 

 Examples to watch out for:

*   The Bind verb can be applied to Roles or ClusterRoles and allows a principal to bypass a general restriction on (cluster)role binding creation, which stops users who can create role bindings from escalating their privileges by binding to high privilege roles like cluster admin. This restriction is described in the Kubernetes documentation: Restrictions on role binding creation or update.
    
*   Escalate rights on cluster roles: Escalate bypasses the Kubernetes RBAC check, which prevents users who are able to create roles or cluster roles from creating (or editing) these objects to have more rights than they do.
    
*   Multiple Roles should be described to reduce the scope of any actions needed for containers that the Operator may run on the cluster. For example, if you have a component that generates a TLS Secret upon startup, a Role that allows Create but not List on Secrets is more secure than using a single all-powerful Service Account.
    
*   If you grant cluster-admin, cluster-admin can itself update/alter SCCs.
    
*   If you have usage of a given SCC and also have "create pod" then you can create a new pod to grab the full extent of what the SCC will permit.
    
*   If you have RBAC that permits editing of RBAC you can edit your own limits.
    
    *   For example:
        

resources:
\- roles
\- rolebindings
verbs:
\- patch
\- create

Would potentially allow the operator to give unprivileged users permissions to access privileged namespaces by 'giving' them the roles when requested. (Note: by default Operators are limited to only granting permissions to others that it has itself).

**Avoid wildcards**

Instead of using the wildcard character in RBAC definitions as per the image below, it is good practice to explicitly list out each verb or resource. Each item in the list can then more easily be examined to confirm where and how the permissions are needed, or if they were accidentally grabbed as a convenience during earlier development.

For example, instead of using "\*" in the verbs section, you can list them out in full, such as: get, list, watch. If the operator knows the name of a resource it will edit, it can be limited to only get/edit and will frequently not need "list".

Being explicit with lists will also future-proof the permissions for if the "\*" changes to match additional items not currently present.

**Using RBAC to define and apply permissions**

The relationships between cluster roles, roles, cluster role bindings, role bindings, users, groups and service accounts are illustrated below.

_Figure 1: Default cluster roles_

**Descoped Operator**

Since operators are run with a service account in a namespace, anyone with the ability to create workloads in that namespace can escalate to the permissions of the operator. To address these concerns, a notion of scoping operators was introduced via the OperatorGroup object. An OperatorGroup would specify a set of namespaces within a cluster in which all operators installed would share the same scope. The Operator Lifecycle Manager (OLM) ensures that only one operator within a namespace owns a particular CRD to avoid collision problems.

The problem is that APIs in a cluster are cluster-scoped. They are visible via discovery to any user that wishes to see them. Even Operators that agree on a particular Group, Version, Kind (GVK) may have differences of opinion in how those objects should be admitted to a cluster, or how conversion between API versions should happen. This means that it increases the likelihood that more than one "opinion" about an API exists in the cluster.

The article Operator Descoping Plan describes this further.

**Pod and container securityContext and Security Context Constraints (SCCs)**

When trying to containerize third-party applications, it may sometimes be necessary to bend to the expectations of those applications and run as specific UIDs, perhaps even running as root. For Operators that are created to be container-native, you should never make any UID expectations, and accept the customary "billion+" high UID that the OpenShift cluster assigns to the namespace your operator runs in.

*   Set a numeric USER in the Containerfile to avoid defaulting to, or assuming the expected user may have uid=0
    
*   Use group id permissions to manage shared file permissions instead of user id.
    

Similarly, the usage of hostPath volumes allows files on the host node to be accessible from the container. If a container is insecurely configured and it is compromised, the attacker could try to attack the host and other containers running on the host.

For hostPath specifically:

*   Operators should never require host paths unless they comprise part of the control plane itself.
    

Other deployment recommendations:

*   **readOnlyRootFilesystem** -- set it to TRUE 
    
    *   Avoid writing any local files to the root filesystem. Use /tmp or an emptyDir instead. Pay attention to PID files, as well as any log output that isn’t going to STDOUT.
        
*   **runAsNonRoot** -- set to TRUE 
    
    *   This can be set in either the podSpec or containerSpec’s security context. By enabling this, the container will refuse to run if other circumstances indicate it might run with uid=0.
        
*   **automount service account token** -- set to FALSE
    
    *   By default, the service account token is mounted as a file within the container. Operators will generally have an SA that they require access to in order to function (hence, set this TRUE). However, any pods that the operator creates may benefit from the added protections of setting it false. 
        

OpenShift Security context constraints (SCC) are gatekeepers that will limit which pods can be admitted to the cluster. Since the Operator process also runs as a pod in a cluster, you can use the same concepts to enhance the security posture of your Operator container as well.

The Udica tool was created to simplify the creation of custom SELinux policies that can then be tied to custom SCCs.

**Continuous security scans**

Continuously scanning helps to identify vulnerabilities and pick up the latest security bug fixes in Go, Kubernetes and the Operator container’s base image.

For the container images that are running in OpenShift and are pulled from Red Hat Quay registries, you can use an Operator to list the vulnerabilities of those images. The Container Security Operator can be added to OpenShift to provide vulnerability reporting for images added to selected namespaces.

Container image scanning for Red Hat Quay is performed by the Clair security scanner. In Red Hat Quay, Clair can search for and report vulnerabilities in images built from RHEL, CentOS, Oracle, Alpine, Debian and Ubuntu operating system software.

**Deployment location **

Where should an Operator run? Depending on what it is, we would recommend the Operator runs in an appropriate location. For an Operator that comprises part of the control plane, it can be scheduled to run on control plane nodes using Tolerations.

Even if Operators and Operands are split between namespaces, because the Operator itself may have a highly privileged service account to perform its kube API interaction, if it runs on a worker node any compromise of that worker node may reveal the Service Account credentials. Separation of workloads by node, as well as by namespace, is therefore beneficial.

**Useful resources**

*   **Get the Kubernetes operators e-book**
    

**References**

*   What is a Kubernetes operator?
    
*   Operator Framework - Operator Best Practices
    
*   Community-operators Best Practice
    
*   HackMD - Decoped/Scoped Operator
    
*   With Kubernetes Operators comes great responsibility
    
*   Kubernetes Operators Best Practices
    
*   How to build security in kubernetes operators
    
*   Operators and Red Hat OpenShift Container Platform
    
*   Using Kubernetes Operators to Manage Let’s Encrypt SSL/TLS Certificates for Red Hat OpenShift Dedicated
    
*   Udica
    
*   A Guide to OpenShift and UIDs
    
*   Using RBAC to define and apply permissions
    
*   Namespace vs Cluster Scoped Operators
    
*   Thinking of building a Kubernetes operator? Here’s what you need to know

Kubernetes Operators: good security practices

The ITarian Endpoint Manage Communication Client, prior to version 6.43.41148.21120, is compiled using insecure OpenSSL settings. Due to this setting, a malicious actor with low privileges access to a system can escalate his privileges to SYSTEM abusing an insecure openssl.conf lookup.

CVE-2022-25153: Redirecting…

Red Hat Security Advisory 2022-4956-01 - Red Hat Advanced Cluster Management for Kubernetes 2.5.0 images Red Hat Advanced Cluster Management for Kubernetes provides the capabilities to address common challenges that administrators and site reliability engineers face as they work across a range of public and private cloud environments. Clusters and applications are all visible and managed from a single console—with security policy built in. This advisory contains the container images for Red Hat Advanced Cluster Management for Kubernetes, which fix several bugs and security issues. Issues addressed include privilege escalation and traversal vulnerabilities.

Red Hat Security Advisory 2022-4956-01

Red Hat Security Advisory 2022-4940-01 - XZ Utils is an integrated collection of user-space file compression utilities based on the Lempel-Ziv-Markov chain algorithm, which performs lossless data compression. The algorithm provides a high compression ratio while keeping the decompression time short.

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

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

Synopsis:          Important: xz security update  
Advisory ID:       RHSA-2022:4940-01  
Product:           Red Hat Enterprise Linux  
Advisory URL:      https://access.redhat.com/errata/RHSA-2022:4940  
Issue date:        2022-06-08  
CVE Names:         CVE-2022-1271  
====================================================================  
1. Summary:

An update for xz is now available for Red Hat Enterprise Linux 9.

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 AppStream (v. 9) - aarch64, ppc64le, s390x, x86_64  
Red Hat Enterprise Linux BaseOS (v. 9) - aarch64, ppc64le, s390x, x86_64

3. Description:

XZ Utils is an integrated collection of user-space file compression  
utilities based on the Lempel-Ziv-Markov chain algorithm (LZMA), which  
performs lossless data compression. The algorithm provides a high  
compression ratio while keeping the decompression time short.

Security Fix(es):

* gzip: arbitrary-file-write vulnerability (CVE-2022-1271)

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/):

2073310 - CVE-2022-1271 gzip: arbitrary-file-write vulnerability

6. Package List:

Red Hat Enterprise Linux AppStream (v. 9):

aarch64:  
xz-debuginfo-5.2.5-8.el9_0.aarch64.rpm  
xz-debugsource-5.2.5-8.el9_0.aarch64.rpm  
xz-devel-5.2.5-8.el9_0.aarch64.rpm  
xz-libs-debuginfo-5.2.5-8.el9_0.aarch64.rpm  
xz-lzma-compat-5.2.5-8.el9_0.aarch64.rpm  
xz-lzma-compat-debuginfo-5.2.5-8.el9_0.aarch64.rpm

ppc64le:  
xz-debuginfo-5.2.5-8.el9_0.ppc64le.rpm  
xz-debugsource-5.2.5-8.el9_0.ppc64le.rpm  
xz-devel-5.2.5-8.el9_0.ppc64le.rpm  
xz-libs-debuginfo-5.2.5-8.el9_0.ppc64le.rpm  
xz-lzma-compat-5.2.5-8.el9_0.ppc64le.rpm  
xz-lzma-compat-debuginfo-5.2.5-8.el9_0.ppc64le.rpm

s390x:  
xz-debuginfo-5.2.5-8.el9_0.s390x.rpm  
xz-debugsource-5.2.5-8.el9_0.s390x.rpm  
xz-devel-5.2.5-8.el9_0.s390x.rpm  
xz-libs-debuginfo-5.2.5-8.el9_0.s390x.rpm  
xz-lzma-compat-5.2.5-8.el9_0.s390x.rpm  
xz-lzma-compat-debuginfo-5.2.5-8.el9_0.s390x.rpm

x86_64:  
xz-debuginfo-5.2.5-8.el9_0.i686.rpm  
xz-debuginfo-5.2.5-8.el9_0.x86_64.rpm  
xz-debugsource-5.2.5-8.el9_0.i686.rpm  
xz-debugsource-5.2.5-8.el9_0.x86_64.rpm  
xz-devel-5.2.5-8.el9_0.i686.rpm  
xz-devel-5.2.5-8.el9_0.x86_64.rpm  
xz-libs-debuginfo-5.2.5-8.el9_0.i686.rpm  
xz-libs-debuginfo-5.2.5-8.el9_0.x86_64.rpm  
xz-lzma-compat-5.2.5-8.el9_0.x86_64.rpm  
xz-lzma-compat-debuginfo-5.2.5-8.el9_0.i686.rpm  
xz-lzma-compat-debuginfo-5.2.5-8.el9_0.x86_64.rpm

Red Hat Enterprise Linux BaseOS (v. 9):

Source:  
xz-5.2.5-8.el9_0.src.rpm

aarch64:  
xz-5.2.5-8.el9_0.aarch64.rpm  
xz-debuginfo-5.2.5-8.el9_0.aarch64.rpm  
xz-debugsource-5.2.5-8.el9_0.aarch64.rpm  
xz-libs-5.2.5-8.el9_0.aarch64.rpm  
xz-libs-debuginfo-5.2.5-8.el9_0.aarch64.rpm  
xz-lzma-compat-debuginfo-5.2.5-8.el9_0.aarch64.rpm

ppc64le:  
xz-5.2.5-8.el9_0.ppc64le.rpm  
xz-debuginfo-5.2.5-8.el9_0.ppc64le.rpm  
xz-debugsource-5.2.5-8.el9_0.ppc64le.rpm  
xz-libs-5.2.5-8.el9_0.ppc64le.rpm  
xz-libs-debuginfo-5.2.5-8.el9_0.ppc64le.rpm  
xz-lzma-compat-debuginfo-5.2.5-8.el9_0.ppc64le.rpm

s390x:  
xz-5.2.5-8.el9_0.s390x.rpm  
xz-debuginfo-5.2.5-8.el9_0.s390x.rpm  
xz-debugsource-5.2.5-8.el9_0.s390x.rpm  
xz-libs-5.2.5-8.el9_0.s390x.rpm  
xz-libs-debuginfo-5.2.5-8.el9_0.s390x.rpm  
xz-lzma-compat-debuginfo-5.2.5-8.el9_0.s390x.rpm

x86_64:  
xz-5.2.5-8.el9_0.x86_64.rpm  
xz-debuginfo-5.2.5-8.el9_0.i686.rpm  
xz-debuginfo-5.2.5-8.el9_0.x86_64.rpm  
xz-debugsource-5.2.5-8.el9_0.i686.rpm  
xz-debugsource-5.2.5-8.el9_0.x86_64.rpm  
xz-libs-5.2.5-8.el9_0.i686.rpm  
xz-libs-5.2.5-8.el9_0.x86_64.rpm  
xz-libs-debuginfo-5.2.5-8.el9_0.i686.rpm  
xz-libs-debuginfo-5.2.5-8.el9_0.x86_64.rpm  
xz-lzma-compat-debuginfo-5.2.5-8.el9_0.i686.rpm  
xz-lzma-compat-debuginfo-5.2.5-8.el9_0.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-1271  
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

iQIVAwUBYqFNhtzjgjWX9erEAQgpJQ/+Kj5X+jS3d8o3bUTn8brYOQ73q/1va+12  
q2HiiR/GPF23kCKXgVEF6OS1BMz8yL1X9ztCTITRGw4jvnJIM7u1dP62QJFeJR07  
/Rm1MOMWHLLcWTJQyt/rCkoXAVltDTEK6jZnr2hLhloinJgDub1LJf5+vZEW7g/k  
ahh0brmBkAAZPodyYEMofASYneGzfAGpQl3WtHkCuGrU+8WPco9UFZnXf5ZIIXEB  
l+QsXTNUqLUwn8N74HFTosY2BahD6ASD3k6SN5Oaq/QmXm8ex3vddfrZ71hc8WWW  
7vDrVfauuniPsFoYkKjnDJ0OTmZafuIjt2O9A2HFD09NH0UazzlDQ+a03bNArGrP  
+nbjqgEIASP3FfSrKLnUyzJYYxPE/tSwa8iCNINV4MBJmNkvKygbhFko5sw4BYIV  
PBQO3tp+faKLQQdF49SzVTcGb8JJ+g2LJRU/FZ7iR9AEMi2QJiAdVlrRqo3eT4Z6  
4Z2gK4OLUDUhzJhHs1nJLIu2YdCrnA9p5k53xSlpLpDTZCGA4WZJmW7Amyw6b+Se  
6f0FLktCtkSqgNAFKRwAQLkbNz6XuNHpWLHPlgf25ITUG8zkrHFaPCpGJmVPZDHF  
bcOieis6IEQs/Im6byl86MY16zFvPiO7LM82saOiyfY70liNfTzGuUKQoDQZU8pE  
/ct9Y5zjEMQ=Kx+V  
-----END PGP SIGNATURE-----  
--  
RHSA-announce mailing list  
RHSA-announce@redhat.com  
https://listman.redhat.com/mailman/listinfo/rhsa-announce

Red Hat Security Advisory 2022-4940-01

Red Hat Security Advisory 2022-4941-01 - Subversion is a concurrent version control system which enables one or more users to collaborate in developing and maintaining a hierarchy of files and directories while keeping a history of all changes.

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

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

Synopsis:          Important: subversion:1.14 security update  
Advisory ID:       RHSA-2022:4941-01  
Product:           Red Hat Enterprise Linux  
Advisory URL:      https://access.redhat.com/errata/RHSA-2022:4941  
Issue date:        2022-06-08  
CVE Names:         CVE-2022-24070  
====================================================================  
1. Summary:

An update for the subversion:1.14 module 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 Enterprise Linux AppStream (v. 8) - aarch64, noarch, ppc64le, s390x, x86_64

3. Description:

Subversion (SVN) is a concurrent version control system which enables one  
or more users to collaborate in developing and maintaining a hierarchy of  
files and directories while keeping a history of all changes.

Security Fix(es):

* subversion: Subversion's mod_dav_svn is vulnerable to memory corruption  
(CVE-2022-24070)

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

After installing the updated packages, for the update to take effect, you  
must restart the httpd daemon, if you are using mod_dav_svn, and the  
svnserve daemon, if you are serving Subversion repositories via the svn://  
protocol.

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

2074772 - CVE-2022-24070 subversion: Subversion's mod_dav_svn is vulnerable to memory corruption

6. Package List:

Red Hat Enterprise Linux AppStream (v. 8):

Source:  
libserf-1.3.9-9.module+el8.4.0+8637+d3bad2c2.src.rpm  
subversion-1.14.1-2.module+el8.6.0+15201+2f551d15.src.rpm  
utf8proc-2.1.1-5.module+el8.4.0+8637+d3bad2c2.src.rpm

aarch64:  
libserf-1.3.9-9.module+el8.4.0+8637+d3bad2c2.aarch64.rpm  
libserf-debuginfo-1.3.9-9.module+el8.4.0+8637+d3bad2c2.aarch64.rpm  
libserf-debugsource-1.3.9-9.module+el8.4.0+8637+d3bad2c2.aarch64.rpm  
mod_dav_svn-1.14.1-2.module+el8.6.0+15201+2f551d15.aarch64.rpm  
mod_dav_svn-debuginfo-1.14.1-2.module+el8.6.0+15201+2f551d15.aarch64.rpm  
python3-subversion-1.14.1-2.module+el8.6.0+15201+2f551d15.aarch64.rpm  
python3-subversion-debuginfo-1.14.1-2.module+el8.6.0+15201+2f551d15.aarch64.rpm  
subversion-1.14.1-2.module+el8.6.0+15201+2f551d15.aarch64.rpm  
subversion-debuginfo-1.14.1-2.module+el8.6.0+15201+2f551d15.aarch64.rpm  
subversion-debugsource-1.14.1-2.module+el8.6.0+15201+2f551d15.aarch64.rpm  
subversion-devel-1.14.1-2.module+el8.6.0+15201+2f551d15.aarch64.rpm  
subversion-devel-debuginfo-1.14.1-2.module+el8.6.0+15201+2f551d15.aarch64.rpm  
subversion-gnome-1.14.1-2.module+el8.6.0+15201+2f551d15.aarch64.rpm  
subversion-gnome-debuginfo-1.14.1-2.module+el8.6.0+15201+2f551d15.aarch64.rpm  
subversion-libs-1.14.1-2.module+el8.6.0+15201+2f551d15.aarch64.rpm  
subversion-libs-debuginfo-1.14.1-2.module+el8.6.0+15201+2f551d15.aarch64.rpm  
subversion-perl-1.14.1-2.module+el8.6.0+15201+2f551d15.aarch64.rpm  
subversion-perl-debuginfo-1.14.1-2.module+el8.6.0+15201+2f551d15.aarch64.rpm  
subversion-tools-1.14.1-2.module+el8.6.0+15201+2f551d15.aarch64.rpm  
subversion-tools-debuginfo-1.14.1-2.module+el8.6.0+15201+2f551d15.aarch64.rpm  
utf8proc-2.1.1-5.module+el8.4.0+8637+d3bad2c2.aarch64.rpm  
utf8proc-debuginfo-2.1.1-5.module+el8.4.0+8637+d3bad2c2.aarch64.rpm  
utf8proc-debugsource-2.1.1-5.module+el8.4.0+8637+d3bad2c2.aarch64.rpm

noarch:  
subversion-javahl-1.14.1-2.module+el8.6.0+15201+2f551d15.noarch.rpm

ppc64le:  
libserf-1.3.9-9.module+el8.4.0+8637+d3bad2c2.ppc64le.rpm  
libserf-debuginfo-1.3.9-9.module+el8.4.0+8637+d3bad2c2.ppc64le.rpm  
libserf-debugsource-1.3.9-9.module+el8.4.0+8637+d3bad2c2.ppc64le.rpm  
mod_dav_svn-1.14.1-2.module+el8.6.0+15201+2f551d15.ppc64le.rpm  
mod_dav_svn-debuginfo-1.14.1-2.module+el8.6.0+15201+2f551d15.ppc64le.rpm  
python3-subversion-1.14.1-2.module+el8.6.0+15201+2f551d15.ppc64le.rpm  
python3-subversion-debuginfo-1.14.1-2.module+el8.6.0+15201+2f551d15.ppc64le.rpm  
subversion-1.14.1-2.module+el8.6.0+15201+2f551d15.ppc64le.rpm  
subversion-debuginfo-1.14.1-2.module+el8.6.0+15201+2f551d15.ppc64le.rpm  
subversion-debugsource-1.14.1-2.module+el8.6.0+15201+2f551d15.ppc64le.rpm  
subversion-devel-1.14.1-2.module+el8.6.0+15201+2f551d15.ppc64le.rpm  
subversion-devel-debuginfo-1.14.1-2.module+el8.6.0+15201+2f551d15.ppc64le.rpm  
subversion-gnome-1.14.1-2.module+el8.6.0+15201+2f551d15.ppc64le.rpm  
subversion-gnome-debuginfo-1.14.1-2.module+el8.6.0+15201+2f551d15.ppc64le.rpm  
subversion-libs-1.14.1-2.module+el8.6.0+15201+2f551d15.ppc64le.rpm  
subversion-libs-debuginfo-1.14.1-2.module+el8.6.0+15201+2f551d15.ppc64le.rpm  
subversion-perl-1.14.1-2.module+el8.6.0+15201+2f551d15.ppc64le.rpm  
subversion-perl-debuginfo-1.14.1-2.module+el8.6.0+15201+2f551d15.ppc64le.rpm  
subversion-tools-1.14.1-2.module+el8.6.0+15201+2f551d15.ppc64le.rpm  
subversion-tools-debuginfo-1.14.1-2.module+el8.6.0+15201+2f551d15.ppc64le.rpm  
utf8proc-2.1.1-5.module+el8.4.0+8637+d3bad2c2.ppc64le.rpm  
utf8proc-debuginfo-2.1.1-5.module+el8.4.0+8637+d3bad2c2.ppc64le.rpm  
utf8proc-debugsource-2.1.1-5.module+el8.4.0+8637+d3bad2c2.ppc64le.rpm

s390x:  
libserf-1.3.9-9.module+el8.4.0+8637+d3bad2c2.s390x.rpm  
libserf-debuginfo-1.3.9-9.module+el8.4.0+8637+d3bad2c2.s390x.rpm  
libserf-debugsource-1.3.9-9.module+el8.4.0+8637+d3bad2c2.s390x.rpm  
mod_dav_svn-1.14.1-2.module+el8.6.0+15201+2f551d15.s390x.rpm  
mod_dav_svn-debuginfo-1.14.1-2.module+el8.6.0+15201+2f551d15.s390x.rpm  
python3-subversion-1.14.1-2.module+el8.6.0+15201+2f551d15.s390x.rpm  
python3-subversion-debuginfo-1.14.1-2.module+el8.6.0+15201+2f551d15.s390x.rpm  
subversion-1.14.1-2.module+el8.6.0+15201+2f551d15.s390x.rpm  
subversion-debuginfo-1.14.1-2.module+el8.6.0+15201+2f551d15.s390x.rpm  
subversion-debugsource-1.14.1-2.module+el8.6.0+15201+2f551d15.s390x.rpm  
subversion-devel-1.14.1-2.module+el8.6.0+15201+2f551d15.s390x.rpm  
subversion-devel-debuginfo-1.14.1-2.module+el8.6.0+15201+2f551d15.s390x.rpm  
subversion-gnome-1.14.1-2.module+el8.6.0+15201+2f551d15.s390x.rpm  
subversion-gnome-debuginfo-1.14.1-2.module+el8.6.0+15201+2f551d15.s390x.rpm  
subversion-libs-1.14.1-2.module+el8.6.0+15201+2f551d15.s390x.rpm  
subversion-libs-debuginfo-1.14.1-2.module+el8.6.0+15201+2f551d15.s390x.rpm  
subversion-perl-1.14.1-2.module+el8.6.0+15201+2f551d15.s390x.rpm  
subversion-perl-debuginfo-1.14.1-2.module+el8.6.0+15201+2f551d15.s390x.rpm  
subversion-tools-1.14.1-2.module+el8.6.0+15201+2f551d15.s390x.rpm  
subversion-tools-debuginfo-1.14.1-2.module+el8.6.0+15201+2f551d15.s390x.rpm  
utf8proc-2.1.1-5.module+el8.4.0+8637+d3bad2c2.s390x.rpm  
utf8proc-debuginfo-2.1.1-5.module+el8.4.0+8637+d3bad2c2.s390x.rpm  
utf8proc-debugsource-2.1.1-5.module+el8.4.0+8637+d3bad2c2.s390x.rpm

x86_64:  
libserf-1.3.9-9.module+el8.4.0+8637+d3bad2c2.x86_64.rpm  
libserf-debuginfo-1.3.9-9.module+el8.4.0+8637+d3bad2c2.x86_64.rpm  
libserf-debugsource-1.3.9-9.module+el8.4.0+8637+d3bad2c2.x86_64.rpm  
mod_dav_svn-1.14.1-2.module+el8.6.0+15201+2f551d15.x86_64.rpm  
mod_dav_svn-debuginfo-1.14.1-2.module+el8.6.0+15201+2f551d15.x86_64.rpm  
python3-subversion-1.14.1-2.module+el8.6.0+15201+2f551d15.x86_64.rpm  
python3-subversion-debuginfo-1.14.1-2.module+el8.6.0+15201+2f551d15.x86_64.rpm  
subversion-1.14.1-2.module+el8.6.0+15201+2f551d15.x86_64.rpm  
subversion-debuginfo-1.14.1-2.module+el8.6.0+15201+2f551d15.x86_64.rpm  
subversion-debugsource-1.14.1-2.module+el8.6.0+15201+2f551d15.x86_64.rpm  
subversion-devel-1.14.1-2.module+el8.6.0+15201+2f551d15.x86_64.rpm  
subversion-devel-debuginfo-1.14.1-2.module+el8.6.0+15201+2f551d15.x86_64.rpm  
subversion-gnome-1.14.1-2.module+el8.6.0+15201+2f551d15.x86_64.rpm  
subversion-gnome-debuginfo-1.14.1-2.module+el8.6.0+15201+2f551d15.x86_64.rpm  
subversion-libs-1.14.1-2.module+el8.6.0+15201+2f551d15.x86_64.rpm  
subversion-libs-debuginfo-1.14.1-2.module+el8.6.0+15201+2f551d15.x86_64.rpm  
subversion-perl-1.14.1-2.module+el8.6.0+15201+2f551d15.x86_64.rpm  
subversion-perl-debuginfo-1.14.1-2.module+el8.6.0+15201+2f551d15.x86_64.rpm  
subversion-tools-1.14.1-2.module+el8.6.0+15201+2f551d15.x86_64.rpm  
subversion-tools-debuginfo-1.14.1-2.module+el8.6.0+15201+2f551d15.x86_64.rpm  
utf8proc-2.1.1-5.module+el8.4.0+8637+d3bad2c2.x86_64.rpm  
utf8proc-debuginfo-2.1.1-5.module+el8.4.0+8637+d3bad2c2.x86_64.rpm  
utf8proc-debugsource-2.1.1-5.module+el8.4.0+8637+d3bad2c2.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-24070  
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

iQIVAwUBYqFNgNzjgjWX9erEAQglLRAAhElOXc+ljmITXHpyhNWnjJwGub9BR/Vu  
K+RKTpb1wkXYY8SS++6uMVBDTra9B5rkrPoQWwUnvMmu2Oomtl8RPtOeovl2TbVH  
9AvBDFBAWU0DbGyVfXVP/StR769ZKWu+9tPgwB28aMiXhbpv3TWOVpy8gszNgrEM  
VBtgvCu4CWKt2FrCtb/Xd8fAROF/g0xxYhTHt3RCY8QbTxcvqvBIU0+JQOleuTtc  
7A3Jt0b1ou3aS7tsSlrVW/nuXHR/Re1SxtEl8Avxp2dz62WYJvef9o+Gas3eTmZi  
wHIRt2/UCL+hESNQXdSmA0sWS/e16y32ABFCO+sU1DUvrCPGxGXXnvAqwRxk4Clj  
cQkC3ZSFt5QKJeZMe7uk3vVXu9wb5V2KMYrlNiYgWNdPf2vEACXt694ika1cFAEW  
SV2ud4vSH7EjfpNQ61nVKK+cZ1bTWH0JKl4qWMYUJGYsxiAqnmjGcd9Y/o6bUqYh  
qW2i8aFjKgU63gdXg1S1dj3+wcdj0ZQO+K+ShMno9E/7ZW+FZlFVBcIT07cpOGH2  
CgH3M04sxxpRtDSDGEqWu7NKZ3QMpev2IJJHxlPiwg6E7dCn1xdQTGPRkTHQkQvc  
QgQfq1DITQ8dho/XzMD0yeAhClzXY1CdkpUiaHR3JE/1rF8yriHR/IEykRRBzEW3  
JP4YIal4KgI=qkZA  
-----END PGP SIGNATURE-----  
--  
RHSA-announce mailing list  
RHSA-announce@redhat.com  
https://listman.redhat.com/mailman/listinfo/rhsa-announce

Tag

#ssl