Dragonfly is an open source P2P-based file distribution and image acceleration system. Versions prior to 2.1.0 contain a server-side request forgery (SSRF) vulnerability that enables users to force DragonFly2’s components to make requests to internal services that are otherwise not accessible to them. The issue arises because the Manager API accepts a user-supplied URL when creating a Preheat job with weak validation, peers can trigger other peers to fetch an arbitrary URL through pieceManager.DownloadSource, and internal HTTP clients follow redirects, allowing a request to a malicious server to be redirected to internal services. This can be used to probe or access internal HTTP endpoints. The vulnerability is fixed in version 2.1.0.
Dragonfly is an open source P2P-based file distribution and image acceleration system. Prior to 2.1.0, The Manager disables TLS certificate verification in HTTP clients. The clients are not configurable, so users have no way to re-enable the verification. A Manager processes dozens of preheat jobs. An adversary performs a network-level Man-in-the-Middle attack, providing invalid data to the Manager. The Manager preheats with the wrong data, which later causes a denial of service and file integrity problems. This vulnerability is fixed in 2.1.0.
Dragonfly is an open source P2P-based file distribution and image acceleration system. Prior to 2.1.0, The /api/v1/jobs and /preheats endpoints in Manager web UI are accessible without authentication. Any user with network access to the Manager can create, delete, and modify jobs, and create preheat jobs. An unauthenticated adversary with network access to a Manager web UI uses /api/v1/jobs endpoint to create hundreds of useless jobs. The Manager is in a denial-of-service state, and stops accepting requests from valid administrators. This vulnerability is fixed in 2.1.0.
In monitor_hang, there is a possible memory corruption due to use after free. This could lead to local escalation of privilege if a malicious actor has already obtained the System privilege. User interaction is not needed for exploitation. Patch ID: ALPS09989078; Issue ID: MSV-3964.
In DA, there is a possible out of bounds write due to a missing bounds check. This could lead to local escalation of privilege, if an attacker has physical access to the device, with no additional execution privileges needed. User interaction is needed for exploitation. Patch ID: ALPS09915215; Issue ID: MSV-3801.
MaterialX is an open standard for the exchange of rich material and look-development content across applications and renderers. In versions 1.39.2 and below, when parsing an MTLX file with multiple nested nodegraph implementations, the MaterialX XML parsing logic can potentially crash due to stack exhaustion. An attacker could intentionally crash a target program that uses OpenEXR by sending a malicious MTLX file. This is fixed in version 1.39.3.
MaterialX is an open standard for the exchange of rich material and look-development content across applications and renderers. In version 1.39.2, when parsing shader nodes in a MTLX file, the MaterialXCore code accesses a potentially null pointer, which can lead to crashes with maliciously crafted files. An attacker could intentionally crash a target program that uses OpenEXR by sending a malicious MTLX file. This is fixed in version 1.39.3.
MaterialX is an open standard for the exchange of rich material and look-development content across applications and renderers. In version 1.39.2, when parsing shader nodes in a MTLX file, the MaterialXCore code accesses a potentially null pointer, which can lead to crashes with maliciously crafted files. An attacker could intentionally crash a target program that uses MaterialX by sending a malicious MTLX file. This is fixed in version 1.39.3.
MaterialX is an open standard for the exchange of rich material and look-development content across applications and renderers. In version 1.39.2, nested imports of MaterialX files can lead to a crash via stack memory exhaustion, due to the lack of a limit on the "import chain" depth. When parsing file imports, recursion is used to process nested files; however, there is no limit imposed to the depth of files that can be parsed by the library. By building a sufficiently deep chain of MaterialX files one referencing the next, it is possible to crash the process using the MaterialX library via stack exhaustion. This is fixed in version 1.39.3.