-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Fix 16 vulnerable dependencies identified by Prisma Cloud #5
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Bridgecrew has found errors in this PR ⬇️
@@ -8,7 +8,7 @@ backoff==2.2.1 | |||
# via opentelemetry-exporter-otlp-proto-grpc | |||
cachetools==5.2.0 | |||
# via google-auth | |||
certifi==2022.12.7 | |||
certifi == 2023.07.22 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
certifi 2023.0 / requirements.txt
Total vulnerabilities: 1
Critical: 1 | High: 0 | Medium: 0 | Low: 0 |
---|
Vulnerability ID | Severity | CVSS | Fixed in | Status |
---|---|---|---|---|
CVE-2023-37920 | 9.8 | 2023.07.22 |
Open |
@@ -6,7 +6,7 @@ | |||
# | |||
brotli==1.0.9 | |||
# via geventhttpclient | |||
certifi==2022.12.7 | |||
certifi == 2023.07.22 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
certifi 2023.0 / requirements.txt
Total vulnerabilities: 1
Critical: 1 | High: 0 | Medium: 0 | Low: 0 |
---|
Vulnerability ID | Severity | CVSS | Fixed in | Status |
---|---|---|---|---|
CVE-2023-37920 | 9.8 | 2023.07.22 |
Open |
@@ -8,7 +8,7 @@ backoff==2.2.1 | |||
# via opentelemetry-exporter-otlp-proto-grpc | |||
cachetools==5.2.0 | |||
# via google-auth | |||
certifi==2022.12.7 | |||
certifi == 2023.07.22 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
certifi 2023.0 / requirements.txt
Total vulnerabilities: 1
Critical: 1 | High: 0 | Medium: 0 | Low: 0 |
---|
Vulnerability ID | Severity | CVSS | Fixed in | Status |
---|---|---|---|---|
CVE-2023-37920 | 9.8 | 2023.07.22 |
Open |
54b5c1c
to
58b6cd2
Compare
@@ -6,7 +6,7 @@ | |||
# | |||
brotli==1.0.9 | |||
# via geventhttpclient | |||
certifi==2022.12.7 | |||
certifi == 2023.07.22 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
certifi 2023.0 / requirements.txt
Total vulnerabilities: 1
Critical: 1 | High: 0 | Medium: 0 | Low: 0 |
---|
Vulnerability ID | Severity | CVSS | Fixed in | Status |
---|---|---|---|---|
CVE-2023-37920 | 9.8 | 2023.07.22 |
Open |
@@ -8,7 +8,7 @@ backoff==2.2.1 | |||
# via opentelemetry-exporter-otlp-proto-grpc | |||
cachetools==5.2.0 | |||
# via google-auth | |||
certifi==2022.12.7 | |||
certifi == 2023.07.22 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
certifi 2023.0 / requirements.txt
Total vulnerabilities: 1
Critical: 1 | High: 0 | Medium: 0 | Low: 0 |
---|
Vulnerability ID | Severity | CVSS | Fixed in | Status |
---|---|---|---|---|
CVE-2023-37920 | 9.8 | 2023.07.22 |
Open |
@@ -8,7 +8,7 @@ backoff==2.2.1 | |||
# via opentelemetry-exporter-otlp-proto-grpc | |||
cachetools==5.2.0 | |||
# via google-auth | |||
certifi==2022.12.7 | |||
certifi == 2023.07.22 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
certifi 2023.0 / requirements.txt
Total vulnerabilities: 1
Critical: 1 | High: 0 | Medium: 0 | Low: 0 |
---|
Vulnerability ID | Severity | CVSS | Fixed in | Status |
---|---|---|---|---|
CVE-2023-37920 | 9.8 | 2023.07.22 |
Open |
Prisma Cloud has detected new vulnerabilities or dependencies in the scan performed on Sat, 16 Dec 2023 11:58:03 UTC
This PR includes the fixes for the vulnerabilities discovered below:
http_method
that has unbound cardinality. It leads to the server's potential memory exhaustion when many malicious requests are sent. HTTP method for requests can be easily set by an attacker to be random and long. In order to be affected program has to be instrumented for HTTP handlers and does not filter any unknown HTTP methods on the level of CDN, LB, previous middleware, etc. This issue has been patched in version 0.41b0.Cookie
HTTP header special or provide any helpers for managing cookies over HTTP, that is the responsibility of the user. However, it is possible for a user to specify aCookie
header and unknowingly leak information via HTTP redirects to a different origin if that user doesn't disable redirects explicitly. This issue has been patched in urllib3 version 1.26.17 or 2.0.5.Set-Cookie
headers, it may send one client'ssession
cookie to other clients. The severity depends on the application's use of the session and the proxy's behavior regarding cookies. The risk depends on all these conditions being met. 1. The application must be hosted behind a caching proxy that does not strip cookies or ignore responses with cookies. 2. The application setssession.permanent = True
3. The application does not access or modify the session at any point during a request. 4.SESSION_REFRESH_EACH_REQUEST
enabled (the default). 5. The application does not set aCache-Control
header to indicate that a page is private or should not be cached. This happens because vulnerable versions of Flask only set theVary: Cookie
header when the session is accessed or modified, not when it is refreshed (re-sent to update the expiration) without being accessed or modified. This issue has been fixed in versions 2.3.2 and 2.2.5.Cookie
HTTP header special or provide any helpers for managing cookies over HTTP, that is the responsibility of the user. However, it is possible for a user to specify aCookie
header and unknowingly leak information via HTTP redirects to a different origin if that user doesn't disable redirects explicitly. This issue has been patched in urllib3 version 1.26.17 or 2.0.5.request.data
,request.form
,request.files
, orrequest.get_data(parse_form_data=False)
, it can cause unexpectedly high resource usage. This allows an attacker to cause a denial of service by sending crafted multipart data to an endpoint that will parse it. The amount of CPU time required can block worker processes from handling legitimate requests. The amount of RAM required can trigger an out of memory kill of the process. Unlimited file parts can use up memory and file handles. If many concurrent requests are sent continuously, this can exhaust or kill all available workers. Version 2.2.3 contains a patch for this issue.http_method
that has unbound cardinality. It leads to the server's potential memory exhaustion when many malicious requests are sent. HTTP method for requests can be easily set by an attacker to be random and long. In order to be affected program has to be instrumented for HTTP handlers and does not filter any unknown HTTP methods on the level of CDN, LB, previous middleware, etc. This issue has been patched in version 0.41b0.Cookie
HTTP header special or provide any helpers for managing cookies over HTTP, that is the responsibility of the user. However, it is possible for a user to specify aCookie
header and unknowingly leak information via HTTP redirects to a different origin if that user doesn't disable redirects explicitly. This issue has been patched in urllib3 version 1.26.17 or 2.0.5.grpc.MaxConcurrentStreams
server option to apply a limit to the server's resources used for any single connection. ### Workarounds None. ### References #6703net.peer.sock.addr
andnet.peer.sock.port
that have unbound cardinality. It leads to the server's potential memory exhaustion when many malicious requests are sent. An attacker can easily flood the peer address and port for requests. Version 0.46.0 contains a fix for this issue. As a workaround to stop being affected, a view removing the attributes can be used. The other possibility is to disable grpc metrics instrumentation by passingotelgrpc.WithMeterProvider
option withnoop.NewMeterProvider
.net.peer.sock.addr
andnet.peer.sock.port
that have unbound cardinality. It leads to the server's potential memory exhaustion when many malicious requests are sent. An attacker can easily flood the peer address and port for requests. Version 0.46.0 contains a fix for this issue. As a workaround to stop being affected, a view removing the attributes can be used. The other possibility is to disable grpc metrics instrumentation by passingotelgrpc.WithMeterProvider
option withnoop.NewMeterProvider
.grpc.MaxConcurrentStreams
server option to apply a limit to the server's resources used for any single connection. ### Workarounds None. ### References #6703http.user_agent
andhttp.method
that have unbound cardinality. It leads to the server's potential memory exhaustion when many malicious requests are sent to it. HTTP header User-Agent or HTTP method for requests can be easily set by an attacker to be random and long. The library internally useshttpconv.ServerRequest
that records every value for HTTPmethod
andUser-Agent
. In order to be affected, a program has to use theotelhttp.NewHandler
wrapper and not filter any unknown HTTP methods or User agents on the level of CDN, LB, previous middleware, etc. Version 0.44.0 fixed this issue when the values collected for attributehttp.request.method
were changed to be restricted to a set of well-known values and other high cardinality attributes were removed. As a workaround to stop being affected,otelhttp.WithFilter()
can be used, but it requires manual careful configuration to not log certain requests entirely. For convenience and safe usage of this library, it should by default mark with the labelunknown
non-standard HTTP methods and User agents to show that such requests were made but do not increase cardinality. In case someone wants to stay with the current behavior, library API should allow to enable it.grpc.MaxConcurrentStreams
server option to apply a limit to the server's resources used for any single connection. ### Workarounds None. ### References #6703net.peer.sock.addr
andnet.peer.sock.port
that have unbound cardinality. It leads to the server's potential memory exhaustion when many malicious requests are sent. An attacker can easily flood the peer address and port for requests. Version 0.46.0 contains a fix for this issue. As a workaround to stop being affected, a view removing the attributes can be used. The other possibility is to disable grpc metrics instrumentation by passingotelgrpc.WithMeterProvider
option withnoop.NewMeterProvider
.grpc.MaxConcurrentStreams
server option to apply a limit to the server's resources used for any single connection. ### Workarounds None. ### References #6703-bin
suffixed headers will result in a disconnection by the gRPC server, but is typically allowed by HTTP2 proxies. We recommend upgrading beyond the commit inu00a0 grpc/grpc#32309 https://www.google.com/urlrebuild_proxies
to reattach theProxy-Authorization
header to requests. For HTTP connections sent through the tunnel, the proxy will identify the header in the request itself and remove it prior to forwarding to the destination server. However when sent over HTTPS, theProxy-Authorization
header must be sent in the CONNECT request as the proxy has no visibility into the tunneled request. This results in Requests forwarding proxy credentials to the destination server unintentionally, allowing a malicious actor to potentially exfiltrate sensitive information. This issue has been patched in version 2.31.0.POST
) toGET
as is required by HTTP RFCs. Although this behavior is not specified in the section for redirects, it can be inferred by piecing together information from different sections and we have observed the behavior in other major HTTP client implementations like curl and web browsers. Because the vulnerability requires a previously trusted service to become compromised in order to have an impact on confidentiality we believe the exploitability of this vulnerability is low. Additionally, many users aren't putting sensitive data in HTTP request bodies, if this is the case then this vulnerability isn't exploitable. Both of the following conditions must be true to be affected by this vulnerability: 1. Using urllib3 and submitting sensitive information in the HTTP request body (such as form data or JSON) and 2. The origin service is compromised and starts redirecting using 301, 302, or 303 to a malicious peer or the redirected-to service becomes compromised. This issue has been addressed in versions 1.26.18 and 2.0.7 and users are advised to update to resolve this issue. Users unable to update should disable redrebuild_proxies
to reattach theProxy-Authorization
header to requests. For HTTP connections sent through the tunnel, the proxy will identify the header in the request itself and remove it prior to forwarding to the destination server. However when sent over HTTPS, theProxy-Authorization
header must be sent in the CONNECT request as the proxy has no visibility into the tunneled request. This results in Requests forwarding proxy credentials to the destination server unintentionally, allowing a malicious actor to potentially exfiltrate sensitive information. This issue has been patched in version 2.31.0.POST
) toGET
as is required by HTTP RFCs. Although this behavior is not specified in the section for redirects, it can be inferred by piecing together information from different sections and we have observed the behavior in other major HTTP client implementations like curl and web browsers. Because the vulnerability requires a previously trusted service to become compromised in order to have an impact on confidentiality we believe the exploitability of this vulnerability is low. Additionally, many users aren't putting sensitive data in HTTP request bodies, if this is the case then this vulnerability isn't exploitable. Both of the following conditions must be true to be affected by this vulnerability: 1. Using urllib3 and submitting sensitive information in the HTTP request body (such as form data or JSON) and 2. The origin service is compromised and starts redirecting using 301, 302, or 303 to a malicious peer or the redirected-to service becomes compromised. This issue has been addressed in versions 1.26.18 and 2.0.7 and users are advised to update to resolve this issue. Users unable to update should disable red-bin
suffixed headers will result in a disconnection by the gRPC server, but is typically allowed by HTTP2 proxies. We recommend upgrading beyond the commit inu00a0 grpc/grpc#32309 https://www.google.com/urlrebuild_proxies
to reattach theProxy-Authorization
header to requests. For HTTP connections sent through the tunnel, the proxy will identify the header in the request itself and remove it prior to forwarding to the destination server. However when sent over HTTPS, theProxy-Authorization
header must be sent in the CONNECT request as the proxy has no visibility into the tunneled request. This results in Requests forwarding proxy credentials to the destination server unintentionally, allowing a malicious actor to potentially exfiltrate sensitive information. This issue has been patched in version 2.31.0.POST
) toGET
as is required by HTTP RFCs. Although this behavior is not specified in the section for redirects, it can be inferred by piecing together information from different sections and we have observed the behavior in other major HTTP client implementations like curl and web browsers. Because the vulnerability requires a previously trusted service to become compromised in order to have an impact on confidentiality we believe the exploitability of this vulnerability is low. Additionally, many users aren't putting sensitive data in HTTP request bodies, if this is the case then this vulnerability isn't exploitable. Both of the following conditions must be true to be affected by this vulnerability: 1. Using urllib3 and submitting sensitive information in the HTTP request body (such as form data or JSON) and 2. The origin service is compromised and starts redirecting using 301, 302, or 303 to a malicious peer or the redirected-to service becomes compromised. This issue has been addressed in versions 1.26.18 and 2.0.7 and users are advised to update to resolve this issue. Users unable to update should disable red=value
instead ofkey=value
. A vulnerable browser may allow a compromised application on an adjacent subdomain to exploit this to set a cookie like=__Host-test=bad
for another subdomain. Werkzeug prior to 2.2.3 will parse the cookie=__Host-test=bad
as __Host-test=bad`. If a Werkzeug application is running next to a vulnerable or malicious subdomain which sets such a cookie using a vulnerable browser, the Werkzeug application will see the bad cookie value but the valid cookie key. The issue is fixed in Werkzeug 2.2.3.