Tremor is an event processing system for unstructured data. A vulnerability exists between versions 0.7.2 and 0.11.6. This vulnerability is…
GitHub_M·CWE-416·Published 2021-09-17
Tremor is an event processing system for unstructured data. A vulnerability exists between versions 0.7.2 and 0.11.6. This vulnerability is a memory safety Issue when using `patch` or `merge` on `state` and assign the result back to `state`. In this case, affected versions of Tremor and the tremor-script crate maintains references to memory that might have been freed already. And these memory regions can be accessed by retrieving the `state`, e.g. send it over TCP or HTTP. This requires the Tremor server (or any other program using tremor-script) to execute a tremor-script script that uses the mentioned language construct. The issue has been patched in version 0.11.6 by removing the optimization and always cloning the target expression of a Merge or Patch. If an upgrade is not possible, a possible workaround is to avoid the optimization by introducing a temporary variable and not immediately reassigning to `state`.
Tremor is an event processing system for unstructured data. A vulnerability exists between versions 0.7.2 and 0.11.6. This vulnerability is a memory safety Issue when using `patch` or `merge` on `state` and assign the result back to `state`. In this case, affected versions of Tremor and the tremor-script crate maintains references to memory that might have been freed already. And these memory regions can be accessed by retrieving the `state`, e.g. send it over TCP or HTTP. This requires the Tremor server (or any other program using tremor-script) to execute a tremor-script script that uses the mentioned language construct. The issue has been patched in version 0.11.6 by removing the optimization and always cloning the target expression of a Merge or Patch. If an upgrade is not possible, a possible workaround is to avoid the optimization by introducing a temporary variable and not immediately reassigning to `state`.
### Impact This vulnerability is a memory safety Issue when using [`patch`](https://www.tremor.rs/docs/tremor-script/index#patch) or [`merge`](https://www.tremor.rs/docs/tremor-script/index#merge) on `state` and assign the result back to `state`. In this case affected versions of Tremor and the [tremor-script crate](https://crates.io/crates/tremor-script) maintains references to memory that might have been freed already. And these memory regions can be accessed by retrieving the `state`, e.g. send it over TCP or HTTP. This requires the Tremor server (or any other program using tremor-script) to execute a tremor-script script that uses the mentioned language construct. #### Details If affects the following two tremor-script language constructs: * A [Merge](https://www.tremor.rs/docs/tremor-script/index#merge) where we assign the result back to the target expression and the expression to be merged needs to reference the `event`: ``` let state = merge state of event end; ``` * A [Patch](https://www.tremor.rs/docs/tremor-script/index#patch) where we assign the result back to the target expression and the patch operations used need to reference the `event`: ``` let state = patch state of insert event.key => event.value end; ``` For constructs like this (it does not matter what it references in the expression to be merged or the patch operations) an optimization was applied to manipulate the target value in-place, instead of cloning it. Our `Value` struct, which underpins all event data in `tremor-script`, is representing strings as borrowed `beef::Cow<'lifetime, str>`, that reference the raw data `Vec<u8>` the event is based upon. We keep this raw byte-array next to the `Value` structure inside our `Event` as a self-referential struct, so we make sure that the structured `Value` and its references are valid across its whole lifetime. The optimization was considered safe as long as it was only possible to merge or patch `event` data or static data. When `state` was introduced to `tremor-script` (in version 0.7.3) a new possibility to keep `Value` data around for longer than the lifetime of an event emerged. If `event` data is merged or patched into `state` without cloning it first, it can still reference keys or values from the previous event, which will now be invalid. This allows access to those already freed regions of memory and to get their content out over the wire. ### Patches The issue has been patched in https://crates.io/crates/tremor-script/0.11.6 and https://github.com/tremor-rs/tremor-runtime/releases/tag/v0.11.6 via commit [1a2efcd](https://github.com/tremor-rs/tremor-runtime/commit/1a2efcdbe68e5e7fd0a05836ac32d2cde78a0b2e) by removing the optimization and always clone the target expression of a [Merge](https://www.tremor.rs/docs/tremor-script/index#merge) or [Patch](https://www.tremor.rs/docs/tremor-script/index#patch. ### Workarounds If an upgrade is not possible, a possible workaround is to avoid the optimization by introducing a temporary variable and not immediately reassigning to `state`: ``` let tmp = merge state of event end; let state = tmp ``` ### References The actual fix is applied in this PR: https://github.com/tremor-rs/tremor-runtime/pull/1217 ### For more information If you have any questions or comments about this advisory: * Open an issue on our repository [tremor-rs/tremor-runtime](https://github.com/tremor-rs/tremor-runtime) * Please join our discord https://chat.tremor.rs and reach out to the team.
### Impact This vulnerability is a memory safety Issue when using [`patch`](https://www.tremor.rs/docs/tremor-script/index#patch) or [`merge`](https://www.tremor.rs/docs/tremor-script/index#merge) on `state` and assign the result back to `state`. In this case affected versions of Tremor and the [tremor-script crate](https://crates.io/crates/tremor-script) maintains references to memory that might have been freed already. And these memory regions can be accessed by retrieving the `state`, e.g. send it over TCP or HTTP. This requires the Tremor server (or any other program using tremor-script) to execute a tremor-script script that uses the mentioned language construct. #### Details If affects the following two tremor-script language constructs: * A [Merge](https://www.tremor.rs/docs/tremor-script/index#merge) where we assign the result back to the target expression and the expression to be merged needs to reference the `event`: ``` let state = merge state of event end; ``` * A [Patch](https://www.tremor.rs/docs/tremor-script/index#patch) where we assign the result back to the target expression and the patch operations used need to reference the `event`: ``` let state = patch state of insert event.key => event.value end; ``` For constructs like this (it does not matter what it references in the expression to be merged or the patch operations) an optimization was applied to manipulate the target value in-place, instead of cloning it. Our `Value` struct, which underpins all event data in `tremor-script`, is representing strings as borrowed `beef::Cow<'lifetime, str>`, that reference the raw data `Vec<u8>` the event is based upon. We keep this raw byte-array next to the `Value` structure inside our `Event` as a self-referential struct, so we make sure that the structured `Value` and its references are valid across its whole lifetime. The optimization was considered safe as long as it was only possible to merge or patch `event` data or static data. When `state` was introduced to `tremor-script` (in version 0.7.3) a new possibility to keep `Value` data around for longer than the lifetime of an event emerged. If `event` data is merged or patched into `state` without cloning it first, it can still reference keys or values from the previous event, which will now be invalid. This allows access to those already freed regions of memory and to get their content out over the wire. ### Patches The issue has been patched in https://crates.io/crates/tremor-script/0.11.6 and https://github.com/tremor-rs/tremor-runtime/releases/tag/v0.11.6 via commit [1a2efcd](https://github.com/tremor-rs/tremor-runtime/commit/1a2efcdbe68e5e7fd0a05836ac32d2cde78a0b2e) by removing the optimization and always clone the target expression of a [Merge](https://www.tremor.rs/docs/tremor-script/index#merge) or [Patch](https://www.tremor.rs/docs/tremor-script/index#patch. ### Workarounds If an upgrade is not possible, a possible workaround is to avoid the optimization by introducing a temporary variable and not immediately reassigning to `state`: ``` let tmp = merge state of event end; let state = tmp ``` ### References The actual fix is applied in this PR: https://github.com/tremor-rs/tremor-runtime/pull/1217 ### For more information If you have any questions or comments about this advisory: * Open an issue on our repository [tremor-rs/tremor-runtime](https://github.com/tremor-rs/tremor-runtime) * Please join our discord https://chat.tremor.rs and reach out to the team.
Tremor es un sistema de procesamiento de eventos para datos no estructurados. Se presenta una vulnerabilidad entre las versiones 0.7.2 y 0.11.6. Esta vulnerabilidad es un problema de seguridad de memoria cuando es usado "patch" o "merge" en "state" y se asigna el resultado de nuevo a "state". En este caso, las versiones afectadas de Tremor y el crate tremor-script mantienen referencias a la memoria que podrían haber sido liberadas ya. Y estas regiones de memoria pueden ser accedidas al recuperar el "state", por ejemplo, enviándolo por TCP o HTTP. Esto requiere que el servidor Tremor (o cualquier otro programa usando tremor-script) ejecute un script tremor-script que use la construcción de lenguaje mencionada. El problema ha sido parcheado en la versión 0.11.6, al eliminar la optimización y clonando siempre la expresión de destino de una Fusión o Parche. Si no es posible una actualización, una posible solución es evitar la optimización introduciendo una variable temporal y no reasignando inmediatamente a "state"
| Version | Type | Source | Base | Exp | Impact | Vector |
|---|---|---|---|---|---|---|
| 2.0 | Primary | NVD | 7.5 | 10.0 | 6.4 | AV:N/AC:L/Au:N/C:P/I:P/A:P |
| 3.1 | Primary | NVD | 9.8 | 3.9 | 5.9 | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H |
| 3.1 | Primary | cve.org | 6.5 | — | — | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N |
| 3.1 | Primary | cve.org | 6.5 | — | — | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N |
| 3.1 | Secondary | NVD | 6.5 | 3.9 | 2.5 | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N |
| 3.1 | Secondary | GHSA | 6.5 | — | — | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N |