In NetX Duo version before 6.4.4, the component of Eclipse Foundation ThreadX, there was an incorrect bound check resulting it out by two out of bound read.
In Eclipse Foundation NextX Duo before 6.4.4, a module of ThreadX, the _nx_secure_tls_process_clienthello() function was missing length verification of
certain SSL/TLS client hello message: the ciphersuite length and
compression method length. In case of an attacker-crafted message with
values outside of the expected range, it could cause an out-of-bound
read.
In NetX Duo version before 6.4.4, the component of Eclipse Foundation ThreadX, there was a potential out of bound read in _nx_secure_tls_process_clienthello() because of a missing validation of PSK length provided in the user message.
In Eclipse ThreadX before 6.4.3, when memory protection is enabled, syscall parameters verification wasn't enough, allowing an attacker to obtain an arbitrary memory read/write.
In Eclipse ThreadX before version 6.4.3, the thread module has a setting of maximum priority. In some cases the check of that maximum priority wasn't performed, allowing, as a result, to obtain a thread with higher priority than expected and causing a possible denial of service.
In Eclipse ThreadX before version 6.4.3, an attacker can cause a denial of service (crash) by providing a pointer to a reserved or unmapped memory region. Vulnerable system calls had a check of pointers, but that check wasn't verifying whether the pointer is outside the module memory region.
In Eclipse Jetty, versions <=9.4.57, <=10.0.25, <=11.0.25, <=12.0.21, <=12.1.0.alpha2, an HTTP/2 client may trigger the server to send RST_STREAM frames, for example by sending frames that are malformed or that should not be sent in a particular stream state, therefore forcing the server to consume resources such as CPU and memory.
For example, a client can open a stream and then send WINDOW_UPDATE frames with window size increment of 0, which is illegal.
Per specification https://www.rfc-editor.org/rfc/rfc9113.html#name-window_update , the server should send a RST_STREAM frame.
The client can now open another stream and send another bad WINDOW_UPDATE, therefore causing the server to consume more resources than necessary, as this case does not exceed the max number of concurrent streams, yet the client is able to create an enormous amount of streams in a short period of time.
The attack can be performed with other conditions (for example, a DATA frame for a closed stream) that cause the server to send a RST_STREAM frame.
Links:
* https://github.com/jetty/jetty.project/security/advisories/GHSA-mmxm-8w33-wc4h
In Jakarta Mail versions prior to 2.0.2 it is possible to perform an SMTP Injection by utilizing theĀ \r and \n UTF-8 characters to separate different messages.
In Eclipse GlassFish version 7.0.15 is possible to perform Stored Cross-site Scripting
attacks by modifying the configuration file in the underlying operating system.