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)

    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. (CVE-2023-31124)

    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. (CVE-2023-31130)

    Insufficient randomness in generation of DNS query IDs

    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. (CVE-2023-31147)

    Denial of Service.

    Attack Steps:

    The target resolver sends a queryThe attacker forges a malformed UDP packet with a length of 0 and returns     them to the target resolverThe target resolver erroneously interprets the 0 length as a graceful shutdown     of the connection. (this is only valid for TCP connections, UDP is connection-less)Current resolution     fails, DoS attack is achieved. (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)

Tenable has extracted the preceding description block directly from the tested product security advisory.

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

Detections

Analytics

Amazon Linux 2023 : ecs-service-connect-agent (ALAS2023-2023-344)

critical Nessus Plugin ID 181703

Version 1.2