GHSA-8mv5-7x95-7wcf – mopa

Package

Manager: cargo
Name: mopa
Vulnerable Version: >=0 <=0.2.2

Severity

Level: High

CVSS v3.1: CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N/E:P/RL:O/RC:R

CVSS v4.0: CVSS:4.0/AV:N/AC:H/AT:N/PR:L/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N

EPSS: N/A pctlN/A

Details

`mopa` is technically unsound The `mopa` crate redefines the deprecated `TraitObject` struct from `core::raw` like so: ```rust #[repr(C)] #[derive(Copy, Clone)] #[doc(hidden)] pub struct TraitObject { pub data: *mut (), pub vtable: *mut (), } ``` This is done to then transmute a reference to a trait object (`&dyn Trait` for any trait `Trait`) into this struct and retrieve the `data` field for the purpose of downcasting. This is used to implement `downcast_ref_unchecked()`, in terms of which `downcast_ref()` is also implemented. Same goes for mutable reference downcasting and `Box` downcasting. The Rust compiler explicitly reserves the right to change the memory layout of `&dyn Trait` for any trait `Trait`. The worst case scenario is that it swaps `data` and `vtable`, making an executable location breach and compromisation of ASLR possible, since reads from `data` would read `vtable` instead. Likewise, arbitrary code execution is also theoretically possible if reads of `vtable` generated by the compiler read `data` instead. While, as of Rust 1.52, this unsound assumption still holds true, updating the compiler may silently create UB in a crate which previously compiled and run without issues, compromising the security of builds which are believed to be reproducible. A potential strategy to resolve this has already been suggested in an issue on the GitHub repository of the crate.

Metadata

Created: 2022-06-17T00:12:33Z
Modified: 2023-06-13T18:35:51Z
Source: https://github.com/github/advisory-database/blob/main/advisories/github-reviewed/2022/06/GHSA-8mv5-7x95-7wcf/GHSA-8mv5-7x95-7wcf.json
CWE IDs: []
Alternative ID: N/A
Finding: F138
Auto approve: 1