漏洞修复列表

OpenSSL

3.0.7

HWPSIRT-2023-38714

CVE-2023-5363

7.5

Issue summary: A bug has been identified in the processing of key and

initialisation vector (IV) lengths. This can lead to potential truncation

or overruns during the initialisation of some symmetric ciphers.

Impact summary: A truncation in the IV can result in non-uniqueness,

which could result in loss of confidentiality for some cipher modes.

When calling EVP_EncryptInit_ex2(), EVP_DecryptInit_ex2() or

EVP_CipherInit_ex2() the provided OSSL_PARAM array is processed after

the key and IV have been established. Any alterations to the key length,

via the "keylen" parameter or the IV length, via the "ivlen" parameter,

within the OSSL_PARAM array will not take effect as intended, potentially

causing truncation or overreading of these values. The following ciphers

and cipher modes are impacted: RC2, RC4, RC5, CCM, GCM and OCB.

For the CCM, GCM and OCB cipher modes, truncation of the IV can result in

loss of confidentiality. For example, when following NIST's SP 800-38D

section 8.2.1 guidance for constructing a deterministic IV for AES in

GCM mode, truncation of the counter portion could lead to IV reuse.

Both truncations and overruns of the key and overruns of the IV will

produce incorrect results and could, in some cases, trigger a memory

exception. However, these issues are not currently assessed as security

critical.

Changing the key and/or IV lengths is not considered to be a common operation

and the vulnerable API was recently introduced. Furthermore it is likely that

application developers will have spotted this problem during testing since

decryption would fail unless both peers in the communication were similarly

vulnerable. For these reasons we expect the probability of an application being

vulnerable to this to be quite low. However if an application is vulnerable then

this issue is considered very serious. For these reasons we have assessed this

issue as Moderate severity overall.

The OpenSSL SSL/TLS implementation is not affected by this issue.

The OpenSSL 3.0 and 3.1 FIPS providers are not affected by this because

the issue lies outside of the FIPS provider boundary.

OpenSSL 3.1 and 3.0 are vulnerable to this issue.

MindStudio 6.0.0

urllib3

1.26.12

HWPSIRT-2023-85332

CVE-2023-43804

8.1

urllib3 is a user-friendly HTTP client library for Python. urllib3 doesn't treat the `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 a `Cookie` 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.

MindStudio 6.0.0

urllib3

1.26.2

HWPSIRT-2023-85332

CVE-2023-43804

8.1

urllib3 is a user-friendly HTTP client library for Python. urllib3 doesn't treat the `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 a `Cookie` 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.

MindStudio 6.0.0

urllib3

1.26.7

HWPSIRT-2023-85332

CVE-2023-43804

8.1

urllib3 is a user-friendly HTTP client library for Python. urllib3 doesn't treat the `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 a `Cookie` 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.

MindStudio 6.0.0

OpenSSL

1.1.1n

HWPSIRT-2023-97265

CVE-2023-5678

5.3

Issue summary: Generating excessively long X9.42 DH keys or checking

excessively long X9.42 DH keys or parameters may be very slow.

Impact summary: Applications that use the functions DH_generate_key() to

generate an X9.42 DH key may experience long delays. Likewise, applications

that use DH_check_pub_key(), DH_check_pub_key_ex() or EVP_PKEY_public_check()

to check an X9.42 DH key or X9.42 DH parameters may experience long delays.

Where the key or parameters that are being checked have been obtained from

an untrusted source this may lead to a Denial of Service.

While DH_check() performs all the necessary checks (as of CVE-2023-3817),

DH_check_pub_key() doesn't make any of these checks, and is therefore

vulnerable for excessively large P and Q parameters.

Likewise, while DH_generate_key() performs a check for an excessively large

P, it doesn't check for an excessively large Q.

An application that calls DH_generate_key() or DH_check_pub_key() and

supplies a key or parameters obtained from an untrusted source could be

vulnerable to a Denial of Service attack.

DH_generate_key() and DH_check_pub_key() are also called by a number of

other OpenSSL functions. An application calling any of those other

functions may similarly be affected. The other functions affected by this

are DH_check_pub_key_ex(), EVP_PKEY_public_check(), and EVP_PKEY_generate().

Also vulnerable are the OpenSSL pkey command line application when using the

"-pubcheck" option, as well as the OpenSSL genpkey command line application.

The OpenSSL SSL/TLS implementation is not affected by this issue.

The OpenSSL 3.0 and 3.1 FIPS providers are not affected by this issue.

MindStudio 6.0.0

OpenSSL

3.0.7

HWPSIRT-2023-97265

CVE-2023-5678

7.5

Issue summary: Generating excessively long X9.42 DH keys or checking

excessively long X9.42 DH keys or parameters may be very slow.

Impact summary: Applications that use the functions DH_generate_key() to

generate an X9.42 DH key may experience long delays. Likewise, applications

that use DH_check_pub_key(), DH_check_pub_key_ex() or EVP_PKEY_public_check()

to check an X9.42 DH key or X9.42 DH parameters may experience long delays.

Where the key or parameters that are being checked have been obtained from

an untrusted source this may lead to a Denial of Service.

While DH_check() performs all the necessary checks (as of CVE-2023-3817),

DH_check_pub_key() doesn't make any of these checks, and is therefore

vulnerable for excessively large P and Q parameters.

Likewise, while DH_generate_key() performs a check for an excessively large

P, it doesn't check for an excessively large Q.

An application that calls DH_generate_key() or DH_check_pub_key() and

supplies a key or parameters obtained from an untrusted source could be

vulnerable to a Denial of Service attack.

DH_generate_key() and DH_check_pub_key() are also called by a number of

other OpenSSL functions. An application calling any of those other

functions may similarly be affected. The other functions affected by this

are DH_check_pub_key_ex(), EVP_PKEY_public_check(), and EVP_PKEY_generate().

Also vulnerable are the OpenSSL pkey command line application when using the

"-pubcheck" option, as well as the OpenSSL genpkey command line application.

The OpenSSL SSL/TLS implementation is not affected by this issue.

The OpenSSL 3.0 and 3.1 FIPS providers are not affected by this issue.

MindStudio 6.0.0

urllib3

1.26.12

HWPSIRT-2023-97271

CVE-2023-45803

4.2

urllib3 is a user-friendly HTTP client library for Python. urllib3 previously wouldn't remove the HTTP request body when an HTTP redirect response using status 301, 302, or 303 after the request had its method changed from one that could accept a request body (like `POST`) to `GET` 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 redirects for services that aren't expecting to respond with redirects with `redirects=False` and disable automatic redirects with `redirects=False` and handle 301, 302, and 303 redirects manually by stripping the HTTP request body.

MindStudio 6.0.0

urllib3

1.26.2

HWPSIRT-2023-97271

CVE-2023-45803

4.2

urllib3 is a user-friendly HTTP client library for Python. urllib3 previously wouldn't remove the HTTP request body when an HTTP redirect response using status 301, 302, or 303 after the request had its method changed from one that could accept a request body (like `POST`) to `GET` 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 redirects for services that aren't expecting to respond with redirects with `redirects=False` and disable automatic redirects with `redirects=False` and handle 301, 302, and 303 redirects manually by stripping the HTTP request body.

MindStudio 6.0.0

urllib3

1.26.7

HWPSIRT-2023-97271

CVE-2023-45803

4.2

urllib3 is a user-friendly HTTP client library for Python. urllib3 previously wouldn't remove the HTTP request body when an HTTP redirect response using status 301, 302, or 303 after the request had its method changed from one that could accept a request body (like `POST`) to `GET` 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 redirects for services that aren't expecting to respond with redirects with `redirects=False` and disable automatic redirects with `redirects=False` and handle 301, 302, and 303 redirects manually by stripping the HTTP request body.

MindStudio 6.0.0

pip

21.3.1

HWPSIRT-2023-99080

CVE-2023-5752

3.3

When installing a package from a Mercurial VCS URL (ie "pip install

hg+...") with pip prior to v23.3, the specified Mercurial revision could

be used to inject arbitrary configuration options to the "hg clone"

call (ie "--config"). Controlling the Mercurial configuration can modify

how and which repository is installed. This vulnerability does not

affect users who aren't installing from Mercurial.

MindStudio 6.0.0

pip

22.3.1

HWPSIRT-2023-99080

CVE-2023-5752

3.3

When installing a package from a Mercurial VCS URL (ie "pip install

hg+...") with pip prior to v23.3, the specified Mercurial revision could

be used to inject arbitrary configuration options to the "hg clone"

call (ie "--config"). Controlling the Mercurial configuration can modify

how and which repository is installed. This vulnerability does not

affect users who aren't installing from Mercurial.

MindStudio 6.0.0

pip

20.3.4

HWPSIRT-2023-99080

CVE-2023-5752

3.3

When installing a package from a Mercurial VCS URL (ie "pip install

hg+...") with pip prior to v23.3, the specified Mercurial revision could

be used to inject arbitrary configuration options to the "hg clone"

call (ie "--config"). Controlling the Mercurial configuration can modify

how and which repository is installed. This vulnerability does not

affect users who aren't installing from Mercurial.

MindStudio 6.0.0