#aws

There is a risk of an IV collision using the awskms or aesgcm provider. NIST SP 800-38D section 8.3 states that it is unsafe to encrypt more than 2^32 plaintexts under the same key when using a random IV. The limit could easily be reached given the use case of database column encryption. Ciphertexts are likely to be persisted and stored together. IV collision could enable an attacker with access to the ciphertexts to decrypt all messages encrypted with the affected key. The aesgcm provider cannot be fixed without a breaking change, so users should not encrypt more than 2^32 values with any key. The awskms package can be fixed without a breaking change by switching to a counter-based IV.

## Impact If a malicious actor is able to trigger Trivy to scan container images from a crafted malicious registry, it could result in the leakage of credentials for legitimate registries such as AWS Elastic Container Registry (ECR), Google Cloud Artifact/Container Registry, or Azure Container Registry (ACR). These tokens can then be used to push/pull images from those registries to which the identity/user running Trivy has access. Taking AWS as an example, the leakage only occurs when Trivy is able to transparently obtain registry credentials from the default [credential provider chain](https://aws.github.io/aws-sdk-go-v2/docs/configuring-sdk/#specifying-credentials). You are affected if Trivy is executed in any of the following situations: - The environment variables contain static AWS credentials (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN) that have access to ECR. - Within a Pod running on an EKS cluster that has been assigned a role with access to ECR using an [...

By Deeba Ahmed "Linguistic Lumberjack" Threatens Data Breaches (CVE-2024-4323). Patch now to shield your cloud services from information disclosure, denial-of-service, or even remote takeover. This is a post from HackRead.com Read the original post: Fluent Bit Tool Vulnerability Threatens Billions of Cloud Deployments

By Waqas The Llama Drama vulnerability in the Llama-cpp-Python package exposes AI models to remote code execution (RCE) attacks, enabling attackers to steal data. Currently, over 6,000 models are affected by this vulnerability. This is a post from HackRead.com Read the original post: AI Python Package Flaw ‘Llama Drama’ Threatens Software Supply Chain

## ID: NFLX-2024-002 ### Impact Authenticated users can achieve limited RCE in ConsoleMe, restricted to flag inputs on a single CLI command. Due to this constraint, it is not currently known whether full RCE is possible but it is unlikely. However, a specific flag allows authenticated users to read any server files accessible by the ConsoleMe process. Given ConsoleMe's role as an AWS identity broker, accessing files containing secrets on the server could potentially be exploited for privilege escalation. Deployments of ConsoleMe that allow templated resources are impacted and urged to patch immediately. Deployments that do not permit templated resources are not affected. To determine if your ConsoleMe deployment uses templated resources, check the configuration value for `cache_resource_templates.repositories`. If this value does not exist or is an empty array, your deployment is not impacted. ### Description The self-service flow for templated resources in ConsoleMe accepts a user...

Here’s a rundown of some things you may have missed if you weren’t able to stay on top of the things coming out of the conference.

Compared to fuzzing for software vulnerabilities on Linux, where most of the code is open-source, targeting anything on macOS presents a few difficulties.

A Server-Side Request Forgery (SSRF) vulnerability exists in the wandb/wandb repository due to improper handling of HTTP 302 redirects. This issue allows team members with access to the 'User settings -> Webhooks' function to exploit this vulnerability to access internal HTTP(s) servers. In severe cases, such as on AWS instances, this could potentially be abused to achieve remote code execution on the victim's machine. The vulnerability is present in the latest version of the repository.

### Impact SQL injection is possible when using the non-default connection property `preferQueryMode=simple` in combination with application code which has a vulnerable SQL that negates a parameter value. There is no vulnerability in the driver when using the default, extended query mode. Note that `preferQueryMode` is not a supported parameter in Redshift JDBC driver, and is inherited code from Postgres JDBC driver. Users who do not override default settings to utilize this unsupported query mode are not affected. ### Patch This issue is patched in driver version 2.1.0.28. ### Workarounds Do not use the connection property `preferQueryMode=simple`. (NOTE: If you do not explicitly specify a query mode, then you are using the default of extended query mode and are not affected by this issue.) ### References Similar to finding in Postgres JDBC: https://github.com/pgjdbc/pgjdbc/security/advisories/GHSA-24rp-q3w6-vc56 If you have any questions or comments about this advisory, we a...

SAP Cloud Connector versions 2.15.0 through 2.16.1 were found to happily accept self-signed TLS certificates between SCC and SAP BTP.