| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| The SSL protocol, as used in certain configurations in Microsoft Windows and Microsoft Internet Explorer, Mozilla Firefox, Google Chrome, Opera, and other products, encrypts data by using CBC mode with chained initialization vectors, which allows man-in-the-middle attackers to obtain plaintext HTTP headers via a blockwise chosen-boundary attack (BCBA) on an HTTPS session, in conjunction with JavaScript code that uses (1) the HTML5 WebSocket API, (2) the Java URLConnection API, or (3) the Silverlight WebClient API, aka a "BEAST" attack. |
| Race condition in the firmware for some Intel(R) Processors may allow a privileged user to potentially enable escalation of privilege via local access. |
| Out of bounds write in the firmware for some Intel(R) Processors may allow a privileged user to potentially enable denial of service via local access. |
| Improper initialization in the firmware for some Intel(R) Processors may allow a privileged user to potentially enable escalation of privilege via local access. |
| Out of bounds read in the firmware for some Intel(R) Processors may allow an authenticated user to potentially enable escalation of privilege via local access. |
| In the Linux kernel, the following vulnerability has been resolved:
tls: fix handling of zero-length records on the rx_list
Each recvmsg() call must process either
- only contiguous DATA records (any number of them)
- one non-DATA record
If the next record has different type than what has already been
processed we break out of the main processing loop. If the record
has already been decrypted (which may be the case for TLS 1.3 where
we don't know type until decryption) we queue the pending record
to the rx_list. Next recvmsg() will pick it up from there.
Queuing the skb to rx_list after zero-copy decrypt is not possible,
since in that case we decrypted directly to the user space buffer,
and we don't have an skb to queue (darg.skb points to the ciphertext
skb for access to metadata like length).
Only data records are allowed zero-copy, and we break the processing
loop after each non-data record. So we should never zero-copy and
then find out that the record type has changed. The corner case
we missed is when the initial record comes from rx_list, and it's
zero length. |
| In the Linux kernel, the following vulnerability has been resolved:
crypto: af_alg - Disallow concurrent writes in af_alg_sendmsg
Issuing two writes to the same af_alg socket is bogus as the
data will be interleaved in an unpredictable fashion. Furthermore,
concurrent writes may create inconsistencies in the internal
socket state.
Disallow this by adding a new ctx->write field that indiciates
exclusive ownership for writing. |
| In the Linux kernel, the following vulnerability has been resolved:
crypto: algif_aead - Revert to operating out-of-place
This mostly reverts commit 72548b093ee3 except for the copying of
the associated data.
There is no benefit in operating in-place in algif_aead since the
source and destination come from different mappings. Get rid of
all the complexity added for in-place operation and just copy the
AD directly. |
| A vulnerability has been identified in SIMATIC IoT2050 Advanced (6ES7647-0BA00-1YA2) (All versions < V4.3.4.1 running Industrial OS with Node-RED installed). Affected devices do not enforce authentication on the Node-RED HTTP interface, allowing unauthenticated access to programming nodes that are capable of executing system commands on the server.
This could allow an unauthenticated remote attacker to create malicious flows through the HTTP interface in order to execute arbitrary code on the underlying server with maximum privileges. |
| A vulnerability has been identified in SIMATIC S7-PLCSIM Advanced (All versions). Affected devices do not properly handle high-volume multicast network traffic, which can exhaust available memory resources in the affected application. This could allow an unauthenticated attacker on the local network segment to cause a denial-of-service condition of the affected application. The affected application becomes inaccessible and requires a manual restart; no project data is lost. Successful exploitation requires a specific project configuration to be already active on the targeted instance. |
| In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix oob access in cgroup local storage
Lonial reported that an out-of-bounds access in cgroup local storage
can be crafted via tail calls. Given two programs each utilizing a
cgroup local storage with a different value size, and one program
doing a tail call into the other. The verifier will validate each of
the indivial programs just fine. However, in the runtime context
the bpf_cg_run_ctx holds an bpf_prog_array_item which contains the
BPF program as well as any cgroup local storage flavor the program
uses. Helpers such as bpf_get_local_storage() pick this up from the
runtime context:
ctx = container_of(current->bpf_ctx, struct bpf_cg_run_ctx, run_ctx);
storage = ctx->prog_item->cgroup_storage[stype];
if (stype == BPF_CGROUP_STORAGE_SHARED)
ptr = &READ_ONCE(storage->buf)->data[0];
else
ptr = this_cpu_ptr(storage->percpu_buf);
For the second program which was called from the originally attached
one, this means bpf_get_local_storage() will pick up the former
program's map, not its own. With mismatching sizes, this can result
in an unintended out-of-bounds access.
To fix this issue, we need to extend bpf_map_owner with an array of
storage_cookie[] to match on i) the exact maps from the original
program if the second program was using bpf_get_local_storage(), or
ii) allow the tail call combination if the second program was not
using any of the cgroup local storage maps. |
| A vulnerability has been identified in SIMATIC WinCC Unified PC Runtime V16 (All versions), SIMATIC WinCC Unified PC Runtime V17 (All versions), SIMATIC WinCC Unified PC Runtime V18 (All versions), SIMATIC WinCC Unified PC Runtime V19 (All versions), SIMATIC WinCC Unified PC Runtime V20 (All versions), SIMATIC WinCC Unified PC Runtime V21 (All versions < V21 Update 2). Insufficient protection of key material in WinCC Certificate Manager that could allow an attacker to extract sensitive information. |
| A vulnerability has been identified in SIMATIC ET 200AL IM 157-1 PN (6ES7157-1AB00-0AB0) (All versions), SIMATIC ET 200MP IM 155-5 PN HF (6ES7155-5AA00-0AC0) (All versions >= V4.2.0), SIMATIC ET 200SP IM 155-6 MF HF (6ES7155-6MU00-0CN0) (All versions), SIMATIC ET 200SP IM 155-6 PN HA (incl. SIPLUS variants) (All versions < V1.3), SIMATIC ET 200SP IM 155-6 PN R1 (6ES7155-6AU00-0HM0) (All versions < V6.0.1), SIMATIC ET 200SP IM 155-6 PN/2 HF (6ES7155-6AU01-0CN0) (All versions >= V4.2.0 < V4.2.5), SIMATIC ET 200SP IM 155-6 PN/3 HF (6ES7155-6AU30-0CN0) (All versions < V4.2.2), SIMATIC PN/MF Coupler (6ES7158-3MU10-0XA0) (All versions), SIMATIC PN/PN Coupler (6ES7158-3AD10-0XA0) (All versions < V6.0.0), SIPLUS ET 200MP IM 155-5 PN HF (6AG1155-5AA00-2AC0) (All versions >= V4.2.0), SIPLUS ET 200MP IM 155-5 PN HF (6AG1155-5AA00-7AC0) (All versions >= V4.2.0), SIPLUS ET 200MP IM 155-5 PN HF T1 RAIL (6AG2155-5AA00-1AC0) (All versions >= V4.2.0), SIPLUS ET 200SP IM 155-6 PN HF (6AG1155-6AU01-2CN0) (All versions >= V4.2.0 < V4.2.5), SIPLUS ET 200SP IM 155-6 PN HF (6AG1155-6AU01-7CN0) (All versions >= V4.2.0 < V4.2.5), SIPLUS ET 200SP IM 155-6 PN HF T1 RAIL (6AG2155-6AU01-1CN0) (All versions >= V4.2.0 < V4.2.5), SIPLUS ET 200SP IM 155-6 PN HF TX RAIL (6AG2155-6AU01-4CN0) (All versions >= V4.2.0 < V4.2.5), SIPLUS NET PN/PN Coupler (6AG2158-3AD10-4XA0) (All versions < V6.0.0). Affected devices do not properly handle S7 protocol session disconnect requests. When receiving a valid S7 protocol Disconnect Request (COTP DR TPDU) on TCP port 102, the devices enter an improper session state.
This could allow an attacker to cause the device to become unresponsive, leading to a denial-of-service condition that requires a power cycle to restore normal operation. |
| A vulnerability has been identified in SIMATIC PCS neo V4.1 (All versions), SIMATIC PCS neo V5.0 (All versions), SIMATIC PCS neo V6.0 (All versions < V6.0 SP1 Update 1), User Management Component (UMC) (All versions < V2.15.1.3). Affected products contain a out-of-bounds read vulnerability in the integrated UMC component. This could allow an unauthenticated remote attacker to cause a denial of service condition. |
| A vulnerability has been identified in SIMATIC PCS neo V4.1 (All versions), SIMATIC PCS neo V5.0 (All versions), SIMATIC PCS neo V6.0 (All versions < V6.0 SP1 Update 1), User Management Component (UMC) (All versions < V2.15.1.3). Affected products contain a out-of-bounds read vulnerability in the integrated UMC component. This could allow an unauthenticated remote attacker to cause a denial of service condition. |
| A vulnerability has been identified in SIMATIC PCS neo V4.1 (All versions), SIMATIC PCS neo V5.0 (All versions), SIMATIC PCS neo V6.0 (All versions < V6.0 SP1 Update 1), User Management Component (UMC) (All versions < V2.15.1.3). Affected products contain a out-of-bounds read vulnerability in the integrated UMC component. This could allow an unauthenticated remote attacker to cause a denial of service condition. |
| A vulnerability has been identified in SIMATIC PCS neo V4.1 (All versions), SIMATIC PCS neo V5.0 (All versions), SIMATIC PCS neo V6.0 (All versions < V6.0 SP1 Update 1), User Management Component (UMC) (All versions < V2.15.1.3). Affected products contain a stack-based buffer overflow vulnerability in the integrated UMC component. This could allow an unauthenticated remote attacker to execute arbitrary code or to cause a denial of service condition. |
| A vulnerability has been identified in SIMATIC PCS neo V4.1 (All versions), SIMATIC PCS neo V5.0 (All versions), SIMATIC PCS neo V6.0 (All versions < V6.0 SP1 Update 1), SIMATIC S7-PLCSIM V17 (All versions), SIMATIC STEP 7 V17 (All versions < V17 Update 9), SIMATIC STEP 7 V18 (All versions), SIMATIC STEP 7 V19 (All versions < V19 Update 4), SIMATIC STEP 7 V20 (All versions < V20 Update 4), SIMATIC WinCC V17 (All versions < V17 Update 9), SIMATIC WinCC V18 (All versions), SIMATIC WinCC V19 (All versions < V19 Update 4), SIMATIC WinCC V20 (All versions < V20 Update 4), SIMOCODE ES V17 (All versions), SIMOCODE ES V18 (All versions), SIMOCODE ES V19 (All versions), SIMOCODE ES V20 (All versions), SIMOTION SCOUT TIA V5.4 (All versions), SIMOTION SCOUT TIA V5.5 (All versions), SIMOTION SCOUT TIA V5.6 (All versions < V5.6 SP1 HF7), SIMOTION SCOUT TIA V5.7 (All versions), SINAMICS Startdrive V17 (All versions), SINAMICS Startdrive V18 (All versions), SINAMICS Startdrive V19 (All versions), SINAMICS Startdrive V20 (All versions), SIRIUS Safety ES V17 (TIA Portal) (All versions), SIRIUS Safety ES V18 (TIA Portal) (All versions), SIRIUS Safety ES V19 (TIA Portal) (All versions), SIRIUS Safety ES V20 (TIA Portal) (All versions), SIRIUS Soft Starter ES V17 (TIA Portal) (All versions), SIRIUS Soft Starter ES V18 (TIA Portal) (All versions), SIRIUS Soft Starter ES V19 (TIA Portal) (All versions), SIRIUS Soft Starter ES V20 (TIA Portal) (All versions), TIA Portal Cloud V17 (All versions), TIA Portal Cloud V18 (All versions), TIA Portal Cloud V19 (All versions < V5.2.1.1), TIA Portal Cloud V20 (All versions < V5.2.2.2), TIA Portal Test Suite V20 (All versions < V20 Update 4). Affected products do not properly sanitize Interprocess Communication input received through a Windows Named Pipe accessible to all local users. This could allow an authenticated local attacker to cause a type confusion and execute arbitrary code within the affected application. |
| Issue summary: An OpenSSL TLS 1.3 server may fail to negotiate the expected
preferred key exchange group when its key exchange group configuration includes
the default by using the 'DEFAULT' keyword.
Impact summary: A less preferred key exchange may be used even when a more
preferred group is supported by both client and server, if the group
was not included among the client's initial predicated keyshares.
This will sometimes be the case with the new hybrid post-quantum groups,
if the client chooses to defer their use until specifically requested by
the server.
If an OpenSSL TLS 1.3 server's configuration uses the 'DEFAULT' keyword to
interpolate the built-in default group list into its own configuration, perhaps
adding or removing specific elements, then an implementation defect causes the
'DEFAULT' list to lose its 'tuple' structure, and all server-supported groups
were treated as a single sufficiently secure 'tuple', with the server not
sending a Hello Retry Request (HRR) even when a group in a more preferred tuple
was mutually supported.
As a result, the client and server might fail to negotiate a mutually supported
post-quantum key agreement group, such as 'X25519MLKEM768', if the client's
configuration results in only 'classical' groups (such as 'X25519' being the
only ones in the client's initial keyshare prediction).
OpenSSL 3.5 and later support a new syntax for selecting the most preferred TLS
1.3 key agreement group on TLS servers. The old syntax had a single 'flat'
list of groups, and treated all the supported groups as sufficiently secure.
If any of the keyshares predicted by the client were supported by the server
the most preferred among these was selected, even if other groups supported by
the client, but not included in the list of predicted keyshares would have been
more preferred, if included.
The new syntax partitions the groups into distinct 'tuples' of roughly
equivalent security. Within each tuple the most preferred group included among
the client's predicted keyshares is chosen, but if the client supports a group
from a more preferred tuple, but did not predict any corresponding keyshares,
the server will ask the client to retry the ClientHello (by issuing a Hello
Retry Request or HRR) with the most preferred mutually supported group.
The above works as expected when the server's configuration uses the built-in
default group list, or explicitly defines its own list by directly defining the
various desired groups and group 'tuples'.
No OpenSSL FIPS modules are affected by this issue, the code in question lies
outside the FIPS boundary.
OpenSSL 3.6 and 3.5 are vulnerable to this issue.
OpenSSL 3.6 users should upgrade to OpenSSL 3.6.2 once it is released.
OpenSSL 3.5 users should upgrade to OpenSSL 3.5.6 once it is released.
OpenSSL 3.4, 3.3, 3.0, 1.0.2 and 1.1.1 are not affected by this issue. |
| A vulnerability has been identified in SIMATIC CP 443-1 OPC UA (All versions), SIMATIC ET 200SP Open Controller CPU 1515SP PC2 (incl. SIPLUS variants) (All versions < V2.7), SIMATIC HMI Comfort Outdoor Panels 7" & 15" (incl. SIPLUS variants) (All versions < V15.1 Upd 4), SIMATIC HMI Comfort Panels 4" - 22" (incl. SIPLUS variants) (All versions < V15.1 Upd 4), SIMATIC HMI KTP Mobile Panels KTP400F, KTP700, KTP700F, KTP900 and KTP900F (All versions < V15.1 Upd 4), SIMATIC IPC DiagMonitor (All versions < V5.1.3), SIMATIC NET PC Software V13 (All versions), SIMATIC NET PC Software V14 (All versions < V14 SP1 Update 14), SIMATIC NET PC Software V15 (All versions), SIMATIC RF188C (All versions < V1.1.0), SIMATIC RF600R family (All versions < V3.2.1), SIMATIC S7-1500 CPU family (incl. related ET200 CPUs and SIPLUS variants) (All versions >= V2.5 < V2.6.1), SIMATIC S7-1500 Software Controller (All versions between V2.5 (including) and V2.7 (excluding)), SIMATIC WinCC OA (All versions < V3.15 P018), SIMATIC WinCC Runtime Advanced (All versions < V15.1 Upd 4), SINEC NMS (All versions < V1.0 SP1), SINEMA Server (All versions < V14 SP2), SINUMERIK OPC UA Server (All versions < V2.1), TeleControl Server Basic (All versions < V3.1.1). Specially crafted network packets sent to affected devices on port 4840/tcp could allow an unauthenticated remote attacker to cause a denial of service condition of the OPC communication or crash the device. The security vulnerability could be exploited by an attacker with network access to the affected systems. Successful exploitation requires no system privileges and no user interaction. An attacker could use the vulnerability to compromise availability of the OPC communication. |
