Wasmtime is a standalone runtime for WebAssembly. Prior to versions 6.0.2, 7.0.1, and 8.0.1, Wasmtime's implementation of managing per-instance state, such as tables and memories, contains LLVM-level undefined behavior. This undefined behavior was found to cause runtime-level issues when compiled with LLVM 16 which causes some writes, which are critical for correctness, to be optimized away. Vulnerable versions of Wasmtime compiled with Rust 1.70, which is currently in beta, or later are known to have incorrectly compiled functions. Versions of Wasmtime compiled with the current Rust stable release, 1.69, and prior are not known at this time to have any issues, but can theoretically exhibit potential issues. The underlying problem is that Wasmtime's runtime state for an instance involves a Rust-defined structure called `Instance` which has a trailing `VMContext` structure after it. This `VMContext` structure has a runtime-defined layout that is unique per-module. This representation cannot be expressed with safe code in Rust so `unsafe` code is required to maintain this state. The code doing this, however, has methods which take `&self` as an argument but modify data in the `VMContext` part of the allocation. This means that pointers derived from `&self` are mutated. This is typically not allowed, except in the presence of `UnsafeCell`, in Rust. When compiled to LLVM these functions have `noalias readonly` parameters which means it's UB to write through the pointers. Wasmtime's internal representation and management of `VMContext` has been updated to use `&mut self` methods where appropriate. Additionally verification tools for `unsafe` code in Rust, such as `cargo miri`, are planned to be executed on the `main` branch soon to fix any Rust-level issues that may be exploited in future compiler versions. Precomplied binaries available for Wasmtime from GitHub releases have been compiled with at most LLVM 15 so are not known to be vulnerable. As mentioned above, however, it's still recommended to update. Wasmtime version 6.0.2, 7.0.1, and 8.0.1 have been issued which contain the patch necessary to work correctly on LLVM 16 and have no known UB on LLVM 15 and earlier. If Wasmtime is compiled with Rust 1.69 and prior, which use LLVM 15, then there are no known issues. There is a theoretical possibility for undefined behavior to exploited, however, so it's recommended that users upgrade to a patched version of Wasmtime. Users using beta Rust (1.70 at this time) or nightly Rust (1.71 at this time) must update to a patched version to work correctly.

The version of ecs-service-connect-agent installed on the remote host is prior to v1.27.0.0-1. It is, therefore, affected by multiple vulnerabilities as referenced in the ALAS2ECS-2023-007 advisory.

  - Wasmtime is a standalone runtime for WebAssembly. Prior to versions 6.0.2, 7.0.1, and 8.0.1, Wasmtime's     implementation of managing per-instance state, such as tables and memories, contains LLVM-level undefined     behavior. This undefined behavior was found to cause runtime-level issues when compiled with LLVM 16 which     causes some writes, which are critical for correctness, to be optimized away. Vulnerable versions of     Wasmtime compiled with Rust 1.70, which is currently in beta, or later are known to have incorrectly     compiled functions. Versions of Wasmtime compiled with the current Rust stable release, 1.69, and prior     are not known at this time to have any issues, but can theoretically exhibit potential issues. The     underlying problem is that Wasmtime's runtime state for an instance involves a Rust-defined structure     called `Instance` which has a trailing `VMContext` structure after it. This `VMContext` structure has a     runtime-defined layout that is unique per-module. This representation cannot be expressed with safe code     in Rust so `unsafe` code is required to maintain this state. The code doing this, however, has methods     which take `&self` as an argument but modify data in the `VMContext` part of the allocation. This means     that pointers derived from `&self` are mutated. This is typically not allowed, except in the presence of     `UnsafeCell`, in Rust. When compiled to LLVM these functions have `noalias readonly` parameters which     means it's UB to write through the pointers. Wasmtime's internal representation and management of     `VMContext` has been updated to use `&mut self` methods where appropriate. Additionally verification tools     for `unsafe` code in Rust, such as `cargo miri`, are planned to be executed on the `main` branch soon to     fix any Rust-level issues that may be exploited in future compiler versions. Precomplied binaries     available for Wasmtime from GitHub releases have been compiled with at most LLVM 15 so are not known to be     vulnerable. As mentioned above, however, it's still recommended to update. Wasmtime version 6.0.2, 7.0.1,     and 8.0.1 have been issued which contain the patch necessary to work correctly on LLVM 16 and have no     known UB on LLVM 15 and earlier. If Wasmtime is compiled with Rust 1.69 and prior, which use LLVM 15, then     there are no known issues. There is a theoretical possibility for undefined behavior to exploited,     however, so it's recommended that users upgrade to a patched version of Wasmtime. Users using beta Rust     (1.70 at this time) or nightly Rust (1.71 at this time) must update to a patched version to work     correctly. (CVE-2023-30624)

  - c-ares is an asynchronous resolver library. When cross-compiling c-ares and using the autotools build     system, CARES_RANDOM_FILE will not be set, as seen when cross compiling aarch64 android. This will     downgrade to using rand() as a fallback which could allow an attacker to take advantage of the lack of     entropy by not using a CSPRNG. This issue was patched in version 1.19.1. (CVE-2023-31124)

  - c-ares is an asynchronous resolver library. ares_inet_net_pton() is vulnerable to a buffer underflow for     certain ipv6 addresses, in particular 0::00:00:00/2 was found to cause an issue. C-ares only uses this     function internally for configuration purposes which would require an administrator to configure such an     address via ares_set_sortlist(). However, users may externally use ares_inet_net_pton() for other purposes     and thus be vulnerable to more severe issues. This issue has been fixed in 1.19.1. (CVE-2023-31130)

  - c-ares is an asynchronous resolver library. When /dev/urandom or RtlGenRandom() are unavailable, c-ares     uses rand() to generate random numbers used for DNS query ids. This is not a CSPRNG, and it is also not     seeded by srand() so will generate predictable output. Input from the random number generator is fed into     a non-compilant RC4 implementation and may not be as strong as the original RC4 implementation. No attempt     is made to look for modern OS-provided CSPRNGs like arc4random() that is widely available. This issue has     been fixed in version 1.19.1. (CVE-2023-31147)

  - c-ares is an asynchronous resolver library. c-ares is vulnerable to denial of service. If a target     resolver sends a query, the attacker forges a malformed UDP packet with a length of 0 and returns them to     the target resolver. The target resolver erroneously interprets the 0 length as a graceful shutdown of the     connection. This issue has been patched in version 1.19.1. (CVE-2023-32067)

  - Envoy is an open source edge and service proxy designed for cloud-native applications. Prior to versions     1.27.0, 1.26.4, 1.25.9, 1.24.10, and 1.23.12, a malicious client is able to construct credentials with     permanent validity in some specific scenarios. This is caused by the some rare scenarios in which HMAC     payload can be always valid in OAuth2 filter's check. Versions 1.27.0, 1.26.4, 1.25.9, 1.24.10, and     1.23.12 have a fix for this issue. As a workaround, avoid wildcards/prefix domain wildcards in the host's     domain configuration. (CVE-2023-35941)

  - Envoy is an open source edge and service proxy designed for cloud-native applications. Prior to versions     1.27.0, 1.26.4, 1.25.9, 1.24.10, and 1.23.12, gRPC access loggers using listener's global scope can cause     a `use-after-free` crash when the listener is drained. Versions 1.27.0, 1.26.4, 1.25.9, 1.24.10, and     1.23.12 have a fix for this issue. As a workaround, disable gRPC access log or stop listener update.
    (CVE-2023-35942)

  - Envoy is an open source edge and service proxy designed for cloud-native applications. Prior to versions     1.27.0, 1.26.4, 1.25.9, 1.24.10, and 1.23.12, the CORS filter will segfault and crash Envoy when the     `origin` header is removed and deleted between `decodeHeaders`and `encodeHeaders`. Versions 1.27.0,     1.26.4, 1.25.9, 1.24.10, and 1.23.12 have a fix for this issue. As a workaround, do not remove the     `origin` header in the Envoy configuration. (CVE-2023-35943)

  - Envoy is an open source edge and service proxy designed for cloud-native applications. Envoy allows mixed-     case schemes in HTTP/2, however, some internal scheme checks are case-sensitive. Prior to versions 1.27.0,     1.26.4, 1.25.9, 1.24.10, and 1.23.12, this can lead to the rejection of requests with mixed-case schemes     such as `htTp` or `htTps`, or the bypassing of some requests such as `https` in unencrypted connections.
    With a fix in versions 1.27.0, 1.26.4, 1.25.9, 1.24.10, and 1.23.12, Envoy will now lowercase scheme     values by default, and change the internal scheme checks that were case-sensitive to be case-insensitive.
    There are no known workarounds for this issue. (CVE-2023-35944)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

It is, therefore, affected by multiple vulnerabilities as referenced in the ALAS2023-2023-344 advisory.

  - Wasmtime is a standalone runtime for WebAssembly. Prior to versions 6.0.2, 7.0.1, and 8.0.1, Wasmtime's     implementation of managing per-instance state, such as tables and memories, contains LLVM-level undefined     behavior. This undefined behavior was found to cause runtime-level issues when compiled with LLVM 16 which     causes some writes, which are critical for correctness, to be optimized away. Vulnerable versions of     Wasmtime compiled with Rust 1.70, which is currently in beta, or later are known to have incorrectly     compiled functions. Versions of Wasmtime compiled with the current Rust stable release, 1.69, and prior     are not known at this time to have any issues, but can theoretically exhibit potential issues. The     underlying problem is that Wasmtime's runtime state for an instance involves a Rust-defined structure     called `Instance` which has a trailing `VMContext` structure after it. This `VMContext` structure has a     runtime-defined layout that is unique per-module. This representation cannot be expressed with safe code     in Rust so `unsafe` code is required to maintain this state. The code doing this, however, has methods     which take `&self` as an argument but modify data in the `VMContext` part of the allocation. This means     that pointers derived from `&self` are mutated. This is typically not allowed, except in the presence of     `UnsafeCell`, in Rust. When compiled to LLVM these functions have `noalias readonly` parameters which     means it's UB to write through the pointers. Wasmtime's internal representation and management of     `VMContext` has been updated to use `&mut self` methods where appropriate. Additionally verification tools     for `unsafe` code in Rust, such as `cargo miri`, are planned to be executed on the `main` branch soon to     fix any Rust-level issues that may be exploited in future compiler versions. Precomplied binaries     available for Wasmtime from GitHub releases have been compiled with at most LLVM 15 so are not known to be     vulnerable. As mentioned above, however, it's still recommended to update. Wasmtime version 6.0.2, 7.0.1,     and 8.0.1 have been issued which contain the patch necessary to work correctly on LLVM 16 and have no     known UB on LLVM 15 and earlier. If Wasmtime is compiled with Rust 1.69 and prior, which use LLVM 15, then     there are no known issues. There is a theoretical possibility for undefined behavior to exploited,     however, so it's recommended that users upgrade to a patched version of Wasmtime. Users using beta Rust     (1.70 at this time) or nightly Rust (1.71 at this time) must update to a patched version to work     correctly. (CVE-2023-30624)

  - c-ares is an asynchronous resolver library. When cross-compiling c-ares and using the autotools build     system, CARES_RANDOM_FILE will not be set, as seen when cross compiling aarch64 android. This will     downgrade to using rand() as a fallback which could allow an attacker to take advantage of the lack of     entropy by not using a CSPRNG. This issue was patched in version 1.19.1. (CVE-2023-31124)

  - c-ares is an asynchronous resolver library. ares_inet_net_pton() is vulnerable to a buffer underflow for     certain ipv6 addresses, in particular 0::00:00:00/2 was found to cause an issue. C-ares only uses this     function internally for configuration purposes which would require an administrator to configure such an     address via ares_set_sortlist(). However, users may externally use ares_inet_net_pton() for other purposes     and thus be vulnerable to more severe issues. This issue has been fixed in 1.19.1. (CVE-2023-31130)

  - c-ares is an asynchronous resolver library. When /dev/urandom or RtlGenRandom() are unavailable, c-ares     uses rand() to generate random numbers used for DNS query ids. This is not a CSPRNG, and it is also not     seeded by srand() so will generate predictable output. Input from the random number generator is fed into     a non-compilant RC4 implementation and may not be as strong as the original RC4 implementation. No attempt     is made to look for modern OS-provided CSPRNGs like arc4random() that is widely available. This issue has     been fixed in version 1.19.1. (CVE-2023-31147)

  - c-ares is an asynchronous resolver library. c-ares is vulnerable to denial of service. If a target     resolver sends a query, the attacker forges a malformed UDP packet with a length of 0 and returns them to     the target resolver. The target resolver erroneously interprets the 0 length as a graceful shutdown of the     connection. This issue has been patched in version 1.19.1. (CVE-2023-32067)

  - Envoy is an open source edge and service proxy designed for cloud-native applications. Prior to versions     1.27.0, 1.26.4, 1.25.9, 1.24.10, and 1.23.12, a malicious client is able to construct credentials with     permanent validity in some specific scenarios. This is caused by the some rare scenarios in which HMAC     payload can be always valid in OAuth2 filter's check. Versions 1.27.0, 1.26.4, 1.25.9, 1.24.10, and     1.23.12 have a fix for this issue. As a workaround, avoid wildcards/prefix domain wildcards in the host's     domain configuration. (CVE-2023-35941)

  - Envoy is an open source edge and service proxy designed for cloud-native applications. Prior to versions     1.27.0, 1.26.4, 1.25.9, 1.24.10, and 1.23.12, gRPC access loggers using listener's global scope can cause     a `use-after-free` crash when the listener is drained. Versions 1.27.0, 1.26.4, 1.25.9, 1.24.10, and     1.23.12 have a fix for this issue. As a workaround, disable gRPC access log or stop listener update.
    (CVE-2023-35942)

  - Envoy is an open source edge and service proxy designed for cloud-native applications. Prior to versions     1.27.0, 1.26.4, 1.25.9, 1.24.10, and 1.23.12, the CORS filter will segfault and crash Envoy when the     `origin` header is removed and deleted between `decodeHeaders`and `encodeHeaders`. Versions 1.27.0,     1.26.4, 1.25.9, 1.24.10, and 1.23.12 have a fix for this issue. As a workaround, do not remove the     `origin` header in the Envoy configuration. (CVE-2023-35943)

  - Envoy is an open source edge and service proxy designed for cloud-native applications. Envoy allows mixed-     case schemes in HTTP/2, however, some internal scheme checks are case-sensitive. Prior to versions 1.27.0,     1.26.4, 1.25.9, 1.24.10, and 1.23.12, this can lead to the rejection of requests with mixed-case schemes     such as `htTp` or `htTps`, or the bypassing of some requests such as `https` in unencrypted connections.
    With a fix in versions 1.27.0, 1.26.4, 1.25.9, 1.24.10, and 1.23.12, Envoy will now lowercase scheme     values by default, and change the internal scheme checks that were case-sensitive to be case-insensitive.
    There are no known workarounds for this issue. (CVE-2023-35944)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

ID	Name	Product	Family	Severity
182066	Amazon Linux 2 : ecs-service-connect-agent (ALASECS-2023-007)	Nessus	Amazon Linux Local Security Checks	critical
181703	Amazon Linux 2023 : ecs-service-connect-agent (ALAS2023-2023-344)	Nessus	Amazon Linux Local Security Checks	critical

Detections

Analytics

CVE-2023-30624

high

Tenable Plugins

critical

critical