SB2020081431 - Fedora 32 update for batik, ecj, eclipse, eclipse-cdt, eclipse-ecf, eclipse-emf, eclipse-gef, eclipse-m2e-core, eclipse-mpc, eclipse-mylyn, eclipse-remote, eclipse-webtools, jetty, lucene, univocity-parsers



SB2020081431 - Fedora 32 update for batik, ecj, eclipse, eclipse-cdt, eclipse-ecf, eclipse-emf, eclipse-gef, eclipse-m2e-core, eclipse-mpc, eclipse-mylyn, eclipse-remote, eclipse-webtools, jetty, lucene, univocity-parsers

Published: August 14, 2020 Updated: April 25, 2025

Security Bulletin ID SB2020081431
Severity
High
Patch available
YES
Number of vulnerabilities 2
Exploitation vector Remote access
Highest impact Code execution

Breakdown by Severity

High 50% Medium 50%
  • Low
  • Medium
  • High
  • Critical

Description

This security bulletin contains information about 2 secuirty vulnerabilities.


1) Server-Side Request Forgery (SSRF) (CVE-ID: CVE-2019-17566)

The disclosed vulnerability allows a remote attacker to perform SSRF attacks.

The vulnerability exists due to insufficient validation of "xlink:href" attributes. A remote attacker can send a specially crafted HTTP request and trick the application to initiate requests to arbitrary systems.

Successful exploitation of this vulnerability may allow a remote attacker gain access to sensitive data, located in the local network or send malicious requests to other servers from the vulnerable system.


2) Operation on a Resource after Expiration or Release (CVE-ID: CVE-2019-17638)

The vulnerability allows a remote non-authenticated attacker to #BASIC_IMPACT#.

In Eclipse Jetty, versions 9.4.27.v20200227 to 9.4.29.v20200521, in case of too large response headers, Jetty throws an exception to produce an HTTP 431 error. When this happens, the ByteBuffer containing the HTTP response headers is released back to the ByteBufferPool twice. Because of this double release, two threads can acquire the same ByteBuffer from the pool and while thread1 is about to use the ByteBuffer to write response1 data, thread2 fills the ByteBuffer with response2 data. Thread1 then proceeds to write the buffer that now contains response2 data. This results in client1, which issued request1 and expects responses, to see response2 which could contain sensitive data belonging to client2 (HTTP session ids, authentication credentials, etc.).


Remediation

Install update from vendor's website.