Single sign-on and request smuggling to the fore in another stellar year for web security research

Adam Bannister 10 February 2023 at 14:56 UTC  
Updated: 10 February 2023 at 16:10 UTC

Single sign-on and request smuggling to the fore in another stellar year for web security research

Detectify founder Frans Rosén has topped PortSwigger’s top 10 web hacking techniques of 2022 with ‘Account hijacking using dirty dancing in sign-in OAuth-flows’.

Published in July, the research was hailed as “a masterclass in chaining OAuth quirks with low-impact URL-leak gadgets including promiscuous postMessages, third-party XSS, and URL storage” by PortSwigger director of research James Kettle in a blog post announcing the results on Wednesday (February 8).

“Many of these bugs would previously have been dismissed as having no significant security impact, so they’ve had years to proliferate,” Kettle added.

DON’T MISS Top 10 web hacking techniques of 2022

The researcher praised Rosén for producing an “outstanding piece of research that we expect to yield fruit for years to come”.

Rosén told The Daily Swig: “I am really thankful and humble ending up on first place among so many great researchers and their awesome posts during the year.

“One thing that I did different this year was to start digging into a subject without even having a single bug to start with. It was only just an idea of a potential concept.

READ MORE ‘Dirty dancing’ in OAuth: Researcher discloses how cyber-attacks can lead to account hijacking

“Thanks again to PortSwigger for highlighting the people in the industry publicly disclosing their findings and methodologies – that’s in my opinion one of the best ways to move the industry forward.”

Rosén was declared the winner by a panel of his peers comprising Nicolas Grégoire, Soroush Dalili, Filedescriptor, and Kettle.

**A new frontier in HTTP request smuggling**

Kettle himself claimed silver medal for the second year in a row, as well as sixth place for separate, HTTP header injection research showcased at Black Hat USA (note: panellists could not vote for their own research).

After claiming second place in the 2021 rankings with ‘HTTP/2: The Sequel is Always Worse’, this time the researcher impressed by leveraging novel HTTP request smuggling vectors to compromise targets including Amazon and Apache “and ultimately taking the attack client-side into victim's browsers”.

RELATED Browser-Powered Desync Attacks: A New Frontier in HTTP Request Smuggling

Described as “seriously technically challenging” research, ‘Browser-Powered Desync Attacks’ prompted one judge to enthuse: “The creativity from desync worm (reminiscence of XSS worm) to client-side desync is off the chart”.

Kettle envisages request smuggling’s multi-year run of being a rich source of novel threats to continue until “until HTTP/1 has been fully stamped out”.

**Memcache injection and Zimbra**

In third place, Google’s Simon Scannell found a memcached injection vulnerability in business webmail platform Zimbra that allowed attackers to poison an unsuspecting victim’s cache and steal cleartext credentials.

READ MORE Business email platform Zimbra patches memcached injection flaw that imperils user credentials

Kettle said the research, which also deployed request smuggling, demonstrated the value of having “deep knowledge of a target”.

Scannell, then of Swiss outfit Sonar, wrote in his research: “By continuously injecting more responses than there are work items into the shared response streams of Memcached, we can force random Memcached lookups to use injected responses instead of the correct response.”

**‘Pushing at the boundaries’**

The 16th annual edition of PortSwigger’s top 10 web hacking techniques saw a record 46 nominations initially whittled down to 15 final-round candidates based on votes cast by the infosec community.

Kettle noted that “outright novel techniques and class-breaks have gotten rarer” but said more researchers were “pushing at the boundaries and sharing their findings than ever”.

Here’s the rest of the top 10 in brief (read James Kettle’s post for a deeper breakdown):

*   4\. ‘Hacking the Cloud with SAML’ by Felix Wilhelm culminates with an XML document leveraging an integer truncation bug to trigger arbitrary bytecode execution when Java attempts to verify its signature
*   5\. ‘Bypassing .NET Serialization Binders’ by Markus Wulftange resulted in vulnerabilities in DevExpress framework and Microsoft Exchange that opened the door to remote code execution
*   6\. ‘Making HTTP header injection critical via response queue poisoning’ by James Kettle explored “the long-forgotten response-splitting technique with a high-impact, high-payout case study”
*   7\. ‘Worldwide Server-side Cache Poisoning on All Akamai Edge Nodes’ by Jacopo Tediosi leveraged HTTP hop-by-hop headers to earn – with some triaging difficulty along the way – a raft of bug bounties
*   8\. ‘Psychic Signatures in Java’ by Neil Madden used the number 0 to forge ECDSA signatures and upend the cryptographic foundation of core web technologies such as JWT and SAML
*   9\. ‘Practical client-Side Path Traversal Attacks’ by Medi highlights a “visible” but neglected issue that should now be recognized “as a vulnerability in its own right”
*   10\. ‘Exploiting Web3’s Hidden Attack Surface: Universal XSS on Netlify's Next.js Library’ by Sam Curry compromises various cryptocurrency sites with XSS, SSRF, and cache poisoning originating from Netlify's Next.js library

PREVIOUS EDITION Dependency confusion tops the PortSwigger annual web hacking list for 2021

OAuth ‘masterclass’ crowned top web hacking technique of 2022

The ImageMagick Engine plugin for WordPress is vulnerable to deserialization of untrusted input via the 'cli_path' parameter in versions up to, and including 1.7.5. This makes it possible for unauthenticated users to call files using a PHAR wrapper, granted they can trick a site administrator into performing an action such as clicking on a link, that will deserialize and call arbitrary PHP Objects that can be used to perform a variety of malicious actions granted a POP chain is also present. It also requires that the attacker is successful in uploading a file with the serialized payload.

CVE-2022-3568: imagemagick-engine/imagemagick-engine.php at v.1.7.2 · orangelabweb/imagemagick-engine

A denial of service vulnerability present in ActiveRecord's PostgreSQL adapter <7.0.4.1 and <6.1.7.1. When a value outside the range for a 64bit signed integer is provided to the PostgreSQL connection adapter, it will treat the target column type as numeric. Comparing integer values against numeric values can result in a slow sequential scan resulting in potential Denial of Service.

**Overview**

Recently, when adding support to Sequel for automatically validating values of integer columns based on the underlying column type, I came across some unfortunate behavior in PostgreSQL. The unfortunate behavior comes from a combination of two features:

*   When using an integer value in an SQL query that is outside the range for a 64-bit signed integer type, PostgreSQL will treat the column type as numeric (since it is too large for bigint).
*   When doing a comparison between an integer or bigint value and a numeric value, PostgreSQL will implicitly cast the integer or bigint value to numeric, then do the comparison.

So if you have an integer or bigint column in your table named id, with a regular index, and you issue an SQL query such as SELECT * FROM table_name WHERE id = 9223372036854775808, PostgreSQL will not use any index on the table, because the index is on the value of the column, not the value of the column after it has been casted to numeric.

**Example of Issue**

Here's an example of the behavior. We first create a table with 1,000,000 rows, then create an index on it:

    CREATE TABLE a AS SELECT * FROM generate_series(1,1000000) AS a(id);
    CREATE INDEX ON a(id);
    

We can then check the query plan when using an integer inside the bigint range:

    EXPLAIN ANALYZE SELECT id FROM a WHERE id = 9223372036854775807;
                                                       QUERY PLAN
    -----------------------------------------------------------------------------------------------------------------
     Index Only Scan using a_id_idx on a  (cost=0.42..4.44 rows=1 width=4) (actual time=0.088..0.089 rows=0 loops=1)
       Index Cond: (id = '9223372036854775807'::bigint)
       Heap Fetches: 0
     Planning Time: 0.327 ms
     Execution Time: 0.117 ms
    

This is as expected, uses the index, and executes in well under a millisecond.

Next we can check the query plan when using an integer outside the bigint range:

    EXPLAIN ANALYZE SELECT id FROM a WHERE id = 9223372036854775808;
                                                         QUERY PLAN
    ---------------------------------------------------------------------------------------------------------------------
     Gather  (cost=1000.00..12175.00 rows=5000 width=4) (actual time=169.630..177.069 rows=0 loops=1)
      Workers Planned: 2
      Workers Launched: 2
      ->  Parallel Seq Scan on a  (cost=0.00..10675.00 rows=2083 width=4) (actual time=158.821..158.821 rows=0 loops=3)
            Filter: ((id)::numeric = '9223372036854775808'::numeric)
            Rows Removed by Filter: 333333
     Planning Time: 0.095 ms
     Execution Time: 177.091 ms
    

This is the unforunate behavior, showing a sequential scan with performance over 1000 times worse.

For large tables, forcing a sequential scan is very negative in terms of performance. If you have an application that will accept a user-supplied integer outside the bigint range, and will use the value directly in an SQL query on a large table, this is a potential denial of service vector.

**Mitigations**

There are a few ways to avoid this issue. One way is using bound variables. Another is raising an exception instead of running the query if the integer is outside the bigint range.

A third way is explicitly casting the value from numeric to integer or bigint depending on the integer value or expected type. You cannot always cast to bigint, as that will break code:

    
    SELECT '[1]'::jsonb - 1;
     ?column?
    ----------
     [1]
    (1 row)
    
    SELECT '[1]'::jsonb - 1::integer;
     ?column?
    ----------
     [1]
    (1 row)
    
    SELECT '[1]'::jsonb - 1::bigint;
    ERROR:  operator does not exist: jsonb - bigint
    LINE 1: SELECT '[1]'::jsonb - 1::bigint;
                                ^
    HINT:  No operator matches the given name and argument types. You might need to add explicit type casts.
    

Explicit casting based on the integer value is a fairly pointless mitigation, though, because you have to check the size of the value, and if the value is outside the bigint range, you might as well raise an exception first, instead of sending a query that you know the database return an error for. Explicit casting based on the expected type should be fine.

A fourth way is quoting the value, as if it were a string (e.g. SELECT * FROM t WHERE id = '9223372036854775808'). PostgreSQL treats the single quoted values as the unknown type, which get implicitly casted to the type of whatever it is compared against. If the value provided is outside of the range of that type, PostgreSQL will return an error. However, quoting integers can break code that depends on the implicit type:

    SELECT 1 + 1;
     ?column?
    ----------
            2
    (1 row)
    
    SELECT '1' + '1';
    ERROR:  operator is not unique: unknown + unknown
    LINE 1: SELECT '1' + '1';
                       ^
    HINT:  Could not choose a best candidate operator. You might need to add explicit type casts.
    

Worse, it can silently change the behavior of SQL queries:

    SELECT json_build_array(1);
     json_build_array
    ------------------
     [1]
    (1 row)
    
    SELECT json_build_array('1');
     json_build_array
    ------------------
     ["1"]
    (1 row)
    

For these reasons, I don't think it makes sense to explicitly cast based on the value or quote the values. Unless you are using bound variables, you should either explicitly check the values of integers before using the integers in SQL queries, or explicit cast to the expected type.

A fifth way would be creating an index on the integer column casted to numeric:

    CREATE INDEX ON a((id::numeric));
    

That's more of a workaround than a fix, and should only be used if you access to the database but no ability to fix the underlying code or SQL queries.

**Not a PostgreSQL Bug**

I reached out to the PostgreSQL developers regarding this issue and they informed me this is not a bug. They said this should be handled on the client side, best done using bound variables.

**Are You Affected?**

If you want to know whether you are affected by this issue, ask yourself the following four questions:

*   Am I using PostgreSQL?
*   Am I using a programming language that supports integers outside the bigint range (most dynamically typed programming languages will)?
*   Am I accepting integer values derived from user input, without validating whether they are in the bigint range?
*   Am I using the integer values literally in my queries, without quoting, explicit casting, or using bound variables?

If you answered yes to all four questions, you are probably vulnerable. If your programming language uses fixed sized integer types, you are probably not vulnerable, unless you are using an unsigned 64-bit type for an integer value that you'll be literalizing into an SQL query. If your application or database library is validating the integer values before using them, to make sure they are within the range of a signed 64-bit integer type, then you are probably not vulnerable. If you are quoting the integers, explicitly casting, or using bound variables, you are probably not vulnerable.

**Behavior of Other Numeric Type Comparisons on PostgreSQL**

Because PostgreSQL treats literal numbers with decimal points as numeric values, you can also force a sequential scan by using a number with a decimal point:

    EXPLAIN ANALYZE SELECT id FROM a WHERE id = 1.0;
                                                         QUERY PLAN
    ---------------------------------------------------------------------------------------------------------------------
     Gather  (cost=1000.00..12175.00 rows=5000 width=4) (actual time=0.239..169.829 rows=1 loops=1)
       Workers Planned: 2
       Workers Launched: 2
       ->  Parallel Seq Scan on a  (cost=0.00..10675.00 rows=2083 width=4) (actual time=98.581..152.694 rows=0 loops=3)
             Filter: ((id)::numeric = 1.0)
             Rows Removed by Filter: 333333
     Planning Time: 0.105 ms
     Execution Time: 169.858 ms
    

When performing a integer = double precision comparison, PostgreSQL will cast the integer to double precision. So this issue also affects queries that use double precision or real values.

When performing a double precision = integer or double precision = numeric comparison, PostgreSQL will cast the integer or numeric to double precision instead of the other way around. So you cannot force a sequential scan for real or double precision columns.

However, you can force a sequential scan for numeric columns, if the value is double precision or real:

    CREATE TABLE ns (id numeric);
    INSERT INTO ns SELECT id FROM a;
    CREATE INDEX ON ns(id);
    EXPLAIN ANALYZE SELECT id FROM ns WHERE id = 1.0::double precision;
                                                          QUERY PLAN
    ----------------------------------------------------------------------------------------------------------------------
     Gather  (cost=1000.00..12175.00 rows=5000 width=6) (actual time=225.169..233.160 rows=0 loops=1)
       Workers Planned: 2
       Workers Launched: 2
       ->  Parallel Seq Scan on ns  (cost=0.00..10675.00 rows=2083 width=6) (actual time=215.148..215.149 rows=0 loops=3)
             Filter: ((id)::double precision = '1'::double precision)
             Rows Removed by Filter: 333333
     Planning Time: 0.125 ms
     Execution Time: 233.183 ms
    

This isn't likely to be an issue in real code, since it can only be hit when you are manually casting the input to double precision. For safety, if you have to cast a floating point number, cast to numeric unless you are sure the underlying type uses double precision. Casting to numeric is safer because it will not cause a sequential scan for either numeric or double precision columns.

Queries similar to those in this section can also be a denial of service vector. If you have an integer column, you should not compare it to a user-provided floating point value. You can run into this issue even when using bound variables, if you are casting the values based on a user-provided type. You should always try to typecast any user-provided input to the appropriate type, you shouldn't trust the type of user input.

The difference between the queries in this section and the integer = numeric query given earlier is that the queries in this section will always result in a sequential scan for the same types in the programming language, regardless of the size of the value. With the integer = numeric query given earlier, a sequential scan can occur for different values of the same type in your programming language, because PostgreSQL implicitly treats the integer values outside the bigint range as numeric. Because the switch from an index scan to a sequential scan occurs for a different value of the same type (from a programming language perspective), I consider that a more serious issue.

**Behavior of Other Databases**

To determine whether PostgreSQL's behavior is reasonable, we can consider how other databases handle the same issue. I tested all 11 SQL databases that Sequel supports. To perform this testing, I used the following Sequel code, which inserts 2\*\*20 (~1,000,000) records, then times queries for values at the boundaries of signed and unsigned 32-bit and 64-bit types:

    DB.create_table(:large_table_test){Integer :id}
    at_exit{DB.drop_table(:large_table_test)}
    ds = DB[:large_table_test]
    ds.insert(1)
    i = 1
    20.times do 
      ds.insert([:id], ds.select{id+i})
      i *= 2
    end
    DB.add_index(:large_table_test, :id)
    puts "#{ds.count} records:"
    
    require 'benchmark'
    [0, 2**31-1, 2**31, 2**32-1, 2**32, 2**63-1, 2**63, 2**64-1, 2**64].each do |i|
      puts "WHERE (id = #{i}): #{Benchmark.measure{ds.first(id: Sequel.lit((i).to_s))}}"
    end
    

Here are the results:

*   PostgreSQL: **Vulnerable**
*   MySQL: Not Vulnerable
*   SQLite: Not Vulnerable
*   Microsoft SQL Server: Not Vulnerable
*   H2: Not Vulnerable
*   HSQLDB: Not Vulnerable
*   Apache Derby: Not Vulnerable
*   Oracle: Not Vulnerable
*   DB2: Not Vulnerable
*   SQLAnywhere: Not Vulnerable
*   Microsoft Access: Not Vulnerable

Only PostgreSQL had a significant difference in performance, showing much worse performance for 2**63, 2**64-1, and 2**64 than for the lower values.

**Potential Changes to PostgreSQL**

The behavior of treating integers outside bigint range as numeric has always been documented by PostgreSQL, so that definitely cannot be considered a bug. I think that behavior is reasonable, because the bigint type cannot support such integers. The only alternative would be raising an error, and that change is impossible due to backwards compatibility.

The actual problematic behavior is when PostgreSQL does an integer = numeric or integer = double precision comparison, it casts the integer to numeric or double precision as the first step. This the behavior that results the sequential scan, since it prevents the use of an index on the column. I think it would be better to first check if the numeric or double precision value can be represented as a value of the integer type it is compared against. If the numeric or double precision value is outside the range of that integer type or has a fractional value, then you could treat the equality comparison as false (modulo NULL handling). However, I have no knowledge of PostgreSQL internals, and therefore no idea whether such an approach is feasible.

**Changes to Sequel**

Applications using Sequel could be vulnerable to this issue, if they were not checking the sizes of the integer values, since it used large integer values directly in queries. The first change I made was to have Sequel's PostgreSQL adapter raise an exception if attempting to literalize an integer outside the bigint range. For users that really want the previous behavior, I added an extension that allowed them to select the old behavior, or to quote the large integer values.

This issue taught me a valuable lesson. For many years, I've thought using values directly in SQL queries is fine, as long as you correctly escape them. Turns out that user provided integers are not safe on PostgreSQL. If I was using bound variables, I wouldn't have needed to worry about this issue. So to prevent this type of issue in the future, I ressurected Sequel's pg_auto_parameterize extension, which uses bound variables automatically. This extension was originally added in Sequel 3.34.0, and then removed in Sequel 4.0.0 because it had many corner cases. I was able to fix almost all of the corner cases, and for the last two weeks have been running all of my applications using the pg_auto_parameterize extension. I recommend that all Sequel users using the PostgreSQL adapter try out the pg_auto_parameterize extension and see if it works for them. As mentioned above, automatically using bound variables does not prevent the issue if you are supporting arbitrary types submitted by users (e.g. users submitting float values for integer columns), so you should make sure you are validating that submitted types are expected (and/or converting submitted types to expected types).

**Updates (last updated: 2022-11-04)**

This post resulted in a small but informative discussion on Lobsters. A few things I learned from the replies:

*   This issue affected Reddit years ago, and they added validations on integer values before queries to work around it.
*   Using bound variables does not necessarily solve this issue if the datatype specified for the bound variable is also one that will cause a sequential scan. This is the equivalent of an explicit cast, and an explicit cast to the wrong type can also cause a sequential scan. This can even happen by default when using JDBC if using the setObject method instead of the setLong method for integers.
*   My point in the section about other numeric type comparisons and how they differ from the main integer = numeric comparison is true for programming languages like Ruby, which have separate integer and decimal/floating point types. However, it's probably not true for programming languages that only have a single numeric type that works for both integers and decimal/floating point values, such as JavaScript and Lua before 5.3. So if you are using a programming language that only has a single numeric type for integers and decimal/floating point values, you need to be very careful in all of your input handling, ensuring the only integer values are used for comparison to PostgreSQL integer columns, or using explicit casts to the expected integer type for all queries involving comparisons to integer columns.

This post was featured in Episode 42 of the 5mins of Postgres video series.

**Other Software Affected (last updated: 2023-01-17)**

I found that this issue affected other libraries besides Sequel. Here is a list of other libraries that were or are affected:

*   ActiveRecord is a database library for Ruby, part of Ruby on Rails. I reported this issue privately to the Rails security list. Rails fixed this issue in Rails 7.0.4.1 and 6.1.7.1.
*   Sequelize is a database library for JavaScript/TypeScript. I reported this issue privately to the maintainers, and it appears they fixed it during a very large refactoring commit.
*   SQLObject is a database library for Python. I submitted a GitHub Issue discussing this topic, but the maintainers do not think it is a security issue in SQLObject. They are unsure if it should be fixed in SQLObject itself, or in applications using SQLObject.

I think it is highly likely that other database libraries are affected, but these are the libraries I found vulnerable in the brief time I spent testing other libraries.

CVE-2022-44566: Forcing Sequential Scans on PostgreSQL Using Large Integers (2022-11-01)

Improper input validation vulnerability in Galaxy Store prior to version 4.5.49.8 allows local attackers to execute JavaScript by launching a web page.

This Cookie Policy describes the different types of cookies that may be used in connection with Samsung Mobile Security website which is owned and controlled by Samsung Electronics Co., Ltd (“Samsung Electronics”). This Cookie Policy also describes how you can manage cookies.

It’s important that you check back often for updates to the Policy as we may change it from time to time to reflect changes to our use of cookies. Please check the date at the top of this page to see when this Policy was last revised. Any changes to this Policy will become effective when we make the revised Policy available on our website.

Samsung Electronics has offices across Europe, so we can ensure that your request or query will be handled by the data protection team based in your region. If you have any questions, the easiest way to contact us is through our Privacy Support Page at https://www.samsung.com/request-desk.

You can also contact us at:

European Data Protection Officer  
Samsung Electronics (UK) Limited  
Samsung House, 2000 Hillswood Drive, Chertsey, Surrey KT16 0RS

**Cookies**

Cookies are small files that store information on your computer, TV, mobile phone, or other device. They enable the entity that put the cookie on your device to recognize you across different websites, services, devices, and/or browsing sessions.

We use the following types of cookies on this website:

**Essential Cookies**: enable you to receive the services you request via our website. Without these cookies, services that you have asked for cannot be provided. For example, these enable to identify users and provide proper service for each user. These cookies are automatically enabled and cannot be turned off because they are essential to enable you to browse our website. Without these cookies this Samsung Mobile Security website could not be provided.

Cookie

Domain

Purpose

JSESSIONID

security.samsungmobile.com

to keep login session

lastActivityTime

security.samsungmobile.com

to save the user's last activity time to automatically logout after 30 minutes of inactivity

**Managing Cookies and Other Technologies**

You can also update your browser settings at any time, if you want to remove or block cookies from your device (consult your browser's "help" menu to learn how to remove or block cookies). Samsung Electronics is not responsible for your browser settings. You can find good and simple instructions on how to manage cookies on the different types of web browsers at http://www.allaboutcookies.org.

CVE-2023-21434: Samsung Mobile Security

Missing Authorization vulnerability in One Hand Operation + prior to version 6.1.21 allows multi-users to access owner&#39;s widget without authorization via gesture setting.

CVE-2023-21450: Samsung Mobile Security

Improper access control vulnerability in WindowManagerService prior to SMR Feb-2023 Release 1 allows attackers to take a screen capture.

CVE-2023-21440: Samsung Mobile Security

A Stack-based overflow vulnerability in IpcRxEmbmsSessionList in SECRIL prior to Android S(12) allows attacker to cause memory corruptions.

CVE-2023-21451: Samsung Mobile Security

An improper implementation logic in Secure Folder prior to SMR Jan-2023 Release 1 allows the Secure Folder container remain unlocked under certain condition.

CVE-2023-21419: Samsung Mobile Security

Red Hat Security Advisory 2023-0691-01 - Open vSwitch provides standard network bridging functions and support for the OpenFlow protocol for remote per-flow control of traffic. Issues addressed include an out of bounds read vulnerability.

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

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

Synopsis:          Moderate: openvswitch2.17 security, bug fix and enhancement update  
Advisory ID:       RHSA-2023:0691-01  
Product:           Fast Datapath  
Advisory URL:      https://access.redhat.com/errata/RHSA-2023:0691  
Issue date:        2023-02-09  
CVE Names:         CVE-2022-4337 CVE-2022-4338   
=====================================================================

1. Summary:

An update for openvswitch2.17 is now available for Fast Datapath for Red  
Hat Enterprise Linux 9.

Red Hat Product Security has rated this update as having a security impact  
of Moderate. 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:

Fast Datapath for Red Hat Enterprise Linux 9 - aarch64, noarch, ppc64le, s390x, x86_64

3. Description:

Open vSwitch provides standard network bridging functions and support for  
the OpenFlow protocol for remote per-flow control of traffic.

Security Fix(es):

* openvswitch: Out-of-Bounds Read in Organization Specific TLV  
(CVE-2022-4337)  
* openvswitch: Integer Underflow in Organization Specific TLV  
(CVE-2022-4338)

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

2155378 - CVE-2022-4337 openvswitch: Out-of-Bounds Read in Organization Specific TLV  
2155381 - CVE-2022-4338 openvswitch: Integer Underflow in Organization Specific TLV  
2159419 - [ovs2.11][RHEL7.7] PF/VF Port statistics get over-run in OVS offload datapath  
2162035 - [23.A RHEL-9] Fast Datapath Release

6. Package List:

Fast Datapath for Red Hat Enterprise Linux 9:

Source:  
openvswitch2.17-2.17.0-62.el9fdp.src.rpm

aarch64:  
openvswitch2.17-2.17.0-62.el9fdp.aarch64.rpm  
openvswitch2.17-debuginfo-2.17.0-62.el9fdp.aarch64.rpm  
openvswitch2.17-debugsource-2.17.0-62.el9fdp.aarch64.rpm  
openvswitch2.17-devel-2.17.0-62.el9fdp.aarch64.rpm  
openvswitch2.17-ipsec-2.17.0-62.el9fdp.aarch64.rpm  
python3-openvswitch2.17-2.17.0-62.el9fdp.aarch64.rpm  
python3-openvswitch2.17-debuginfo-2.17.0-62.el9fdp.aarch64.rpm

noarch:  
openvswitch2.17-test-2.17.0-62.el9fdp.noarch.rpm

ppc64le:  
openvswitch2.17-2.17.0-62.el9fdp.ppc64le.rpm  
openvswitch2.17-debuginfo-2.17.0-62.el9fdp.ppc64le.rpm  
openvswitch2.17-debugsource-2.17.0-62.el9fdp.ppc64le.rpm  
openvswitch2.17-devel-2.17.0-62.el9fdp.ppc64le.rpm  
openvswitch2.17-ipsec-2.17.0-62.el9fdp.ppc64le.rpm  
python3-openvswitch2.17-2.17.0-62.el9fdp.ppc64le.rpm  
python3-openvswitch2.17-debuginfo-2.17.0-62.el9fdp.ppc64le.rpm

s390x:  
openvswitch2.17-2.17.0-62.el9fdp.s390x.rpm  
openvswitch2.17-debuginfo-2.17.0-62.el9fdp.s390x.rpm  
openvswitch2.17-debugsource-2.17.0-62.el9fdp.s390x.rpm  
openvswitch2.17-devel-2.17.0-62.el9fdp.s390x.rpm  
openvswitch2.17-ipsec-2.17.0-62.el9fdp.s390x.rpm  
python3-openvswitch2.17-2.17.0-62.el9fdp.s390x.rpm  
python3-openvswitch2.17-debuginfo-2.17.0-62.el9fdp.s390x.rpm

x86_64:  
openvswitch2.17-2.17.0-62.el9fdp.x86_64.rpm  
openvswitch2.17-debuginfo-2.17.0-62.el9fdp.x86_64.rpm  
openvswitch2.17-debugsource-2.17.0-62.el9fdp.x86_64.rpm  
openvswitch2.17-devel-2.17.0-62.el9fdp.x86_64.rpm  
openvswitch2.17-ipsec-2.17.0-62.el9fdp.x86_64.rpm  
python3-openvswitch2.17-2.17.0-62.el9fdp.x86_64.rpm  
python3-openvswitch2.17-debuginfo-2.17.0-62.el9fdp.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-4337  
https://access.redhat.com/security/cve/CVE-2022-4338  
https://access.redhat.com/security/updates/classification/#moderate

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

iQIVAwUBY+RnytzjgjWX9erEAQh83hAAn7wZtp4GczoBt9pm1Cbl8ug0NFzax2Ve  
D1VedORejT43jl84X2tHGsMx95heFU0eCmIMD88Szqj9Vx3Yi3IZPX1htRNVb2mC  
4u27n+uAaIGFVkNcx1aWfKO2qitYmCCSsg2zQenJqhe+Pt4gUmvRy2R7feiyW91Q  
u7xo3kHyaOof9J+87WWq+xxmEXp6gAOl7/pzClew38cq/f7bUmHiMZE4o+nlM6rJ  
jhCvDQSr4PVaHBqiHsh1dH4npuXqkBzlqi0uG2qgU4sAhfEMhmG0eI52q7TzUm4w  
ASCz3c6aOYLQq4e0CXrB4+tHf2tN1SJCA4YBjhvFnPUbidxfdAOqvImj3dAJAvvc  
Oc93W74Zb1zIxHBkRWeVNzOEKQT8WOHrAzMbWEYObndTvKcvv6xn582dIbwgT4oy  
Z62tl6VHDTbemWkN+BcTAIllIqyamhBNv9VgzUpIeIk9TGj5Mh7qDn2dL9pJv//o  
n4D9FUfal2elVLjFqlJ23m0nU9S6EYNGv8FisfUA32sFu2HxRRmDoC7AoBPxUzQj  
U5o8RIEPVnwWfjvuKC9LymDKRU4AQV11GIEGq6zEvZYP2A8j/oDpfEmTmg5NhUeI  
Z8QlezHTOyMfGjsFfkz+8MzKuwabA7phwvYk/MRRE81Pr7cpDebKHy37NfAhaEp9  
w9uYO6IHLig=  
=B0kT  
-----END PGP SIGNATURE-----  
--  
RHSA-announce mailing list  
RHSA-announce@redhat.com  
https://listman.redhat.com/mailman/listinfo/rhsa-announce

Red Hat Security Advisory 2023-0691-01

Red Hat Security Advisory 2023-0688-01 - Open vSwitch provides standard network bridging functions and support for the OpenFlow protocol for remote per-flow control of traffic. Issues addressed include an out of bounds read vulnerability.

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

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

Synopsis:          Moderate: openvswitch2.17 security, bug fix and enhancement update  
Advisory ID:       RHSA-2023:0688-01  
Product:           Fast Datapath  
Advisory URL:      https://access.redhat.com/errata/RHSA-2023:0688  
Issue date:        2023-02-09  
CVE Names:         CVE-2022-4337 CVE-2022-4338   
=====================================================================

1. Summary:

An update for openvswitch2.17 is now available for Fast Datapath for Red  
Hat Enterprise Linux 8.

Red Hat Product Security has rated this update as having a security impact  
of Moderate. 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:

Fast Datapath for Red Hat Enterprise Linux 8 - aarch64, noarch, ppc64le, s390x, x86_64

3. Description:

Open vSwitch provides standard network bridging functions and support for  
the OpenFlow protocol for remote per-flow control of traffic.

Security Fix(es):

* openvswitch: Out-of-Bounds Read in Organization Specific TLV  
(CVE-2022-4337)  
* openvswitch: Integer Underflow in Organization Specific TLV  
(CVE-2022-4338)

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

2155378 - CVE-2022-4337 openvswitch: Out-of-Bounds Read in Organization Specific TLV  
2155381 - CVE-2022-4338 openvswitch: Integer Underflow in Organization Specific TLV  
2162034 - [23.A RHEL-8] Fast Datapath Release

6. Package List:

Fast Datapath for Red Hat Enterprise Linux 8:

Source:  
openvswitch2.17-2.17.0-71.el8fdp.src.rpm

aarch64:  
network-scripts-openvswitch2.17-2.17.0-71.el8fdp.aarch64.rpm  
openvswitch2.17-2.17.0-71.el8fdp.aarch64.rpm  
openvswitch2.17-debuginfo-2.17.0-71.el8fdp.aarch64.rpm  
openvswitch2.17-debugsource-2.17.0-71.el8fdp.aarch64.rpm  
openvswitch2.17-devel-2.17.0-71.el8fdp.aarch64.rpm  
openvswitch2.17-ipsec-2.17.0-71.el8fdp.aarch64.rpm  
python3-openvswitch2.17-2.17.0-71.el8fdp.aarch64.rpm  
python3-openvswitch2.17-debuginfo-2.17.0-71.el8fdp.aarch64.rpm

noarch:  
openvswitch2.17-test-2.17.0-71.el8fdp.noarch.rpm

ppc64le:  
network-scripts-openvswitch2.17-2.17.0-71.el8fdp.ppc64le.rpm  
openvswitch2.17-2.17.0-71.el8fdp.ppc64le.rpm  
openvswitch2.17-debuginfo-2.17.0-71.el8fdp.ppc64le.rpm  
openvswitch2.17-debugsource-2.17.0-71.el8fdp.ppc64le.rpm  
openvswitch2.17-devel-2.17.0-71.el8fdp.ppc64le.rpm  
openvswitch2.17-ipsec-2.17.0-71.el8fdp.ppc64le.rpm  
python3-openvswitch2.17-2.17.0-71.el8fdp.ppc64le.rpm  
python3-openvswitch2.17-debuginfo-2.17.0-71.el8fdp.ppc64le.rpm

s390x:  
network-scripts-openvswitch2.17-2.17.0-71.el8fdp.s390x.rpm  
openvswitch2.17-2.17.0-71.el8fdp.s390x.rpm  
openvswitch2.17-debuginfo-2.17.0-71.el8fdp.s390x.rpm  
openvswitch2.17-debugsource-2.17.0-71.el8fdp.s390x.rpm  
openvswitch2.17-devel-2.17.0-71.el8fdp.s390x.rpm  
openvswitch2.17-ipsec-2.17.0-71.el8fdp.s390x.rpm  
python3-openvswitch2.17-2.17.0-71.el8fdp.s390x.rpm  
python3-openvswitch2.17-debuginfo-2.17.0-71.el8fdp.s390x.rpm

x86_64:  
network-scripts-openvswitch2.17-2.17.0-71.el8fdp.x86_64.rpm  
openvswitch2.17-2.17.0-71.el8fdp.x86_64.rpm  
openvswitch2.17-debuginfo-2.17.0-71.el8fdp.x86_64.rpm  
openvswitch2.17-debugsource-2.17.0-71.el8fdp.x86_64.rpm  
openvswitch2.17-devel-2.17.0-71.el8fdp.x86_64.rpm  
openvswitch2.17-ipsec-2.17.0-71.el8fdp.x86_64.rpm  
python3-openvswitch2.17-2.17.0-71.el8fdp.x86_64.rpm  
python3-openvswitch2.17-debuginfo-2.17.0-71.el8fdp.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-4337  
https://access.redhat.com/security/cve/CVE-2022-4338  
https://access.redhat.com/security/updates/classification/#moderate

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

iQIVAwUBY+RnxNzjgjWX9erEAQiAng/8CEF0s+9tyHZJ5vvhbA4EMhTBY30BvlWf  
WPyybqxk2tucXuk4ARfruStnf/AZpL8xtf9aznCOhP4vacrpWYp7PJausIRfLKwG  
Jk1xsOJs3imyKSMkJR9ilJBvuyG6GFD9e/RR/2z5H1vpcw1ldL9MpizDyVLy0I3F  
XYjgMIHJDC66PwJRua4ABeiIrX2P8+tCm3cynXxrA/08DvVsQ/HZMnO5XMZh6+uw  
QXubvp6ThkNJBLi5fENErJWAlpu31c/sI6njP7VZdInRX+mDh99aDFFvAGZ4RetQ  
DslipMvHpe7niXEJ9EEXirAZkGOHhNQmh5e3wXYjc4Fn1lq+hLDB2friB0rNdBlR  
e4BG3m3wK9TebgvpLkK7mt3jdn8zlxAtY33Wg2SYSHLwpFj0kxQ0tZAKQTTpwc9l  
Ek/yfFubEGfZoYIhqCBFOEnEb635SVXQYFL2QQw4JGZf46xEewBxLxftp/SZ4H7D  
eLQXmrBHflEALaqnazOPObNNw2jB7gQmm5svAatZd1fy1vcFVIqB7hdy701SpWBm  
jzlvazTq59t3UmlUPs9OhkIOR//BaUuuSLqNm3xPGxE2hHOsC/yURdYBcfFRRBcf  
zqWOHIRNysHcyzBMtixtnbB9S4uf5EKo9RGf2TLGRW1ZdFYN2TsA7ryklWo/9RRD  
QliC+OVLpHo=  
=mmIf  
-----END PGP SIGNATURE-----  
--  
RHSA-announce mailing list  
RHSA-announce@redhat.com  
https://listman.redhat.com/mailman/listinfo/rhsa-announce

Tag

#js