You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When curl is asked to use HSTS, the expiry time for a subdomain might
overwrite a parent domain's cache entry, making it end sooner or later than
otherwise intended.
This affects curl using applications that enable HSTS and use URLs with the
insecure HTTP:// scheme and perform transfers with hosts like x.example.com as well as example.com where the first host is a subdomain
of the second host.
(The HSTS cache either needs to have been populated manually or there needs to
have been previous HTTPS accesses done as the cache needs to have entries for
the domains involved to trigger this problem.)
When x.example.com responds with Strict-Transport-Security: headers, this
bug can make the subdomain's expiry timeout bleed over and get set for the
parent domain example.com in curl's HSTS cache.
The result of a triggered bug is that HTTP accesses to example.com get
converted to HTTPS for a different period of time than what was asked for by
the origin server. If example.com for example stops supporting HTTPS at its
expiry time, curl might then fail to access http://example.com until the
(wrongly set) timeout expires. This bug can also expire the parent's entry earlier, thus making curl inadvertently switch back to insecure HTTP earlier
than otherwise intended.
Remediation Steps
Update the affected package curl from version 8.3.0-1.amzn2.0.7 to 8.3.0-1.amzn2.0.8.
About this issue
This issue may not contain all the information about the CVE nor the images it affects.
This issue will not be updated with new information and the list of affected images may have changed since the creation of this issue.
CVE Details
MEDIUM
curl
8.3.0-1.amzn2.0.7
8.3.0-1.amzn2.0.8
2024-11-06T08:15:03.74Z
2025-01-10T10:18:22.607359557Z
Affected Docker Images
public.ecr.aws/lambda/provided:al2
public.ecr.aws/lambda/provided@sha256:53d9274bb52d2396ddad4aaa50a1d333402fe63c649262b75e9d2d68aa716746
public.ecr.aws/lambda/python:3.11
public.ecr.aws/lambda/python@sha256:16d97e570819711f62471d33828066421b1589aad11021f210059d751c539957
public.ecr.aws/lambda/python:3.10
public.ecr.aws/lambda/python@sha256:a0a02845bc28bc464ee0b19e4c1ef0bf5d1d330697d2c937f8e82e8448abd192
public.ecr.aws/lambda/python:3.9
public.ecr.aws/lambda/python@sha256:af5c9e23286b5ed9e280e794428c6ca12961e37e778682a99857025b8f4dab27
public.ecr.aws/lambda/nodejs:18
public.ecr.aws/lambda/nodejs@sha256:493330ba8e63c4e3ead44ea7c6b67797ecc21ae4c9e4a805eb2a1fb410eed709
public.ecr.aws/lambda/java:17
public.ecr.aws/lambda/java@sha256:381d98e6781ca2f724f799019af37651ae3d5f9973de65c0faaf4e18befa2196
public.ecr.aws/lambda/java:11
public.ecr.aws/lambda/java@sha256:11d21e0b4280e46b9004f65cb17bc390f4857f85fc5f290a980ae91dd2f9f13f
public.ecr.aws/lambda/java:8.al2
public.ecr.aws/lambda/java@sha256:c97c9d4fab4662d12cc10a653b8e6a7f778530382d734d653ad5ceb8eb460dbe
public.ecr.aws/lambda/dotnet:6
public.ecr.aws/lambda/dotnet@sha256:376bf73799c547704323fa58c8ef67059b61ea91674c1771a23539a405f061e8
Description
This affects curl using applications that enable HSTS and use URLs with the
insecure
HTTP://
scheme and perform transfers with hosts likex.example.com
as well asexample.com
where the first host is a subdomainof the second host.
(The HSTS cache either needs to have been populated manually or there needs to
have been previous HTTPS accesses done as the cache needs to have entries for
the domains involved to trigger this problem.)
When
x.example.com
responds withStrict-Transport-Security:
headers, thisbug can make the subdomain's expiry timeout bleed over and get set for the
parent domain
example.com
in curl's HSTS cache.The result of a triggered bug is that HTTP accesses to
example.com
getconverted to HTTPS for a different period of time than what was asked for by
the origin server. If
example.com
for example stops supporting HTTPS at itsexpiry time, curl might then fail to access
http://example.com
until the(wrongly set) timeout expires. This bug can also expire the parent's entry
earlier, thus making curl inadvertently switch back to insecure HTTP earlier
than otherwise intended.
Remediation Steps
curl
from version8.3.0-1.amzn2.0.7
to8.3.0-1.amzn2.0.8
.About this issue
The text was updated successfully, but these errors were encountered: