A SQL Injection vulnerability detected in Food Ordering System v1.0 allows attackers to run commands on the database by sending crafted SQL queries to the ID parameter.

A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?

CVE-2023-36968: GitHub - haxxorsid/food-ordering-system: Food or Item Order Management System

An issue was discovered in pdfcrack 0.17 thru 0.18, allows attackers to execute arbitrary code via a stack overflow in the MD5 function.

*   Summary
*   Files
*   Reviews
*   Support
*   Tickets ▾
    *   Bugs
    *   Support Requests
    *   Patches
    *   Feature Requests
*   News
*   Discussion

Menu ▾ ▴

**#12 stack-buffer-overflow**

Status: closed

Priority: 9

Updated: 2020-04-24

Created: 2020-02-29

Private: No

hi, i find a stack over-flow when to calculate md5 value.  
crashed datas can find in https://github.com/p1ay8y3ar/crashdatas/tree/master/padcrack/29022020  
here is ASAN says

freedom@ubuntu:~/Downloads/pdfcrack\-0.18$ ./pdfcrack \-l /home/freedom/Desktop/pdfcrack/pdfcrack\-0.17/o/crashes/id\\:000000\\,sig\\:06\\,src\\:000072\\,op\\:ext\_AO\\,pos\\:28
\=================================================================
\==5441\==ERROR: AddressSanitizer: stack\-buffer\-overflow on address 0x7ffe99b24673 at pc 0x55929a48d42c bp 0x7ffe99b24430 sp 0x7ffe99b24420
READ of size 1 at 0x7ffe99b24673 thread T0
    #0 0x55929a48d42b in md5 /home/freedom/Downloads/pdfcrack\-0.18/md5.c:79
    #1 0x55929a48da1c in md5\_50s /home/freedom/Downloads/pdfcrack\-0.18/md5.c:202
    #2 0x55929a48e445 in isUserPasswordRev3 /home/freedom/Downloads/pdfcrack\-0.18/pdfcrack.c:261
    #3 0x55929a494d3a in initPDFCrack /home/freedom/Downloads/pdfcrack\-0.18/pdfcrack.c:678
    #4 0x55929a477b4d in main /home/freedom/Downloads/pdfcrack\-0.18/main.c:304
    #5 0x7f5726b4d1e2 in \_\_libc\_start\_main (/lib/x86\_64\-linux\-gnu/libc.so.6+0x271e2)
    #6 0x55929a47909d in \_start (/home/freedom/Downloads/pdfcrack\-0.18/pdfcrack+0x809d)

Address 0x7ffe99b24673 is located in stack of thread T0 at offset 83 in frame
    #0 0x55929a48e26f in isUserPasswordRev3 /home/freedom/Downloads/pdfcrack\-0.18/pdfcrack.c:253

  This frame has 3 object(s):
    \[32, 48) 'test' (line 254)
    \[64, 80) 'enckey' (line 254) <== Memory access at offset 83 overflows this variable
    \[96, 112) 'tmpkey' (line 254)
HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork
      (longjmp and C++ exceptions \*are\* supported)
SUMMARY: AddressSanitizer: stack\-buffer\-overflow /home/freedom/Downloads/pdfcrack\-0.18/md5.c:79 in md5
Shadow bytes around the buggy address:
  0x10005335c870: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10005335c880: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10005335c890: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1
  0x10005335c8a0: f1 f1 00 00 00 00 00 00 00 00 f3 f3 f3 f3 00 00
  0x10005335c8b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
\=>0x10005335c8c0: 00 00 00 00 f1 f1 f1 f1 00 00 f2 f2 00 00\[f2\]f2
  0x10005335c8d0: 00 00 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00
  0x10005335c8e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1
  0x10005335c8f0: f1 f1 00 00 f2 f2 00 00 f3 f3 00 00 00 00 00 00
  0x10005335c900: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10005335c910: 00 00 00 00 00 00 f1 f1 f1 f1 01 f2 f8 f2 00 f2
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
  Shadow gap:              cc
\==5441\==ABORTING

**1 Attachments**

**Discussion**

Log in to post a comment.

CVE-2020-22336: pdfcrack / Bugs

SQL injection vulnerability in langchain v.0.0.64 allows a remote attacker to obtain sensitive information via the SQLDatabaseChain component.

Add validation controls to the SQL chain to mitigate SQL injection issues.  
Using sqlfluff to perform static analysis:

1.  Disallow non select statement (INSERT, DROP)
2.  Disallow wildcard select statement

Some dialects that are supported by langchain are not supported by sqlfluff. It is possible to disallow usage of such dialects as well.

Also fixed the SQL integration tests which were not working as expected

Fixes #5923

BTW, looks like there is a huge diff on poetry.lock which doesn't look OK to me, would appreciate any advice on how to resovle it (I was following the instructions found here https://github.com/hwchase17/langchain/blob/master/.github/CONTRIBUTING.md)

**Who can review?**

@hwchase17

CVE-2023-36189: Mitigate issue #5923 (Prompt injection -> SQL injection in SQLChain) by boazwasserman · Pull Request #6051 · hwchase17/langchain

Six months of honeypot data finds that 19% of traffic to sensors were malicious exploit attempts, and 95% of those attempts came from just three botnets.

Attackers quickly turn around real-world attacks using proof-of-concept code, taking only days to weeks to create workable exploits from published research, according to six months of data collected by researchers at Trustwave.

During the experiment, Trustwave deployed honeypots that mimicked five common enterprises appliances, finding that attackers began exploiting one vulnerability within six days of the release of proof-of-concept (PoC) code and another within 17 days. Overall, the researchers found that exploit scans, which include legitimate scanning of the Internet by security professionals as well as attackers, accounted for 25% of HTTP and HTTPS requests, while actual attacks accounted for 19% of traffic to the newly created servers. Nearly all the attacks came from three specific botnets: Mozi, Mirai, and Kinsing.

Companies should assume that attackers will be able to reverse engineer any patch and develop their own exploit, even without a proof of concept, says Ziv Mador, vice president of security research at Trustwave.

"It's essential to stay aware of the constant stream of newly discovered vulnerabilities, take proactive measures, and apply patches promptly to minimize the window of opportunity for threat actors," he says.

The research highlights not only that attackers are quickly using exploit code, but that attacks are quickly automated by plugging into existing botnet infrastructure. Of the 19% of traffic that attempted to exploit the researchers' honeypots, 73% came from the Mozi botnet, 14% from the Kinsing botnet, and 9% came from the Mirai botnet.

All three botnets tend to focus on Internet of Things (IoT) and edge devices, such as managed file servers, mail servers, network gateways, and industrial control systems that manage operational technology. Mozi, for example, is a peer-to-peer botnet that started by infecting network gateways and digital video recording devices, but evolved to exploit vulnerabilities in network gateway appliances. Recent updates to the Mirai botnet include the ability to exploit bugs in Tenda and Zyxel networking appliances.

Currently, Mozi is very aggressive in its efforts to find as many unprotected IoT devices as possible, says Allen West, a security researcher with Akamai.

"Security has historically not been as much of a priority on IoT devices, yet they make up a huge portion of the Internet landscape," he says. "If it can send traffic, it's good enough to be used as a bot. Attackers, most notably Mirai, have acknowledged this and built their entire operation around this idea."

**Grabbing Code on the Fly**

To conduct the research, cybersecurity experts at Trustwave SpiderLabs deployed honeypots in six different countries for five different devices — Fortra GoAnywhere MFT, Microsoft Exchange, Fortinet FortiNAC, Atlassian BitBucket, and F5 Big-IP — to emulate vulnerable enterprise networks. They collected data from more than 38,000 IP addresses, including at least 1,100 unique payloads, the researchers stated in their analysis.

The honeypots had some capability to interact with attackers, using a "medium-interaction honeypot," attempting to fool the intruders into believing that their exploit had worked. However, the honeypots did not extend the charade beyond that basic level. Following an exploit attempt, attackers typically run \_wget\_ or \_curl\_ to download the next stage of the attack, but rather than run the command, the honeypot merely attempted to download the next stage for analysis, says Trustwave's Mador.

"Our honeypots were configured as true vulnerable applications and that's how they appeared in services like Shodan," Mador says. "We successfully captured several Web shells, which are commonly used by individuals or groups involved in such activities, but due to the medium-interaction nature of our honeypot, we were unable to track the subsequent actions that attackers may have taken."

The honeypots detected an attack against Fortra GoAnywhere MFT, a managed file transfer service, in the US and UK that attempted to upload a previously unreported Web shell. The researchers also detected attacks that targeted a vulnerability in Fortinet FortiNAC appliance (CVE-2022-39952) within six days of PoC exploit code being released. Other attacks targeted Atlassian Bitbucket servers and F5 Big-IP devices.

**Should Every Company Have a Honeypot?**

While quickly patching edge and IoT devices should be a priority, organizations should also prioritize those devices for which PoC exploits have been released or are being attacked in the wild.

Nonetheless, Mador suggests that companies should consider deploying honeypots of their own.

"When existing security measures do not offer adequate visibility into these attacks, the deployment of a honeypot can be a valuable option to consider," he says. "Honeypots act as additional layers of defense, luring attackers and providing valuable insights into their tactics and techniques."

Botnets Send Exploits Within Days to Weeks After Published PoC

Email fraud is a confidence game that costs the economy billions. An effective defense takes technology and vigilance.

Last year the FBI registered over 21,000 complaints about business email fraud, with adjusted losses of over $2.7 billion. Today this line of attack shows no sign of slowing down. Business email compromise (BEC) techniques are increasingly sophisticated; cybercrime-as-a-service (CasS) has lowered the barrier to entry for threat actors while also making it easier to evade "impossible travel" alerts, among other safeguards. 

BEC is a confidence game. The technology aspects — links that download malware, take users to spoofed sites, or motivate a financial transaction — require social engineering to gain trust and motivate a click. 

What are threat actors looking for? Along with useful data like employee records, payroll information, and proprietary business records, BEC actors want to convince someone to fulfill a request for payment or funds transfer using messages that look legitimate, with logos and designs that are copies of the real thing. 

With BEC fast becoming a specialty of cybercriminals, security teams need to stay ahead of these evolving threats. Through a combination of technology, policy, and culture, enterprise security teams can help preempt attacks and mitigate the risks of email fraud. Let’s look at how BEC works, along with six key steps to mitigate the risk.

**As-a-Service Fuels BEC Growth**

Phishing-as-a-service providers make it easy for threat actors to produce effective, authentic-looking BEC campaigns without needing high-level tech skills of their own. Criminal platforms, such as BulletProftLink, go even further, selling templates, automated services, and even a hosting platform. This not only opens up BEC as an avenue to any criminal organization willing to pay, but it also accelerates the ramp-up time, making it fast and easy to launch new campaigns.

**Localizing the Threat**

Most importantly, in a new trend BEC threat actors are also purchasing residential IP addresses from residential IP services, enabling them to mask where their emails originate. Armed with localized address space to support their malicious activities (in addition to usernames and passwords), BEC attackers can obscure movements, circumvent "impossible travel" flags, and open a gateway to conduct further attacks. 

Impossible travel alerts indicate that a user account might be compromised. They flag physical restrictions that indicate a task is being performed in two locations, without the appropriate amount of time to travel from one location to the other. The specialization and consolidation of this sector of the cybercrime economy could escalate the use of residential IP addresses to evade detection.

**Defend Against BEC**

There are six key tips security teams can apply. Some can be implemented immediately, while others will require long-term thinking and reinforcement. 

*   **Inbox protection:** Configure mail systems to flag messages from outside of the enterprise. Enable alerts about unverified senders, and block senders who can’t be independently identified.

*   **Strong authentication:** Enabling multifactor authentication makes it harder for attackers to compromise user email.

*   **Secure email:** Cloud platforms with artificial intelligence and machine learning can provide enhanced protection, continuous updates, and centralized management of security policies.

*   **Identity and access management:** Control access to the organization's apps and data with zero trust and automated identity governance.

*   **Secure payments:** Replace emailed invoices with a system that authenticates payments and providers.

*   **Education and empowerment:** Regularly train and remind employees to think twice before clicking. Establish and enforce policies requiring employees to verify payment requests — not by clicking the link in the email, but with a phone call. Teach employees to take the initiative to stop BEC scams, and be sure to reinforce the consequences that a single mistake can cause.

Policy and governance are crucial to helping stop BEC. Security by default — for example, a domain-based message authentication, reporting, and conformance (DMARC) policy of "reject" — ensures that unauthenticated messages are rejected at the mail server. Updating policies for accounting, internal controls, payroll, and HR can help employees know how to handle inbound requests for access, money, or personal information, such as their Social Security numbers.

Thwarting BEC threat actors takes vigilance and an ongoing commitment. As their techniques get more sophisticated, their tricks become harder to spot. Putting the brakes on this con game takes the entire organization, from the C-suite and IT, compliance, and risk management teams to every business unit. Awareness, backed by policy and technology, is the crucial factor in a consistently strong defense.

6 Steps To Outsmart Business Email Compromise Scammers

Commercial spyware has become so notorious that international governments are taking notice and action against it, as evidenced by the Biden administration’s recent Executive Order on commercial spyware.

Thursday, July 6, 2023 08:07

Attackers have long used commercial products developed by legitimate companies to compromise targeted devices. These products are known as commercial spyware. Commercial spyware operations mainly target mobile platforms with zero- or one-click zero-day exploits to deliver spyware. This threat initially came to light with the leaks of HackingTeam back in 2015, but gained new notoriety with public reporting on the NSO Group, and, in the years that have followed, the landscape has exploded.

There are now numerous companies with similar offerings, like Intellexa, DSIRF, Variston IT, and the newly disclosed Quadream representing just a small subset — there are likely more that are operating covertly today.

Commercial spyware has become so notorious that international governments are taking notice and action against it, as evidenced by the Biden administration’s recent Executive Order on commercial spyware. A recent report from the United Kingdom’s National CyberSecurity Center (NCSC) highlights the accessibility of these tools “lowers the barrier to entry to state and non-state actors in obtaining capability and intelligence.” As recently as June 2023, the European Parliament’s plenary session voted on an ongoing investigation concerning the illicit usage of NSO’s Pegasus and equivalent surveillance spyware by EU member states (PEGA report). In this session, European Parliament members argued that the illicit usage of spyware has put “democracy itself at stake” and called for legislative changes and stricter regulation of the use of commercial spyware. The full press release and report can be found here.

**Commercial spyware companies don't care who is targeted by their products**

Commercial spyware companies advertise their products simply as a means of obtaining access and deny having any knowledge of who their customers’ targets are. This tactic is possibly a means of plausible deniability in the event that illegal targeting of individuals is traced back to their spyware. To avoid legal repercussions, these companies have headquarters in countries that do not have laws governing the export of their products or which classify the entities as IT service providers, effectively removing them from any product liability. These companies can therefore ultimately sell to whomever can pay without regard for who the intended targets are or what the impacts on the victims might be.

Although advertised as “tools” for law enforcement and government agencies strictly intended for legal use, report after report has shown commercial spyware has consistently been used against ethically questionable targets that don't fit the profile of criminals or terrorists. Such targets have repeatedly been journalists, politicians and activists who the host government perceives as competitors or existential threats. While these technologies may exist to fight terrorism and organized crime, their sale and usage must be regulated and subject to scrutiny by judicial authorities at an international level to prevent their misuse and abuse.  

One such example of limited repercussions within a host state is the case where a journalist in Greece was targeted with Predator Spyware, eventually leading to the resignation of Greece’s National Intelligence Service’s director in 2022 and the subsequent ban on the use of commercial spyware in Greece. Earlier in 2022, we also saw the departure of the NSO group’s CEO from the company amid widespread public outrage over the use of their spyware by Israeli Police forces.

**The untethered future of commercial spyware**

Mobile platform developers such as Google and Apple have repeatedly introduced and implemented protections and mitigations in their operating systems. However, commercial spyware providers often use zero-day, zero-click exploits to compromise victims’ mobile devices and are so confident in their ability to repeatedly compromise phones _without getting caught_ that, in some cases, they don't even deploy persistence mechanisms — a simple device reboot is enough to remove the implant from the device. However, a device reboot simply results in the commercial spyware outfit reinfecting the device using the zero-day, zero-click combination they had used during the initial compromise indicating the aggressive nature of these campaigns.

We see no indications that these commercial spyware offerings are slowing down. If anything, they are growing along with the constant availability of exploitable, unpatched/unknown vulnerabilities. Until the international community acts to regulate the technology, very little is going to change. When exposed by researchers, some of these companies just cease to exist. But in reality, they do not shut down, they just rebrand under a different name or merge with others sharing the technology they have produced. A typical example of such a case is the commercial spyware firm Cytrox, which was on the verge of disappearing, but was subsequently “rescued” and is now part of the Intellexa conglomerate.

Private and government organizations have taken steps to legally curb the use of commercial spyware, including attempts to hold them responsible for their actions in the past. Meta, formerly Facebook, is one of the first to move against commercial spyware companies by opening a lawsuit against the NSO Group for leveraging Meta-owned WhatsApp in their infection chain. The Biden administration has also taken an important step in fighting these companies with the Executive Order putting limitations on the U.S. government's ability to use commercial spyware to “discourage the improper use of commercial spyware; and encourage the development and implementation of responsible norms regarding the use of commercial spyware that are consistent with respect for the rule of law, human rights, and democratic norms and values.”

However, limited legal and legislative actions are yet to have an _immediate_ positive effect on curbing the use of commercial spyware. Despite these steps toward limiting the operations of these spyware companies, they are likely to keep operating in any region as long as it's financially and legally feasible. Increasing scrutiny with export regulations, criminal liability and fines may be a way forward towards ensuring that their activity does not go beyond the legitimate purposes they advertise.

**Risk profile**

For almost everyone on the planet, your Apple or Android phone’s built-in security features are more than sufficient to keep you protected. However, the commercial spyware industry has proven that it is easy to compromise targets if you have access to these products and the means to use them. We've seen numerous deeply concerning reports of people being compromised and are commonly met with the news that it was a journalist or dissident. The ability of these companies to repeatedly compromise devices, regardless of patch level, makes protection difficult.

For those that believe they are being or could be targeted by commercial spyware, rebooting the device before contacting a source or switching to lockdown mode might be the only options for the foreseeable future.

If you feel that you have been targeted by commercial spyware, there are also more generic habits that should be part of your daily routine:

*   Reboot your device regularly.
*   Use lockdown mode if your device is an iPhone.
*   Don’t click on links from dubious sources.
*   Don’t accept private messages from unknown persons.
*   If you have to keep a public contact, use an empty device to receive such contacts and reset it frequently.
*   Keep your devices up-to-date.

_If readers suspect their system(s) may have been compromised by commercial spyware or hack-for-hire groups, please consider notifying Talos’ research team at talos-mercenary-spyware-help@external.cisco.com to assist in furthering the community’s knowledge of these threats._

The growth of commercial spyware based intelligence providers without legal or ethical supervision

Gcore Radar is a quarterly report prepared by Gcore that provides insights into the current state of the DDoS protection market and cybersecurity trends. This report offers you an understanding of the evolving threat landscape and highlights the measures required to protect against attacks effectively. It serves as an insight for businesses and individuals seeking to stay informed about the

Gcore Radar is a quarterly report prepared by Gcore that provides insights into the current state of the DDoS protection market and cybersecurity trends. This report offers you an understanding of the evolving threat landscape and highlights the measures required to protect against attacks effectively. It serves as an insight for businesses and individuals seeking to stay informed about the latest developments in cybersecurity.

As we entered 2023, the cybersecurity landscape witnessed an increase in sophisticated, high-volume attacks. Here, we present the current state of the DDoS protection market based on Gcore's statistics.

**Key Highlights from Q1–Q2**

*   The maximum attack power rose from 600 to 800 Gbps.
*   UDP flood attacks were most common and amounted to 52% of total attacks, while SYN flood accounted for 24%. In third place was TCP flood.
*   The most-attacked business sectors are gaming, telecom, and financial.
*   The longest attack duration in the year's first half was seven days, 16 hours, and 22 minutes.
*   Most attacks lasted less than four hours.

**High-Volume Attacks: An Escalating Threat**

There has been a significant increase in the power and volume of DDoS attacks over the last two years:

*   In 2021, the capacity of DDoS attacks was up to 300 Gbps.
*   In 2022, the attack capacity was about 650 Gbps.
*   In Q1–Q2 of 2023, we see a capacity of about 800 Gbps.

Figure 1. Attack intrensity 2021–2023, Gbps

Alt Text: Illustration of attack raising from 300 Gbps in 2021 and 650 Gbps in 2021 to 800 Gbps in 2023

The alarming 50–100% annual increase in DDoS attack volume highlights the growing sophistication of cyber attackers and their utilization of increasingly powerful tools. This means that businesses need to invest in DDoS mitigation strategies and solutions to protect their networks, systems, and customer data. Failure to address these evolving threats can result in costly disruptions, reputational damage, loss of customer trust, and security breaches.

**DDoS Attack Techniques**

According to Gcore's statistics, in Q1–Q2 of 2023:

*   UDP flood became more popular among attackers and is the most common method
*   SYN flood is in second place
*   In third place is TCP flood
*   All other techniques combined accounted for just 5% of attack types

Figure 2. Attack type spread, Q1–Q2 2023

Alt Text: Attack types illustrated: 52% - UDP, 24% - SYN flood, 19% - TCP flood, 5% - other traffic

According to Andrey Slastenov, Head of **Web Security at Gcore**, there has been an increase in the frequency of complex, multi-vector attacks by attackers. Attackers are now employing adaptive strategies, such as combining high-volume UDP attacks with a massive number of TCP packets, and shifting from targeting the application layer with a large amount of traffic to using a high volume of small packets. These changes in tactics indicate a deliberate effort to intensify the DDoS assault by overwhelming the network infrastructure and potentially bypassing mitigation measures. The ultimate goal is to maximize the impact of the attack and disrupt services.

**DDoS Attacks by Business Sector**

DDoS attacks across different business sectors have revealed specific trends and impacts. According to Gcore's report, gaming, telecom, and financial industries were the most attacked sectors in Q1–Q2 of 2023.

Figure 3. Most attacked industries based on Gcore's statistics.

Alt Text: Attack types illustrated: 30.1% - Gaming, 24.7% - Telecom, 16.8% - Financial, 28.4% - Other

The **gaming industry** was the most targeted sector, accounting for a considerable proportion of the DDoS attacks. Gaming platforms, operating in real-time and catering to millions of active users, experience detrimental consequences from even short periods of downtime. Attackers aim to disrupt services, undermine player experiences, and potentially gain a competitive advantage. The financial implications are substantial, with gaming companies often incurring a cost of $25,000 to $40,000 per hour of downtime.

The **telecommunication sector** faces a significant volume of DDoS attacks, affecting internet service providers (ISPs) and other telecom services. These attacks can result in widespread internet outages, impacting not only the telecom companies themselves but also businesses and consumers relying on their services. The disruptive nature of such attacks on critical infrastructure can have far-reaching consequences, disrupting communications and various aspects of daily life and business operations for customers.

The **financial sector**, encompassing banks and financial technology (FinTech) companies, remains constantly threatened by DDoS attacks. The rise in digital banking and online financial services adoption has increased the potential for disruptive attacks that can bring financial operations to a complete halt.

**DDoS Protection from Gcore**

Gcore can protect you from DDoS attacks with protection against threats at L3, L4, and L7 wielding over 1 Tbps of filtering capacity. Its real-time traffic filtering selectively blocks malicious sessions, allowing normal business processes to continue during attacks. All Gcore DDoS Protection servers are equipped with high-performance 3rd generation Intel® Xeon® Scalable processors, enabling fast processing so we can respond to attacks as quickly as possible. Learn **how Gcore repelled** a 650 Gbps attack in January 2023.

Found this article interesting? Follow us on Twitter __ and LinkedIn to read more exclusive content we post.

Surviving the 800 Gbps Storm: Gain Insights from Gcore's 2023 DDoS Attack Statistics

Out-of-bounds Read in GitHub repository gpac/gpac prior to 2.2.2.

Expand Up

@@ -253,13 +253,15 @@ static char \*strtrim(char \*str)

  

GF\_Err vobsub\_read\_idx(FILE \*file, vobsub\_file \*vobsub, s32 \*version)

{

char strbuf\[256\];

char strbuf\[257\];

char \*str, \*pos, \*entry;

s32 line, id \=\-1, delay \= 0;

Bool error \= 0;

  

for (line \= 0; !error && gf\_fgets(strbuf, sizeof(strbuf), file); line++)

for (line \= 0; !error && gf\_fgets(strbuf, 256, file); line++)

{

//make sure we are null-terminated - cf #2520

strbuf\[256\]\=0;

str \= strtrim(strbuf);

  

if (line \== 0)

Expand Down

CVE-2023-3523: fixed #2520 · gpac/gpac@64201a2

Red Hat Security Advisory 2023-3915-01 - Red Hat OpenShift Container Platform is Red Hat's cloud computing Kubernetes application platform solution designed for on-premise or private cloud deployments. This advisory contains the container images for Red Hat OpenShift Container Platform 4.11.44.

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

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

Synopsis:          Important: OpenShift Container Platform 4.11.44 bug fix and security update  
Advisory ID:       RHSA-2023:3915-01  
Product:           Red Hat OpenShift Enterprise  
Advisory URL:      https://access.redhat.com/errata/RHSA-2023:3915  
Issue date:        2023-07-06  
CVE Names:         CVE-2022-2879 CVE-2022-2880 CVE-2022-2995   
                   CVE-2022-27664 CVE-2022-32149 CVE-2022-32190   
                   CVE-2022-41715 CVE-2023-1370 CVE-2023-3089   
                   CVE-2023-24329 CVE-2023-24540 CVE-2023-32067   
=====================================================================

1. Summary:

Red Hat OpenShift Container Platform release 4.11.44 is now available with  
updates to packages and images that fix several bugs and add enhancements.

This release includes a security update for Red Hat OpenShift Container  
Platform 4.11.

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. Description:

Red Hat OpenShift Container Platform is Red Hat's cloud computing  
Kubernetes application platform solution designed for on-premise or private  
cloud deployments.

This advisory contains the container images for Red Hat OpenShift Container  
Platform 4.11.44. See the following advisory for the RPM packages for this  
release:

https://access.redhat.com/errata/RHSA-2023:3914

Space precludes documenting all of the container images in this advisory.  
See the following Release Notes documentation, which will be updated  
shortly for this release, for details about these changes:

https://docs.openshift.com/container-platform/4.11/release_notes/ocp-4-11-release-notes.html

Security Fix(es):  
* golang: html/template: improper handling of JavaScript whitespace  
(CVE-2023-24540)

* openshift: OCP does not use FIPS-certified cryptography (CVE-2023-3089)

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.

All OpenShift Container Platform 4.11 users are advised to upgrade to these  
updated packages and images when they are available in the appropriate  
release channel. To check for available updates, use the OpenShift CLI (oc)  
or web console. Instructions for upgrading a cluster are available at  
https://docs.openshift.com/container-platform/4.11/updating/updating-cluster-cli.html

3. Solution:

For OpenShift Container Platform 4.11 see the following documentation,  
which will be updated shortly for this release, for important instructions  
on how to upgrade your cluster and fully apply this asynchronous errata  
update:

https://docs.openshift.com/container-platform/4.11/release_notes/ocp-4-11-release-notes.html

You may download the oc tool and use it to inspect release image metadata  
for x86_64, s390x, ppc64le, and aarch64 architectures. The image digests  
may be found at  
https://quay.io/repository/openshift-release-dev/ocp-release?tab=tags.

    The sha values for the release are

    (For x86_64 architecture)  
The image digest is  
sha256:52cbfbbeb9cc03b49c2788ac7333e63d3dae14673e01a9d8e59270f3a8390ed3

    (For s390x architecture)  
The image digest is  
sha256:8e25fe8123b744a1e7ae48b1d02cb989387168c6bc3eef8a47ee7ee13157c25f

    (For ppc64le architecture)  
The image digest is  
sha256:9d9ee02572038ccc4750e416c2acb4a222bfc4fcca63a3595ff63685304d0e53

    (For aarch64 architecture)  
The image digest is  
sha256:e26acde99c69074890e2eefc4ca89506e3dd7426c049a7ff02734cabfa3be42a

All OpenShift Container Platform 4.11 users are advised to upgrade to these  
updated packages and images when they are available in the appropriate  
release channel. To check for available updates, use the OpenShift CLI (oc)  
or web console. Instructions for upgrading a cluster are available at  
https://docs.openshift.com/container-platform/4.11/updating/updating-cluster-cli.html

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

2196027 - CVE-2023-24540 golang: html/template: improper handling of JavaScript whitespace  
2212085 - CVE-2023-3089 openshift: OCP & FIPS mode

5. JIRA issues fixed (https://issues.redhat.com/):

OCPBUGS-14004 - "pipelines-as-code-pipelinerun-go" configMap is not been used for the Go repository   
OCPBUGS-14355 - [4.11.z] [GCP] worker node with Sriov operator installed fails to come up online after reboot  
OCPBUGS-14413 - "Create" button inactive when creating application with "Import from Git" workflow  
OCPBUGS-14456 - CRL configmap is limited by 1MB max, not allowing for multiple public CRLS. (4.11)  
OCPBUGS-14457 - mtls CRL not working when using an intermediate CA (4.11)  
OCPBUGS-14654 - [4.11] IPI redfish installation fails on inspect for EthernetInterfaces  
OCPBUGS-14686 - Package openvswitch2.17 conflicts with openvswitch2.15 during the 4.12 to 4.13 upgrade of RHEL worker  
OCPBUGS-14746 - container_network* metrics stop reporting after container restart  
OCPBUGS-14931 - kuryr-controller crashes on KuryrPort cleanup when subport is already gone: Request requires an ID but none was found  
OCPBUGS-15150 - TestNewApp unit tests in oc are failing  
OCPBUGS-15151 - e2e-agnostic-ovn-cmd is permanently failing due to registry.centos.org  
OCPBUGS-15361 - Bump to kubernetes 1.24.15  
OCPBUGS-4812 -  oc new-app command using s2i with private Github repo (over SSH) fails using oc v4.10

6. References:

https://access.redhat.com/security/cve/CVE-2022-2879  
https://access.redhat.com/security/cve/CVE-2022-2880  
https://access.redhat.com/security/cve/CVE-2022-2995  
https://access.redhat.com/security/cve/CVE-2022-27664  
https://access.redhat.com/security/cve/CVE-2022-32149  
https://access.redhat.com/security/cve/CVE-2022-32190  
https://access.redhat.com/security/cve/CVE-2022-41715  
https://access.redhat.com/security/cve/CVE-2023-1370  
https://access.redhat.com/security/cve/CVE-2023-3089  
https://access.redhat.com/security/cve/CVE-2023-24329  
https://access.redhat.com/security/cve/CVE-2023-24540  
https://access.redhat.com/security/cve/CVE-2023-32067  
https://access.redhat.com/security/updates/classification/#important  
https://access.redhat.com/security/vulnerabilities/RHSB-2023-001

7. Contact:

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

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

iQIcBAEBCAAGBQJkpj2NAAoJENzjgjWX9erEfG8P/05BRiaqdCD1dgYerHwb64ms  
O9YCegBzmBdVkjzSCRiTU/x/Mn5PP69KMjMuxwusL1NKsp5eh8Z3hUtHCQUyOsyE  
zvQnO+ktOs0QYI7tzGd3Nj22o3xpJnXXbr+dGA+M97IXBA0Zb4xz3BlF11ahdPnR  
7jz1dhd3KBds/w/ebbtHdQspoyAWCRhB+/Mtz6bamJg4sGiqETlPsPD5Vp9+RgHC  
SFKc8+uPuGJy2vTdeo9O3rITFCbggT21zli7A9eGlS2/LgV+B/NbK7fdNzHsiHIg  
Xy4Dl6KFpGwuKjYsblsNNnViSmSRarJ4IurU4DzLeNyBFAoWpmdGjiOV3jM+9BYZ  
gKV3yzM5xkm9o1J3RC+b/TPZeWYHZn/OHdf7gfS1LmMmw48CV2sFWZb18w6U1kM3  
wvOEffOGIMoQLc3fTJ81nen44WrWUNRdUgOk6QQDiZh1LvhP7Oip9L5abSaufzKP  
lK1JP2M/Rf0chImpV6FhkVRcEpeg8mG1MyQDxdhCRJPAraF6UnxnsETIemII2Z3O  
VJe5/kB8gpZ/4GmLodoffidIeQqExcrQ5p4qM5pd7t2FiHOQ3D6RLpdm+zQfc2wC  
x44L9J7rlqI/sIBQ4JQ96Vx/COeimXGeUezFIhKroQALKBxEUBroCe3UcwjwzM6g  
MPz/sm7kFJXSbvGqi67w  
=AIL0  
-----END PGP SIGNATURE-----  
--  
RHSA-announce mailing list  
RHSA-announce@redhat.com  
https://listman.redhat.com/mailman/listinfo/rhsa-announce

Red Hat Security Advisory 2023-3915-01

Red Hat Security Advisory 2023-3914-01 - Red Hat OpenShift Container Platform is Red Hat's cloud computing Kubernetes application platform solution designed for on-premise or private cloud deployments. This advisory contains the RPM packages for Red Hat OpenShift Container Platform 4.11.44.

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

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

Synopsis:          Important: Red Hat OpenShift Enterprise security update  
Advisory ID:       RHSA-2023:3914-01  
Product:           Red Hat OpenShift Enterprise  
Advisory URL:      https://access.redhat.com/errata/RHSA-2023:3914  
Issue date:        2023-07-06  
CVE Names:         CVE-2022-23772 CVE-2022-24675 CVE-2022-28327   
                   CVE-2022-30629 CVE-2022-41717 CVE-2023-3089   
                   CVE-2023-24540   
=====================================================================

1. Summary:

Red Hat OpenShift Container Platform release 4.11.44 is now available with  
updates to packages and images that fix several bugs and add enhancements.

This release includes a security update for Red Hat OpenShift Container  
Platform 4.11.

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 OpenShift Container Platform 4.11 - aarch64, noarch, ppc64le, s390x, x86_64

3. Description:

Red Hat OpenShift Container Platform is Red Hat's cloud computing  
Kubernetes application platform solution designed for on-premise or private  
cloud deployments.

This advisory contains the RPM packages for Red Hat OpenShift Container  
Platform 4.11.44. See the following advisory for the container images for  
this release:

https://access.redhat.com/errata/RHSA-2023:3915

Security Fix(es):

* openshift: OCP & FIPS mode (CVE-2023-3089)

* golang: html/template: improper handling of JavaScript whitespace  
(CVE-2023-24540)

* golang: math/big: uncontrolled memory consumption due to an unhandled  
overflow via Rat.SetString (CVE-2022-23772)

* golang: encoding/pem: fix stack overflow in Decode (CVE-2022-24675)

* golang: crypto/elliptic: panic caused by oversized scalar  
(CVE-2022-28327)

* golang: net/http: excessive memory growth in a Go server accepting HTTP/2  
requests (CVE-2022-41717)

* golang: crypto/tls: session tickets lack random ticket_age_add  
(CVE-2022-30629)

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.

All OpenShift Container Platform 4.11 users are advised to upgrade to these  
updated packages and images when they are available in the appropriate  
release channel. To check for available updates, use the OpenShift CLI (oc)  
or web console. Instructions for upgrading a cluster are available at  
https://docs.openshift.com/container-platform/4.11/updating/updating-cluster-cli.html

4. Solution:

For OpenShift Container Platform 4.11 see the following documentation,  
which will be updated shortly for this release, for important instructions  
on how to upgrade your cluster and fully apply this asynchronous errata  
update:

https://docs.openshift.com/container-platform/4.11/release_notes/ocp-4-11-release-notes.html

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

2053532 - CVE-2022-23772 golang: math/big: uncontrolled memory consumption due to an unhandled overflow via Rat.SetString  
2077688 - CVE-2022-24675 golang: encoding/pem: fix stack overflow in Decode  
2077689 - CVE-2022-28327 golang: crypto/elliptic: panic caused by oversized scalar  
2092793 - CVE-2022-30629 golang: crypto/tls: session tickets lack random ticket_age_add  
2161274 - CVE-2022-41717 golang: net/http: excessive memory growth in a Go server accepting HTTP/2 requests  
2196027 - CVE-2023-24540 golang: html/template: improper handling of JavaScript whitespace  
2212085 - CVE-2023-3089 openshift: OCP & FIPS mode

6. Package List:

Red Hat OpenShift Container Platform 4.11:

Source:  
buildah-1.23.4-3.rhaos4.11.el8.src.rpm  
conmon-2.1.2-3.rhaos4.11.el8.src.rpm  
containernetworking-plugins-1.0.1-6.rhaos4.11.el8.src.rpm  
cri-o-1.24.6-2.rhaos4.11.git4bfe15a.el8.src.rpm  
openshift-4.11.0-202306260054.p0.g990d55b.assembly.stream.el8.src.rpm  
openshift-ansible-4.11.0-202306230041.p0.g0a466d7.assembly.stream.el8.src.rpm  
openshift-clients-4.11.0-202306231116.p0.g2ae2303.assembly.stream.el8.src.rpm  
openshift-kuryr-4.11.0-202306280915.p0.gc732699.assembly.stream.el8.src.rpm  
podman-4.0.2-7.rhaos4.11.el8.src.rpm  
runc-1.1.2-2.rhaos4.11.el8.src.rpm  
skopeo-1.5.2-4.rhaos4.11.el8.src.rpm

aarch64:  
buildah-1.23.4-3.rhaos4.11.el8.aarch64.rpm  
buildah-debuginfo-1.23.4-3.rhaos4.11.el8.aarch64.rpm  
buildah-debugsource-1.23.4-3.rhaos4.11.el8.aarch64.rpm  
buildah-tests-1.23.4-3.rhaos4.11.el8.aarch64.rpm  
buildah-tests-debuginfo-1.23.4-3.rhaos4.11.el8.aarch64.rpm  
conmon-2.1.2-3.rhaos4.11.el8.aarch64.rpm  
conmon-debuginfo-2.1.2-3.rhaos4.11.el8.aarch64.rpm  
conmon-debugsource-2.1.2-3.rhaos4.11.el8.aarch64.rpm  
containernetworking-plugins-1.0.1-6.rhaos4.11.el8.aarch64.rpm  
containernetworking-plugins-debuginfo-1.0.1-6.rhaos4.11.el8.aarch64.rpm  
containernetworking-plugins-debugsource-1.0.1-6.rhaos4.11.el8.aarch64.rpm  
cri-o-1.24.6-2.rhaos4.11.git4bfe15a.el8.aarch64.rpm  
cri-o-debuginfo-1.24.6-2.rhaos4.11.git4bfe15a.el8.aarch64.rpm  
cri-o-debugsource-1.24.6-2.rhaos4.11.git4bfe15a.el8.aarch64.rpm  
openshift-clients-4.11.0-202306231116.p0.g2ae2303.assembly.stream.el8.aarch64.rpm  
openshift-hyperkube-4.11.0-202306260054.p0.g990d55b.assembly.stream.el8.aarch64.rpm  
podman-4.0.2-7.rhaos4.11.el8.aarch64.rpm  
podman-catatonit-4.0.2-7.rhaos4.11.el8.aarch64.rpm  
podman-catatonit-debuginfo-4.0.2-7.rhaos4.11.el8.aarch64.rpm  
podman-debuginfo-4.0.2-7.rhaos4.11.el8.aarch64.rpm  
podman-debugsource-4.0.2-7.rhaos4.11.el8.aarch64.rpm  
podman-gvproxy-debuginfo-4.0.2-7.rhaos4.11.el8.aarch64.rpm  
podman-plugins-4.0.2-7.rhaos4.11.el8.aarch64.rpm  
podman-plugins-debuginfo-4.0.2-7.rhaos4.11.el8.aarch64.rpm  
podman-remote-4.0.2-7.rhaos4.11.el8.aarch64.rpm  
podman-remote-debuginfo-4.0.2-7.rhaos4.11.el8.aarch64.rpm  
podman-tests-4.0.2-7.rhaos4.11.el8.aarch64.rpm  
runc-1.1.2-2.rhaos4.11.el8.aarch64.rpm  
runc-debuginfo-1.1.2-2.rhaos4.11.el8.aarch64.rpm  
runc-debugsource-1.1.2-2.rhaos4.11.el8.aarch64.rpm  
skopeo-1.5.2-4.rhaos4.11.el8.aarch64.rpm  
skopeo-debuginfo-1.5.2-4.rhaos4.11.el8.aarch64.rpm  
skopeo-debugsource-1.5.2-4.rhaos4.11.el8.aarch64.rpm  
skopeo-tests-1.5.2-4.rhaos4.11.el8.aarch64.rpm

noarch:  
openshift-ansible-4.11.0-202306230041.p0.g0a466d7.assembly.stream.el8.noarch.rpm  
openshift-ansible-test-4.11.0-202306230041.p0.g0a466d7.assembly.stream.el8.noarch.rpm  
openshift-kuryr-cni-4.11.0-202306280915.p0.gc732699.assembly.stream.el8.noarch.rpm  
openshift-kuryr-common-4.11.0-202306280915.p0.gc732699.assembly.stream.el8.noarch.rpm  
openshift-kuryr-controller-4.11.0-202306280915.p0.gc732699.assembly.stream.el8.noarch.rpm  
podman-docker-4.0.2-7.rhaos4.11.el8.noarch.rpm  
python3-kuryr-kubernetes-4.11.0-202306280915.p0.gc732699.assembly.stream.el8.noarch.rpm

ppc64le:  
buildah-1.23.4-3.rhaos4.11.el8.ppc64le.rpm  
buildah-debuginfo-1.23.4-3.rhaos4.11.el8.ppc64le.rpm  
buildah-debugsource-1.23.4-3.rhaos4.11.el8.ppc64le.rpm  
buildah-tests-1.23.4-3.rhaos4.11.el8.ppc64le.rpm  
buildah-tests-debuginfo-1.23.4-3.rhaos4.11.el8.ppc64le.rpm  
conmon-2.1.2-3.rhaos4.11.el8.ppc64le.rpm  
conmon-debuginfo-2.1.2-3.rhaos4.11.el8.ppc64le.rpm  
conmon-debugsource-2.1.2-3.rhaos4.11.el8.ppc64le.rpm  
containernetworking-plugins-1.0.1-6.rhaos4.11.el8.ppc64le.rpm  
containernetworking-plugins-debuginfo-1.0.1-6.rhaos4.11.el8.ppc64le.rpm  
containernetworking-plugins-debugsource-1.0.1-6.rhaos4.11.el8.ppc64le.rpm  
cri-o-1.24.6-2.rhaos4.11.git4bfe15a.el8.ppc64le.rpm  
cri-o-debuginfo-1.24.6-2.rhaos4.11.git4bfe15a.el8.ppc64le.rpm  
cri-o-debugsource-1.24.6-2.rhaos4.11.git4bfe15a.el8.ppc64le.rpm  
openshift-clients-4.11.0-202306231116.p0.g2ae2303.assembly.stream.el8.ppc64le.rpm  
openshift-hyperkube-4.11.0-202306260054.p0.g990d55b.assembly.stream.el8.ppc64le.rpm  
podman-4.0.2-7.rhaos4.11.el8.ppc64le.rpm  
podman-catatonit-4.0.2-7.rhaos4.11.el8.ppc64le.rpm  
podman-catatonit-debuginfo-4.0.2-7.rhaos4.11.el8.ppc64le.rpm  
podman-debuginfo-4.0.2-7.rhaos4.11.el8.ppc64le.rpm  
podman-debugsource-4.0.2-7.rhaos4.11.el8.ppc64le.rpm  
podman-gvproxy-debuginfo-4.0.2-7.rhaos4.11.el8.ppc64le.rpm  
podman-plugins-4.0.2-7.rhaos4.11.el8.ppc64le.rpm  
podman-plugins-debuginfo-4.0.2-7.rhaos4.11.el8.ppc64le.rpm  
podman-remote-4.0.2-7.rhaos4.11.el8.ppc64le.rpm  
podman-remote-debuginfo-4.0.2-7.rhaos4.11.el8.ppc64le.rpm  
podman-tests-4.0.2-7.rhaos4.11.el8.ppc64le.rpm  
runc-1.1.2-2.rhaos4.11.el8.ppc64le.rpm  
runc-debuginfo-1.1.2-2.rhaos4.11.el8.ppc64le.rpm  
runc-debugsource-1.1.2-2.rhaos4.11.el8.ppc64le.rpm  
skopeo-1.5.2-4.rhaos4.11.el8.ppc64le.rpm  
skopeo-debuginfo-1.5.2-4.rhaos4.11.el8.ppc64le.rpm  
skopeo-debugsource-1.5.2-4.rhaos4.11.el8.ppc64le.rpm  
skopeo-tests-1.5.2-4.rhaos4.11.el8.ppc64le.rpm

s390x:  
buildah-1.23.4-3.rhaos4.11.el8.s390x.rpm  
buildah-debuginfo-1.23.4-3.rhaos4.11.el8.s390x.rpm  
buildah-debugsource-1.23.4-3.rhaos4.11.el8.s390x.rpm  
buildah-tests-1.23.4-3.rhaos4.11.el8.s390x.rpm  
buildah-tests-debuginfo-1.23.4-3.rhaos4.11.el8.s390x.rpm  
conmon-2.1.2-3.rhaos4.11.el8.s390x.rpm  
conmon-debuginfo-2.1.2-3.rhaos4.11.el8.s390x.rpm  
conmon-debugsource-2.1.2-3.rhaos4.11.el8.s390x.rpm  
containernetworking-plugins-1.0.1-6.rhaos4.11.el8.s390x.rpm  
containernetworking-plugins-debuginfo-1.0.1-6.rhaos4.11.el8.s390x.rpm  
containernetworking-plugins-debugsource-1.0.1-6.rhaos4.11.el8.s390x.rpm  
cri-o-1.24.6-2.rhaos4.11.git4bfe15a.el8.s390x.rpm  
cri-o-debuginfo-1.24.6-2.rhaos4.11.git4bfe15a.el8.s390x.rpm  
cri-o-debugsource-1.24.6-2.rhaos4.11.git4bfe15a.el8.s390x.rpm  
openshift-clients-4.11.0-202306231116.p0.g2ae2303.assembly.stream.el8.s390x.rpm  
openshift-hyperkube-4.11.0-202306260054.p0.g990d55b.assembly.stream.el8.s390x.rpm  
podman-4.0.2-7.rhaos4.11.el8.s390x.rpm  
podman-catatonit-4.0.2-7.rhaos4.11.el8.s390x.rpm  
podman-catatonit-debuginfo-4.0.2-7.rhaos4.11.el8.s390x.rpm  
podman-debuginfo-4.0.2-7.rhaos4.11.el8.s390x.rpm  
podman-debugsource-4.0.2-7.rhaos4.11.el8.s390x.rpm  
podman-gvproxy-debuginfo-4.0.2-7.rhaos4.11.el8.s390x.rpm  
podman-plugins-4.0.2-7.rhaos4.11.el8.s390x.rpm  
podman-plugins-debuginfo-4.0.2-7.rhaos4.11.el8.s390x.rpm  
podman-remote-4.0.2-7.rhaos4.11.el8.s390x.rpm  
podman-remote-debuginfo-4.0.2-7.rhaos4.11.el8.s390x.rpm  
podman-tests-4.0.2-7.rhaos4.11.el8.s390x.rpm  
runc-1.1.2-2.rhaos4.11.el8.s390x.rpm  
runc-debuginfo-1.1.2-2.rhaos4.11.el8.s390x.rpm  
runc-debugsource-1.1.2-2.rhaos4.11.el8.s390x.rpm  
skopeo-1.5.2-4.rhaos4.11.el8.s390x.rpm  
skopeo-debuginfo-1.5.2-4.rhaos4.11.el8.s390x.rpm  
skopeo-debugsource-1.5.2-4.rhaos4.11.el8.s390x.rpm  
skopeo-tests-1.5.2-4.rhaos4.11.el8.s390x.rpm

x86_64:  
buildah-1.23.4-3.rhaos4.11.el8.x86_64.rpm  
buildah-debuginfo-1.23.4-3.rhaos4.11.el8.x86_64.rpm  
buildah-debugsource-1.23.4-3.rhaos4.11.el8.x86_64.rpm  
buildah-tests-1.23.4-3.rhaos4.11.el8.x86_64.rpm  
buildah-tests-debuginfo-1.23.4-3.rhaos4.11.el8.x86_64.rpm  
conmon-2.1.2-3.rhaos4.11.el8.x86_64.rpm  
conmon-debuginfo-2.1.2-3.rhaos4.11.el8.x86_64.rpm  
conmon-debugsource-2.1.2-3.rhaos4.11.el8.x86_64.rpm  
containernetworking-plugins-1.0.1-6.rhaos4.11.el8.x86_64.rpm  
containernetworking-plugins-debuginfo-1.0.1-6.rhaos4.11.el8.x86_64.rpm  
containernetworking-plugins-debugsource-1.0.1-6.rhaos4.11.el8.x86_64.rpm  
cri-o-1.24.6-2.rhaos4.11.git4bfe15a.el8.x86_64.rpm  
cri-o-debuginfo-1.24.6-2.rhaos4.11.git4bfe15a.el8.x86_64.rpm  
cri-o-debugsource-1.24.6-2.rhaos4.11.git4bfe15a.el8.x86_64.rpm  
openshift-clients-4.11.0-202306231116.p0.g2ae2303.assembly.stream.el8.x86_64.rpm  
openshift-clients-redistributable-4.11.0-202306231116.p0.g2ae2303.assembly.stream.el8.x86_64.rpm  
openshift-hyperkube-4.11.0-202306260054.p0.g990d55b.assembly.stream.el8.x86_64.rpm  
podman-4.0.2-7.rhaos4.11.el8.x86_64.rpm  
podman-catatonit-4.0.2-7.rhaos4.11.el8.x86_64.rpm  
podman-catatonit-debuginfo-4.0.2-7.rhaos4.11.el8.x86_64.rpm  
podman-debuginfo-4.0.2-7.rhaos4.11.el8.x86_64.rpm  
podman-debugsource-4.0.2-7.rhaos4.11.el8.x86_64.rpm  
podman-gvproxy-debuginfo-4.0.2-7.rhaos4.11.el8.x86_64.rpm  
podman-plugins-4.0.2-7.rhaos4.11.el8.x86_64.rpm  
podman-plugins-debuginfo-4.0.2-7.rhaos4.11.el8.x86_64.rpm  
podman-remote-4.0.2-7.rhaos4.11.el8.x86_64.rpm  
podman-remote-debuginfo-4.0.2-7.rhaos4.11.el8.x86_64.rpm  
podman-tests-4.0.2-7.rhaos4.11.el8.x86_64.rpm  
runc-1.1.2-2.rhaos4.11.el8.x86_64.rpm  
runc-debuginfo-1.1.2-2.rhaos4.11.el8.x86_64.rpm  
runc-debugsource-1.1.2-2.rhaos4.11.el8.x86_64.rpm  
skopeo-1.5.2-4.rhaos4.11.el8.x86_64.rpm  
skopeo-debuginfo-1.5.2-4.rhaos4.11.el8.x86_64.rpm  
skopeo-debugsource-1.5.2-4.rhaos4.11.el8.x86_64.rpm  
skopeo-tests-1.5.2-4.rhaos4.11.el8.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-23772  
https://access.redhat.com/security/cve/CVE-2022-24675  
https://access.redhat.com/security/cve/CVE-2022-28327  
https://access.redhat.com/security/cve/CVE-2022-30629  
https://access.redhat.com/security/cve/CVE-2022-41717  
https://access.redhat.com/security/cve/CVE-2023-3089  
https://access.redhat.com/security/cve/CVE-2023-24540  
https://access.redhat.com/security/updates/classification/#important  
https://access.redhat.com/security/vulnerabilities/RHSB-2023-001

8. Contact:

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

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

iQIcBAEBCAAGBQJkpjt7AAoJENzjgjWX9erEnZsQAKRcM+y6BeZeJH1RawZcl0tP  
Cc7QM52GHXraQX4kFLN1kAUtJEkwcKRCJ6zCOf3R0wK/+BNvFI7FvxkH6bjCMGbx  
5HEuJH1ouaAeDFkBh7CdBedre3+xRmPFtI7T6DMDhvFbpBexb7IvZ3fEE5iNG96G  
ysop1HLVxnm6Nq/bohbzRiYZGhEhRSlh797gjnFuRvExaaNvxja5a2PIfEoG8EMB  
hR+Ow1Rvv5zpNPMYyoNZY4VCjXCkMc4laXUj9YNTmh2G9RM3XMH7fgJ7tdceOP/X  
0FHG9sz99ZYpPTUDvEgtzokxPfTfhTmSkU20iFC+SuNJRtZcX7W+HoCLabRl6VlQ  
ekpK2C0+sPxqy4U+y4Xwe8egibnXCPaKLTE/N1aoeZlClzHDbVJBr1T3IR5g8Lrj  
k9pcRXKbCb66frLfY2o4VqfxVor8VdmuLbrtCtyEe+D6Uh3PZ20ivoBqVb93hdLA  
ouBdFqCbsGe0DWg344jHBBJ9snL4AhmiiBC9gBDbhIUY7gOTn8epyCOKjurRaSLr  
rUeE81i9F1cvUncZN7Z7TTv6hWcv6tl973EgQJgxVP+jfGpPDFGoKvcEp8cCRtZd  
vf3KUFlIzucUSvvgDzmT3DuvDw8+3FOkPVHz/5WvK793YceK7CnX7pcvpdiJnxan  
rmvM20rgy7QP3CMlJ0dT  
=9l4S  
-----END PGP SIGNATURE-----  
--  
RHSA-announce mailing list  
RHSA-announce@redhat.com  
https://listman.redhat.com/mailman/listinfo/rhsa-announce

Tag

#git