ghsa

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 [security@tauri.app](mailto:security@tauri.app)

### Observation When handling dependencies that come from a Git repository instead of a registry, Poetry uses various commands, such as `git clone`. These commands are being constructed using user input (e.g. the repository URL). When building the commands, Poetry correctly avoids Command Injection vulnerabilities by passing an array of arguments instead of a command string. However, there is the possibility that a user input starts with a dash (`-`) and is therefore treated as an optional argument instead of a positional one. This can lead to Code Execution because some of the commands have options that can be leveraged to run arbitrary executables. To clone a repository, Poetry builds a git clone command, but fails to validate or sanitize the repository location properly: [`poetry/core/vcs/git.py`](https://github.com/python-poetry/poetry-core/blob/ad33bc2f92be03dc5b31a666664903c439fb1173/poetry/core/vcs/git.py#L207): ```python def clone(self, repository: str, dest: Path) -> str: ...

### Impact If `tf.sparse.cross` receives an input `separator` that is not a scalar, it gives a `CHECK` fail that can be used to trigger a denial of service attack. ```python import tensorflow as tf tf.sparse.cross(inputs=[],name='a',separator=tf.constant(['a', 'b'],dtype=tf.string)) ``` ### Patches We have patched the issue in GitHub commit [83dcb4dbfa094e33db084e97c4d0531a559e0ebf](https://github.com/tensorflow/tensorflow/commit/83dcb4dbfa094e33db084e97c4d0531a559e0ebf). 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 reported by Kang Hong Jin.

### Impact When `Conv2DBackpropInput` receives empty `out_backprop` inputs (e.g. `[3, 1, 0, 1]`), the current CPU/GPU kernels `CHECK` fail (one with dnnl, the other with cudnn). This can be used to trigger a denial of service attack. ```python import tensorflow as tf import numpy as np input_sizes = [3, 1, 1, 2] filter = np.ones([1, 3, 2, 3]) out_backprop = np.ones([3, 1, 0, 3]) strides = [1, 1, 2, 1] padding = 'VALID' tf.raw_ops.Conv2DBackpropInput( input_sizes = input_sizes, filter = filter, out_backprop = out_backprop, strides = strides, padding = padding ) ``` ### Patches We have patched the issue in GitHub commit [27a65a43cf763897fecfa5cdb5cc653fc5dd0346](https://github.com/tensorflow/tensorflow/commit/27a65a43cf763897fecfa5cdb5cc653fc5dd0346). 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 inform...

## Summary A number of vulnerabilities have been found in `cosign verify-blob`, where Cosign would successfully verify an artifact when verification should have failed. ## Vulnerability 1: Bundle mismatch causes invalid verification. ### Summary A cosign bundle can be crafted to successfully verify a blob even if the embedded rekorBundle does not reference the given signature. ### Details Cosign supports "bundles" which intend to allow offline verification of the signature and rekor inclusion. By using the --bundle flag in cosign sign-blob, cosign will create a JSON file called a "bundle". These bundles include three fields: base64Signature, cert, and rekorBundle. The desired behavior is that the verification of these bundles would: - verify the provided blob using the included signature and certificate - verify the rekorBundle SET - verify the rekorBundle payload references the given artifact. It appears that step three is not being performed, allowing "any old rekorBundle" to p...