Security
Headlines
HeadlinesLatestCVEs

Source

ghsa

GHSA-4fg9-5w46-xmrj: Apache Superset Server Side Request Forgery vulnerability

Improper REST API permission in Apache Superset up to and including 2.1.0 allows for an authenticated Gamma users to test network connections, possible SSRF.

ghsa
#vulnerability#apache#git#ssrf#auth
GHSA-v594-2c97-hx38: Apache Superset vulnerable to improper data authorization

Improper data authorization check on Jinja templated queries in Apache Superset up to and including 2.1.0 allows for an authenticated user to issue queries on database tables they may not have access to.

GHSA-9qc3-p9jq-2x27: Apache Superset users may incorrectly create resources using the import charts feature

A non Admin authenticated user could incorrectly create resources using the import charts feature, on Apache Superset up to and including 2.1.0. 

GHSA-9832-mgg4-3gr6: Apache Superset has improper default REST API permission for Gamma users

An improper default REST API permission for Gamma users in Apache Superset up to and including 2.1.0 allows for an authenticated Gamma user to test database connections.

GHSA-f4r5-q63f-gcww: Keylime registrar and (untrusted) Agent can be bypassed by an attacker

### Impact A security issue was found in the Keylime `registrar` code which allows an attacker to effectively bypass the challenge-response protocol used to verify that an `agent` has indeed access to an AIK which in indeed related to the EK. When an `agent` starts up, it will contact a `registrar` and provide a public EK and public AIK, in addition to the EK Certificate. This `registrar` will then challenge the `agent` to decrypt a challenge encrypted with the EK. When receiving the wrong "auth_tag" back from the `agent` during activation, the `registrar` answers with an error message that contains the expected correct "auth_tag" (an HMAC which is calculated within the `registrar` for checking). An attacker could simply record the correct expected "auth_tag" from the HTTP error message and perform the activate call again with the correct expected "auth_tag" for the `agent`. The security issue allows an attacker to pass the challenge-response protocol during registration with (alm...

GHSA-2pxw-r47w-4p8c: Privilege Escalation on Linux/MacOS

### Impact An attacker can use crafted requests to bypass metadata bucket name checking and put an object into any bucket while processing `PostPolicyBucket`. To carry out this attack, the attacker requires credentials with `arn:aws:s3:::*` permission, as well as enabled Console API access. ### Patches ``` commit 67f4ba154a27a1b06e48bfabda38355a010dfca5 Author: Aditya Manthramurthy <donatello@users.noreply.github.com> Date: Sun Mar 19 21:15:20 2023 -0700 fix: post policy request security bypass (#16849) ``` ### Workarounds Browser API access must be enabled turning off `MINIO_BROWSER=off` allows for this workaround. ### References The vulnerable code: ```go // minio/cmd/generic-handlers.go func setRequestValidityHandler(h http.Handler) http.Handler { return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { // ... // For all other requests reject access to reserved buckets bucketName, _ := request2BucketObjectName(r) if isMinioReservedBucket(buc...

GHSA-qvh6-3j7x-3hq7: Salt can cause Git Providers to get wrong data

Git Providers can read from the wrong environment because they get the same cache directory base name in Salt masters prior to 3005.2 or 3006.2. Anything that uses Git Providers with different environments can get garbage data or the wrong data, which can lead to wrongful data disclosure, wrongful executions, data corruption and/or crash.

GHSA-vpjg-wmf8-29h9: Salt vulnerable to denial of service

Salt masters prior to 3005.2 or 3006.2 contain a DOS in minion return. After receiving several bad packets on the request server equal to the number of worker threads, the master will become unresponsive to return requests until restarted.

GHSA-fcv6-fg5r-jm9q: Trigger `beforeFind` not invoked in internal query pipeline when fetching pointer

### Impact A Parse Pointer can be used to access internal Parse Server classes. It can also be used to circumvent the `beforeFind` query trigger which can be an additional vulnerability for deployments where the `beforeFind` trigger is used as a security layer to modify an incoming query. ### Patches The vulnerability was fixed by implementing a patch in the internal query pipeline to prevent a Parse Pointer to be used to access internal Parse Server classes or circumvent the `beforeFind` trigger. ### Workarounds There is no known workaround to prevent a Parse Pointer to be used to access internal Parse Server classes. A workaround if a `beforeFind` trigger is used as a security layer is to instead use the Parse Server provided [security layers](https://docs.parseplatform.org/parse-server/guide/#security) to manage access levels with Class-Level Permissions and Object-Level Access Control. ### References - GitHub security advisory: https://github.com/parse-community/parse-server...

GHSA-xc27-f9q3-4448: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') in hyper-bump-it

### Summary `hyper-bump-it` reads a file glob pattern from the configuration file. That is combined with the project root directory to construct a full glob pattern that is used to find files that should be edited. These matched files should be contained within the project root directory, but that is not checked. This could result in changes being written to files outside of the project. The default behaviour of `hyper-bump-it` is to display the planned changes and prompt the user for confirmation before editing any files. However, the configuration file provides a field that can be used cause files to be edited without displaying the prompt. ### Details The vulnerability is present in https://github.com/plannigan/hyper-bump-it/blob/49c726201bbdc02c052302e03fd907d2170e1f47/hyper_bump_it/_hyper_bump_it/files.py#L35 That code joins the project root directory with a string read from the configuration file without checking if the final path is located outside the project root directo...