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
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
There is a type confusion vulnerability relating to X.400 address processing
inside an X.509 GeneralName. X.400 addresses were parsed as an ASN1_STRING but
the public structure definition for GENERAL_NAME incorrectly specified the type
of the x400Address field as ASN1_TYPE. This field is subsequently interpreted by
the OpenSSL function GENERAL_NAME_cmp as an ASN1_TYPE rather than an
ASN1_STRING.
When CRL checking is enabled (i.e. the application sets the
X509_V_FLAG_CRL_CHECK flag), this vulnerability may allow an attacker to pass
arbitrary pointers to a memcmp call, enabling them to read memory contents or
enact a denial of service. In most cases, the attack requires the attacker to
provide both the certificate chain and CRL, neither of which need to have a
valid signature. If the attacker only controls one of these inputs, the other
input must already contain an X.400 address as a CRL distribution point, which
is uncommon. As such, this vulnerability is most likely to only affect
applications which have implemented their own functionality for retrieving CRLs
over a network.
OpenSSL versions 3.0, 1.1.1 and 1.0.2 are vulnerable to this issue.
OpenSSL 3.0 users should upgrade to OpenSSL 3.0.8.
OpenSSL 1.1.1 users should upgrade to OpenSSL 1.1.1t.
OpenSSL 1.0.2 users should upgrade to OpenSSL 1.0.2zg (premium support customers
only).
This issue was reported on 11th January 2023 by David Benjamin (Google).
The fix was developed by Hugo Landau.
Affected range
<1.1.1t-r2
Fixed version
1.1.1t-r2
EPSS Score
0.17%
EPSS Percentile
55th percentile
Description
Affected range
<1.1.1q-r0
Fixed version
1.1.1q-r0
EPSS Score
0.85%
EPSS Percentile
83rd percentile
Description
Affected range
<1.1.1t-r0
Fixed version
1.1.1t-r0
EPSS Score
0.64%
EPSS Percentile
80th percentile
Description
The public API function BIO_new_NDEF is a helper function used for streaming
ASN.1 data via a BIO. It is primarily used internally to OpenSSL to support the
SMIME, CMS and PKCS7 streaming capabilities, but may also be called directly by
end user applications.
The function receives a BIO from the caller, prepends a new BIO_f_asn1 filter
BIO onto the front of it to form a BIO chain, and then returns the new head of
the BIO chain to the caller. Under certain conditions, for example if a CMS
recipient public key is invalid, the new filter BIO is freed and the function
returns a NULL result indicating a failure. However, in this case, the BIO chain
is not properly cleaned up and the BIO passed by the caller still retains
internal pointers to the previously freed filter BIO. If the caller then goes on
to call BIO_pop() on the BIO then a use-after-free will occur. This will most
likely result in a crash.
This scenario occurs directly in the internal function B64_write_ASN1() which
may cause BIO_new_NDEF() to be called and will subsequently call BIO_pop() on
the BIO. This internal function is in turn called by the public API functions
PEM_write_bio_ASN1_stream, PEM_write_bio_CMS_stream, PEM_write_bio_PKCS7_stream,
SMIME_write_ASN1, SMIME_write_CMS and SMIME_write_PKCS7.
Other public API functions that may be impacted by this include
i2d_ASN1_bio_stream, BIO_new_CMS, BIO_new_PKCS7, i2d_CMS_bio_stream and
i2d_PKCS7_bio_stream.
The OpenSSL cms and smime command line applications are similarly affected.
OpenSSL 3.0, 1.1.1 and 1.0.2 are vulnerable to this issue.
OpenSSL 3.0 users should upgrade to OpenSSL 3.0.8.
OpenSSL 1.1.1 users should upgrade to OpenSSL 1.1.1t.
OpenSSL 1.0.2 users should upgrade to OpenSSL 1.0.2zg (premium support customers
only).
This issue was reported on 29th November 2022 by Octavio Galland and
Marcel Böhme (Max Planck Institute for Security and Privacy). The fix was
developed by Viktor Dukhovni and Matt Caswell.
Affected range
<1.1.1t-r0
Fixed version
1.1.1t-r0
EPSS Score
0.17%
EPSS Percentile
55th percentile
Description
The function PEM_read_bio_ex() reads a PEM file from a BIO and parses and
decodes the "name" (e.g. "CERTIFICATE"), any header data and the payload data.
If the function succeeds then the "name_out", "header" and "data" arguments are
populated with pointers to buffers containing the relevant decoded data. The
caller is responsible for freeing those buffers. It is possible to construct a
PEM file that results in 0 bytes of payload data. In this case PEM_read_bio_ex()
will return a failure code but will populate the header argument with a pointer
to a buffer that has already been freed. If the caller also frees this buffer
then a double free will occur. This will most likely lead to a crash. This
could be exploited by an attacker who has the ability to supply malicious PEM
files for parsing to achieve a denial of service attack.
The functions PEM_read_bio() and PEM_read() are simple wrappers around
PEM_read_bio_ex() and therefore these functions are also directly affected.
These functions are also called indirectly by a number of other OpenSSL
functions including PEM_X509_INFO_read_bio_ex() and
SSL_CTX_use_serverinfo_file() which are also vulnerable. Some OpenSSL internal
uses of these functions are not vulnerable because the caller does not free the
header argument if PEM_read_bio_ex() returns a failure code. These locations
include the PEM_read_bio_TYPE() functions as well as the decoders introduced in
OpenSSL 3.0.
The OpenSSL asn1parse command line application is also impacted by this issue.
OpenSSL 3.0 and 1.1.1 are vulnerable to this issue.
OpenSSL 3.0 users should upgrade to OpenSSL 3.0.8.
OpenSSL 1.1.1 users should upgrade to OpenSSL 1.1.1t.
OpenSSL 1.0.2 is not affected by this issue.
This issue was discovered by CarpetFuzz and reported on 8th December 2022 by
Dawei Wang. The fix was developed by Kurt Roeckx and Matt Caswell.
Affected range
<1.1.1t-r0
Fixed version
1.1.1t-r0
EPSS Score
0.18%
EPSS Percentile
55th percentile
Description
A timing based side channel exists in the OpenSSL RSA Decryption implementation
which could be sufficient to recover a plaintext across a network in a
Bleichenbacher style attack. To achieve a successful decryption an attacker
would have to be able to send a very large number of trial messages for
decryption. The vulnerability affects all RSA padding modes: PKCS#1 v1.5,
RSA-OEAP and RSASVE.
For example, in a TLS connection, RSA is commonly used by a client to send an
encrypted pre-master secret to the server. An attacker that had observed a
genuine connection between a client and a server could use this flaw to send
trial messages to the server and record the time taken to process them. After a
sufficiently large number of messages the attacker could recover the pre-master
secret used for the original connection and thus be able to decrypt the
application data sent over that connection.
OpenSSL 3.0, 1.1.1 and 1.0.2 are vulnerable to this issue.
OpenSSL 3.0 users should upgrade to OpenSSL 3.0.8.
OpenSSL 1.1.1 users should upgrade to OpenSSL 1.1.1t.
OpenSSL 1.0.2 users should upgrade to OpenSSL 1.0.2zg (premium support customers
only).
An initial report of a possible timing side channel was made on 14th July 2020
by Hubert Kario (Red Hat). A refined report identifying a specific timing side
channel was made on 15th July 2022 by Hubert Kario.
The fix was developed by Dmitry Belyavsky (Red Hat) and Hubert Kario.
body-parser <1.20.3 is vulnerable to denial of service when url encoding is enabled. A malicious actor using a specially crafted payload could flood the server with a large number of requests, resulting in denial of service.
A bad regular expression is generated any time you have two parameters within a single segment, separated by something that is not a period (.). For example, /:a-:b.
Patches
For users of 0.1, upgrade to 0.1.10. All other users should upgrade to 8.0.0.
These versions add backtrack protection when a custom regex pattern is not provided:
They do not protect against vulnerable user supplied capture groups. Protecting against explicit user patterns is out of scope for old versions and not considered a vulnerability.
Version 7.1.0 can enable strict: true and get an error when the regular expression might be bad.
Version 8.0.0 removes the features that can cause a ReDoS.
Workarounds
All versions can be patched by providing a custom regular expression for parameters after the first in a single segment. As long as the custom regular expression does not match the text before the parameter, you will be safe. For example, change /:a-:b to /:a-:b([^-/]+).
If paths cannot be rewritten and versions cannot be upgraded, another alternative is to limit the URL length. For example, halving the attack string improves performance by 4x faster.
Details
Using /:a-:b will produce the regular expression /^\/([^\/]+?)-([^\/]+?)\/?$/. This can be exploited by a path such as /a${'-a'.repeat(8_000)}/a. OWASP has a good example of why this occurs, but the TL;DR is the /a at the end ensures this route would never match but due to naive backtracking it will still attempt every combination of the :a-:b on the repeated 8,000 -a.
Because JavaScript is single threaded and regex matching runs on the main thread, poor performance will block the event loop and can lead to a DoS. In local benchmarks, exploiting the unsafe regex will result in performance that is over 1000x worse than the safe regex. In a more realistic environment using Express v4 and 10 concurrent connections, this translated to average latency of ~600ms vs 1ms.
Improper Validation of Syntactic Correctness of Input
Affected range
<4.19.2
Fixed version
4.19.2
CVSS Score
6.1
CVSS Vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N
EPSS Score
0.04%
EPSS Percentile
11th percentile
Description
Impact
Versions of Express.js prior to 4.19.2 and pre-release alpha and beta versions before 5.0.0-beta.3 are affected by an open redirect vulnerability using malformed URLs.
When a user of Express performs a redirect using a user-provided URL Express performs an encode using encodeurl on the contents before passing it to the location header. This can cause malformed URLs to be evaluated in unexpected ways by common redirect allow list implementations in Express applications, leading to an Open Redirect via bypass of a properly implemented allow list.
The main method impacted is res.location() but this is also called from within res.redirect().
An initial fix went out with express@4.19.0, we then patched a feature regression in 4.19.1 and added improved handling for the bypass in 4.19.2.
Workarounds
The fix for this involves pre-parsing the url string with either require('node:url').parse or new URL. These are steps you can take on your own before passing the user input string to res.location or res.redirect.
In express <4.20.0, passing untrusted user input - even after sanitizing it - to response.redirect() may execute untrusted code
Patches
this issue is patched in express 4.20.0
Workarounds
users are encouraged to upgrade to the patched version of express, but otherwise can workaround this issue by making sure any untrusted inputs are safe, ideally by validating them against an explicit allowlist
Details
successful exploitation of this vector requires the following:
The attacker MUST control the input to response.redirect()
express MUST NOT redirect before the template appears
the browser MUST NOT complete redirection before:
the user MUST click on the link in the template
send0.17.2 (npm)
pkg:npm/send@0.17.2
Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
passing untrusted user input - even after sanitizing it - to SendStream.redirect() may execute untrusted code
Patches
this issue is patched in send 0.19.0
Workarounds
users are encouraged to upgrade to the patched version of express, but otherwise can workaround this issue by making sure any untrusted inputs are safe, ideally by validating them against an explicit allowlist
Details
successful exploitation of this vector requires the following:
The attacker MUST control the input to response.redirect()
express MUST NOT redirect before the template appears
the browser MUST NOT complete redirection before:
the user MUST click on the link in the template
serve-static1.14.2 (npm)
pkg:npm/serve-static@1.14.2
Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
passing untrusted user input - even after sanitizing it - to redirect() may execute untrusted code
Patches
this issue is patched in serve-static 1.16.0
Workarounds
users are encouraged to upgrade to the patched version of express, but otherwise can workaround this issue by making sure any untrusted inputs are safe, ideally by validating them against an explicit allowlist
Details
successful exploitation of this vector requires the following:
The attacker MUST control the input to response.redirect()
express MUST NOT redirect before the template appears
the browser MUST NOT complete redirection before:
the user MUST click on the link in the template
cookie0.4.2 (npm)
pkg:npm/cookie@0.4.2
Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')
Affected range
<0.7.0
Fixed version
0.7.0
EPSS Score
0.04%
EPSS Percentile
17th percentile
Description
Impact
The cookie name could be used to set other fields of the cookie, resulting in an unexpected cookie value. For example, serialize("userName=<script>alert('XSS3')</script>; Max-Age=2592000; a", value) would result in "userName=<script>alert('XSS3')</script>; Max-Age=2592000; a=test", setting userName cookie to <script> and ignoring value.
A similar escape can be used for path and domain, which could be abused to alter other fields of the cookie.
Patches
Upgrade to 0.7.0, which updates the validation for name, path, and domain.
Workarounds
Avoid passing untrusted or arbitrary values for these fields, ensure they are set by the application instead of user input.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.