ghsa

Moby is an open-source project created by Docker to enable software containerization. A bug was found in Moby (Docker Engine) where supplementary groups are not set up properly. If an attacker has direct access to a container and manipulates their supplementary group access, they may be able to use supplementary group access to bypass primary group restrictions in some cases, potentially gaining access to sensitive information or gaining the ability to execute code in that container. This bug is fixed in Moby (Docker Engine) 20.10.18. Users should update to this version when it is available. Running containers should be stopped and restarted for the permissions to be fixed. For users unable to upgrade, this problem can be worked around by not using the `"USER $USERNAME"` Dockerfile instruction. Instead by calling `ENTRYPOINT ["su", "-", "user"]` the supplementary groups will be set up properly. Thanks to Steven Murdoch for reporting this issue. ---- ### Impact If an attacker has d...

### Impact When a full CVSS v2.0 vector string is parsed using `ParseVector`, an Out-of-Bounds Read is possible due to a lack of tests. The Go module will then panic. ### Patches The problem is patched in tag `v0.4.0`, by the commit `d9d478ff0c13b8b09ace030db9262f3c2fe031f4`. ### Workarounds The only way to avoid it is by parsing CVSS v2.0 vector strings that does not have all attributes defined (e.g. `AV:N/AC:L/Au:N/C:P/I:P/A:C/E:U/RL:OF/RC:C/CDP:MH/TD:H/CR:M/IR:M/AR:M`). ### References N/A ### CPE v2.3 As stated in [SECURITY.md](https://github.com/pandatix/go-cvss/blob/master/SECURITY.md), the CPE v2.3 to refer to this Go module is `cpe:2.3:a:pandatix:go_cvss:*:*:*:*:*:*:*:*`. The entry has already been requested to the NVD CPE dictionnary. ### Exploit example ```go package main import ( "log" gocvss20 "github.com/pandatix/go-cvss/20" ) func main() { _, err := gocvss20.ParseVector("AV:N/AC:L/Au:N/C:P/I:P/A:C/E:U/RL:OF/RC:C/CDP:MH/TD:H/CR:M/IR:M/AR:M") if err != nil { lo...

### Impact The implementation of tf.reshape op in TensorFlow is vulnerable to a denial of service via CHECK-failure (assertion failure) caused by overflowing the number of elements in a tensor: ```python import tensorflow as tf tf.reshape(tensor=[[1]],shape=tf.constant([0 for i in range(255)], dtype=tf.int64)) ``` This is another instance of [TFSA-2021-198](https://github.com/tensorflow/tensorflow/blob/master/tensorflow/security/advisory/tfsa-2021-198.md) (https://github.com/advisories/GHSA-prcg-wp5q-rv7p). ### Patches We have patched the issue in GitHub commit [61f0f9b94df8c0411f0ad0ecc2fec2d3f3c33555](https://github.com/tensorflow/tensorflow/commit/61f0f9b94df8c0411f0ad0ecc2fec2d3f3c33555). The fix will be included in TensorFlow 2.10.0. We will also cherrypick this commit on TensorFlow 2.9.1, TensorFlow 2.8.1, and TensorFlow 2.7.2, as these are also affected and still in supported range. ### For more information Please consult [our security guide](https://github.com/tensorflow/te...

### Impact The implementation of SobolSampleOp is vulnerable to a denial of service via CHECK-failure (assertion failure) caused by assuming `input(0)`, `input(1)`, and `input(2)` to be scalar. ```python import tensorflow as tf tf.raw_ops.SobolSample(dim=tf.constant([1,0]), num_results=tf.constant([1]), skip=tf.constant([1])) ``` ### Patches We have patched the issue in GitHub commit [c65c67f88ad770662e8f191269a907bf2b94b1bf](https://github.com/tensorflow/tensorflow/commit/c65c67f88ad770662e8f191269a907bf2b94b1bf). The fix will be included in TensorFlow 2.10.0. We will also cherrypick this commit on TensorFlow 2.9.1, TensorFlow 2.8.1, and TensorFlow 2.7.2, as these are also affected and still in supported range. ### For more information Please consult [our security guide](https://github.com/tensorflow/tensorflow/blob/master/SECURITY.md) for more information regarding the security model and how to contact us with issues and questions. ### Attribution This vulnerability has been r...

indy-node is the server portion of Hyperledger Indy, a distributed ledger purpose-built for decentralized identity. ### Impact An attacker can max out the number of client connections allowed by the ledger that was deployed using guidance provided in the indy-node repository, leaving the ledger unable to be used for its intended purpose. The ledger content will not be impacted by the attack, and the ledger will resume servicing valid client requests after the attack. ### Mitigations This attack exploits the trade-off between resilience and availability. Any protection against abusive client connections will also prevent the network being accessed by certain legitimate users. As a result, validator nodes must tune their firewall rules to ensure the right trade-off for their network's expected users. The guidance previously provided enabled a low-cost DDoS attack. The [guidance to network operators for the use of firewall rules](https://github.com/hyperledger/indy-node/blob/main/do...

### Impact Harbor fails to validate the user permissions when updating a robot account that belongs to a project that the authenticated user doesn’t have access to. API call: PUT /robots/{robot_id} By sending a request that attempts to update a robot account, and specifying a robot account id and robot account name that belongs to a different project that the user doesn’t have access to, it was possible to revoke the robot account permissions. ### Patches This and similar issues are fixed in Harbor v2.5.2 and later. Please upgrade as soon as possible. ### Workarounds There are no workarounds available. ### For more information If you have any questions or comments about this advisory: * Open an issue in [the Harbor GitHub repository](https://github.com/goharbor/harbor) ### Credits Thanks to [Gal Goldstein](https://www.linkedin.com/in/gal-goldshtein/) and [Daniel Abeles](https://www.linkedin.com/in/daniel-abeles/) from [Oxeye Security](https://www.oxeye.io/) for reporting this iss...

### Impact Harbor fails to validate the user permissions when updating tag immutability policies - API call: PUT /projects/{project_name_or_id}/immutabletagrules/{immutable_rule_id} By sending a request to update a tag immutability policy with an id that belongs to a project that the currently authenticated user doesn’t have access to, the attacker could modify tag immutability policies configured in other projects. ### Patches This and similar issues are fixed in Harbor v2.5.2 and later. Please upgrade as soon as possible. ### Workarounds There are no workarounds available. ### For more information If you have any questions or comments about this advisory: * Open an issue in [the Harbor GitHub repository](https://github.com/goharbor/harbor) ### Credits Thanks to [Gal Goldstein](https://www.linkedin.com/in/gal-goldshtein/) and [Daniel Abeles](https://www.linkedin.com/in/daniel-abeles/) from [Oxeye Security](https://www.oxeye.io/) for reporting this issue.

### Impact Harbor fails to validate the user permissions to view Webhook policies including relevant credentials configured in different projects the user doesn’t have access to, resulting in malicious users being able to read Webhook policies of other users/projects. API call is   GET /projects/{project_name_or_id}/webhook/policies/{webhook_policy_id} By sending the below request and specifying different Webhook policy ids in the last part of the URL, the malicious user may disclose Webhook policies related to other repositories/projects.: none;"> ### Patches This and similar issues are fixed in Harbor v2.5.2 and later. Please upgrade as soon as possible. ### Workarounds There are no workarounds available. ### For more information If you have any questions or comments about this advisory: * Open an issue in [the Harbor GitHub repository](https://github.com/goharbor/harbor) ### Credits Thanks to [Gal Goldstein](https://www.linkedin.com/in/gal-goldshtein/) and [Daniel Abeles](http...

### Impact Harbor fails to validate the user permissions when updating tag retention policies. API call: PUT /retentions/{id} By sending a request to update a tag retention policy with an id that belongs to a project that the currently authenticated user doesn’t have access to, the attacker could modify tag retention policies configured in other projects. ### Patches This and similar issues are fixed in Harbor v2.5.2 and later. Please upgrade as soon as possible. ### Workarounds There are no workarounds available. ### For more information If you have any questions or comments about this advisory: * Open an issue in [the Harbor GitHub repository](https://github.com/goharbor/harbor) ### Credits Thanks to [Gal Goldstein](https://www.linkedin.com/in/gal-goldshtein/) and [Daniel Abeles](https://www.linkedin.com/in/daniel-abeles/) from [Oxeye Security](https://www.oxeye.io/) for reporting this issue.

### Impact Due to missing canonicalization when `readDir` is called recursively, it was possible to display directory listings outside of the defined `fs` scope. This required a crafted symbolic link or junction folder inside an allowed path of the `fs` scope. No arbitrary file content could be leaked. ### Patches The issue has been resolved in https://github.com/tauri-apps/tauri/pull/5123 and the implementation now properly checks if the requested (sub) directory is a symbolic link outside of the defined `scope`. ### Workarounds Disable the `readDir` endpoint in the `allowlist` inside the `tauri.conf.json`. ### For more information This issue was initially reported by [martin-ocasek]( https://github.com/martin-ocasek) in [#4882](https://github.com/tauri-apps/tauri/issues/4882). If you have any questions or comments about this advisory: * Open an issue in [tauri](https://github.com/tauri-apps/tauri) * Email us at [[email protected]](mailto:[email protected])