CVE-2023-47641

aiohttp is an asynchronous HTTP client/server framework for asyncio and Python. Affected versions of aiohttp have a security vulnerability regarding the inconsistent interpretation of the http protocol. HTTP/1.1 is a persistent protocol, if both Content-Length(CL) and Transfer-Encoding(TE) header values are present it can lead to incorrect interpretation of two entities that parse the HTTP and we can poison other sockets with this incorrect interpretation. A possible Proof-of-Concept (POC) would be a configuration with a reverse proxy(frontend) that accepts both CL and TE headers and aiohttp as backend. As aiohttp parses anything with chunked, we can pass a chunked123 as TE, the frontend entity will ignore this header and will parse Content-Length. The impact of this vulnerability is that it is possible to bypass any proxy rule, poisoning sockets to other users like passing Authentication Headers, also if it is present an Open Redirect an attacker could combine it to redirect random users to another website and log the request. This vulnerability has been addressed in release 3.8.0 of aiohttp. Users are advised to upgrade. There are no known workarounds for this vulnerability.

aiohttp is an asynchronous HTTP client/server framework for asyncio and Python. Affected versions of aiohttp have a security vulnerability regarding the inconsistent interpretation of the http protocol. HTTP/1.1 is a persistent protocol, if both Content-Length(CL) and Transfer-Encoding(TE) header values are present it can lead to incorrect interpretation of two entities that parse the HTTP and we can poison other sockets with this incorrect interpretation. A possible Proof-of-Concept (POC) would be a configuration with a reverse proxy(frontend) that accepts both CL and TE headers and aiohttp as backend. As aiohttp parses anything with chunked, we can pass a chunked123 as TE, the frontend entity will ignore this header and will parse Content-Length. The impact of this vulnerability is that it is possible to bypass any proxy rule, poisoning sockets to other users like passing Authentication Headers, also if it is present an Open Redirect an attacker could combine it to redirect random users to another website and log the request. This vulnerability has been addressed in release 3.8.0 of aiohttp. Users are advised to upgrade. There are no known workarounds for this vulnerability.

Impact

Aiohttp has a security vulnerability regarding the inconsistent interpretation of the http protocol. As we know that HTTP/1.1 is persistent, if we have both Content-Length(CL) and Transfer-Encoding(TE) it can lead to incorrect interpretation of two entities that parse the HTTP and we can poison other sockets with this incorrect interpretation.

A possible Proof-of-Concept (POC) would be a configuration with a reverse proxy(frontend) that accepts both CL and TE headers and aiohttp as backend. As aiohttp parses anything with chunked, we can pass a chunked123 as TE, the frontend entity will ignore this header and will parse Content-Length. I can give a Dockerfile with the configuration if you want.

The impact of this vulnerability is that it is possible to bypass any proxy rule, poisoning sockets to other users like passing Authentication Headers, also if it is present an Open Redirect (just like CVE-2021-21330) we can combine it to redirect random users to our website and log the request.

References

• https://github.com/aio-libs/aiohttp/commit/f016f0680e4ace6742b03a70cb0382ce86abe371

Async http client/server framework (asyncio).

Security Fix(es):

aiohttp is an asynchronous HTTP client/server framework for asyncio and Python. Affected versions of aiohttp have a security vulnerability regarding the inconsistent interpretation of the http protocol. HTTP/1.1 is a persistent protocol, if both Content-Length(CL) and Transfer-Encoding(TE) header values are present it can lead to incorrect interpretation of two entities that parse the HTTP and we can poison other sockets with this incorrect interpretation. A possible Proof-of-Concept (POC) would be a configuration with a reverse proxy(frontend) that accepts both CL and TE headers and aiohttp as backend. As aiohttp parses anything with chunked, we can pass a chunked123 as TE, the frontend entity will ignore this header and will parse Content-Length. The impact of this vulnerability is that it is possible to bypass any proxy rule, poisoning sockets to other users like passing Authentication Headers, also if it is present an Open Redirect an attacker could combine it to redirect random users to another website and log the request. This vulnerability has been addressed in release 3.8.0 of aiohttp. Users are advised to upgrade. There are no known workarounds for this vulnerability.(CVE-2023-47641)

aiohttp is an asynchronous HTTP client/server framework for asyncio and Python. Affected versions of aiohttp have a security vulnerability regarding the inconsistent interpretation of the http protocol. HTTP/1.1 is a persistent protocol, if both Content-Length(CL) and Transfer-Encoding(TE) header values are present it can lead to incorrect interpretation of two entities that parse the HTTP and we can poison other sockets with this incorrect interpretation. A possible Proof-of-Concept (POC) would be a configuration with a reverse proxy(frontend) that accepts both CL and TE headers and aiohttp as backend. As aiohttp parses anything with chunked, we can pass a chunked123 as TE, the frontend entity will ignore this header and will parse Content-Length. The impact of this vulnerability is that it is possible to bypass any proxy rule, poisoning sockets to other users like passing Authentication Headers, also if it is present an Open Redirect an attacker could combine it to redirect random users to another website and log the request. This vulnerability has been addressed in release 3.8.0 of aiohttp. Users are advised to upgrade. There are no known workarounds for this vulnerability.

aiohttp is an asynchronous HTTP client/server framework for asyncio and Python. Affected versions of aiohttp have a security vulnerability regarding the inconsistent interpretation of the http protocol. HTTP/1.1 is a persistent protocol, if both Content-Length(CL) and Transfer-Encoding(TE) header values are present it can lead to incorrect interpretation of two entities that parse the HTTP and we can poison other sockets with this incorrect interpretation. A possible Proof-of-Concept (POC) would be a configuration with a reverse proxy(frontend) that accepts both CL and TE headers and aiohttp as backend. As aiohttp parses anything with chunked, we can pass a chunked123 as TE, the frontend entity will ignore this header and will parse Content-Length. The impact of this vulnerability is that it is possible to bypass any proxy rule, poisoning sockets to other users like passing Authentication Headers, also if it is present an Open Redirect an attacker could combine it to redirect random users to another website and log the request. This vulnerability has been addressed in release 3.8.0 of aiohttp. Users are advised to upgrade. There are no known workarounds for this vulnerability.

These are all security issues fixed in the python310-aiohttp-3.9.3-2.1 package on the GA media of openSUSE Tumbleweed.

These are all security issues fixed in the python313-aiohttp-3.14.3-1.1 package on the GA media of openSUSE Tumbleweed.

This update for python-aiohttp fixes the following issues:

• CVE-2023-47641: Fixed inconsistent interpretation of the http protocol, if content-length and transport-encoding are in the same header with transport-encoding value of 'chunked*' (bsc#1217174)

This update for python-aiohttp, python-time-machine fixes the following issues:

python-aiohttp was updated to version 3.9.3:

• Fixed backwards compatibility breakage (in 3.9.2) of ssl parameter when set outside of ClientSession (e.g. directly in TCPConnector)
• Improved test suite handling of paths and temp files to consistently use pathlib and pytest fixtures.

From version 3.9.2 (bsc#1219341, CVE-2024-23334, bsc#1219342, CVE-2024-23829):

• Fixed server-side websocket connection leak.
• Fixed web.FileResponse doing blocking I/O in the event loop.
• Fixed double compress when compression enabled and compressed file exists in server file responses.
• Added runtime type check for ClientSession timeout parameter.
• Fixed an unhandled exception in the Python HTTP parser on header lines starting with a colon.
• Improved validation of paths for static resources requests to the server.
• Added support for passing :py:data:True to ssl parameter in ClientSession while deprecating :py:data:None.
• Fixed an unhandled exception in the Python HTTP parser on header lines starting with a colon.
• Fixed examples of fallback_charset_resolver function in the :doc:client_advanced document.
• The Sphinx setup was updated to avoid showing the empty changelog draft section in the tagged release documentation builds on Read The Docs.
• The changelog categorization was made clearer. The contributors can now mark their fragment files more accurately.
• Updated :ref:contributing/Tests coverage <aiohttp-contributing> section to show how we use codecov.
• Replaced all tmpdir fixtures with tmp_path in test suite.

• Disable broken tests with openssl 3.2 and python < 3.11 bsc#1217782

update to 3.9.1:

• Fixed importing aiohttp under PyPy on Windows.
• Fixed async concurrency safety in websocket compressor.
• Fixed ClientResponse.close() releasing the connection instead of closing.
• Fixed a regression where connection may get closed during upgrade. -- by :user:Dreamsorcerer
• Fixed messages being reported as upgraded without an Upgrade header in Python parser. -- by :user:Dreamsorcerer

update to 3.9.0: (bsc#1217684, CVE-2023-49081, bsc#1217682, CVE-2023-49082)

• Introduced AppKey for static typing support of Application storage.
• Added a graceful shutdown period which allows pending tasks to complete before the application's cleanup is called.
• Added handler_cancellation_ parameter to cancel web handler on client disconnection.
• This (optionally) reintroduces a feature removed in a previous release.
• Recommended for those looking for an extra level of protection against denial-of-service attacks.
• Added support for setting response header parameters max_line_size and max_field_size.
• Added auto_decompress parameter to ClientSession.request to override ClientSession._auto_decompress.
• Changed raise_for_status to allow a coroutine.
• Added client brotli compression support (optional with runtime check).
• Added client_max_size to BaseRequest.clone() to allow overriding the request body size. -- :user:anesabml.
• Added a middleware type alias aiohttp.typedefs.Middleware.
• Exported HTTPMove which can be used to catch any redirection request that has a location -- :user:dreamsorcerer.
• Changed the path parameter in web.run_app() to accept a pathlib.Path object.
• Performance: Skipped filtering CookieJar when the jar is empty or all cookies have expired.
• Performance: Only check origin if insecure scheme and there are origins to treat as secure, in CookieJar.filter_cookies().
• Performance: Used timestamp instead of datetime to achieve faster cookie expiration in CookieJar.
• Added support for passing a custom server name parameter to HTTPS connection.
• Added support for using Basic Auth credentials from :file:.netrc file when making…