ghsa

### Impact Blst versions v0.3.0 to v0.3.2 can produce the incorrect outputs for some inputs to the blst_fp_eucl_inverse function. This could theoretically result in the creation of an invalid signature from correct inputs. However, fuzzing of higher level functions such as sign and verify were unable to produce incorrect results and there has been no reported occurrences of this issue being encountered in production use. ### Description During the course of differential fuzzing of the blst library by @guidovranken it was discovered that blst would produce the incorrect result for some input values in the inverse function. This was the result of the introduction of a new inversion formula in version v0.3.0. This source of these incorrect outputs was due to two issues: 1. The amount of inner loop iterations was not sufficient for the algorithm to converge. 2. It was erroneously assumed that the absolute value of the intermediate result would be capped at 767-bits. As a result, some out...

### Description Tendermint Core v0.34.0 introduced a new way of handling evidence of misbehavior. As part of this, [we added a new `Timestamp` field to `Evidence` structs](https://github.com/tendermint/tendermint/pull/5219). This timestamp would be calculated using the same algorithm that is used when a block is created and proposed. (This algorithm relies on the timestamp of the last commit from this specific block.) In Tendermint Core v0.34.0-v0.34.2, the `consensus` reactor is responsible for forming `DuplicateVoteEvidence` whenever double signs are observed. However, the current block is still “in flight” when it is being formed by the `consensus` reactor. It hasn’t been finalized through network consensus yet. This means that different nodes in the network may observe different “last commits” when assigning a timestamp to `DuplicateVoteEvidence.` In turn, different nodes could form `DuplicateVoteEvidence` objects at the same height but with different timestamps. One `Duplicat...

### Impact The general implementation for matching filesystem paths to globbing pattern is vulnerable to an access out of bounds of [the array holding the directories](https://github.com/tensorflow/tensorflow/blob/458c6260265c46ebaf18052d6c61aea4b6b40926/tensorflow/core/platform/file_system_helper.cc#L127): ```cc if (!fs->Match(child_path, dirs[dir_index])) { ... } ``` Since `dir_index` is [unconditionaly incremented](https://github.com/tensorflow/tensorflow/blob/458c6260265c46ebaf18052d6c61aea4b6b40926/tensorflow/core/platform/file_system_helper.cc#L106) outside of the lambda function where the vulnerable pattern occurs, this results in an access out of bounds issue under certain scenarios. For example, if `/tmp/x` is a directory that only contains a single file `y`, then the following scenario will cause a crash due to the out of bounds read: ```python >>> tf.io.gfile.glob('/tmp/x/') Segmentation fault ``` There are multiple invariants and preconditions that are assumed by the pa...

### Impact An attacker can execute arbitrary code in the context of a GitHub runner by creating a specially crafted GitHub issue. ### Patches This issue is patched in gajira-create version 2.0.1. ### Workarounds There are no known workarounds. ### References [GitHub Security Lab advisory GHSL-2020-172](https://securitylab.github.com/advisories/GHSL-2020-172-gajira-create-action)

xmlquery before 1.3.1 lacks a check for whether a LoadURL response is in the XML format, which allows attackers to cause a denial of service (SIGSEGV) at xmlquery.(*Node).InnerText or possibly have unspecified other impact.

This affects all versions of package github.com/russellhaering/goxmldsig prior to 1.1.1. There is a crash on nil-pointer dereference caused by sending malformed XML signatures. This issue is patched in version 1.1.1.

### Vulnerability type Data Validation ### Detail When an etcd instance attempts to perform service discovery, if a cluster size is provided as a negative value, the etcd instance will panic without recovery. ### References Find out more on this vulnerability in the [security audit report](https://github.com/etcd-io/etcd/blob/master/security/SECURITY_AUDIT.pdf) ### For more information If you have any questions or comments about this advisory: * Contact the [etcd security committee](https://github.com/etcd-io/etcd/blob/master/security/security-release-process.md#product-security-committee-psc)

### Vulnerability type Data Exposure ### Workarounds The etcd assumes that the on disk files are secure. The possible fixes have been provided, however, it is the responsibility of the etcd users to make sure that the etcd server WAL log files are secure. The [etcd doesn't encrypt key/value data stored on disk drives]( https://github.com/etcd-io/etcd/blob/master/Documentation/op-guide/security.md#does-etcd-encrypt-data-stored-on-disk-drives). ### Detail User credentials (login and password) are stored in WAL entries on each user authentication. If the WAL log files are not secure, it can potentially expose sensitive information. ### References Find out more on this vulnerability in the [security audit report](https://github.com/etcd-io/etcd/blob/master/security/SECURITY_AUDIT.pdf) ### For more information If you have any questions or comments about this advisory: * Contact the [etcd security committee](https://github.com/etcd-io/etcd/blob/master/security/security-release-process.md...

### Vulnerability type Access Control ### Workarounds The etcdctl and etcd API do not enforce a specific password length during user creation or user password update operations. [It is the responsibility of the administrator to enforce these requirements](https://github.com/etcd-io/etcd/blob/master/Documentation/op-guide/authentication.md#notes-on-password-strength). ### Detail etcd does not perform any password length validation, which allows for very short passwords, such as those with a length of one. This may allow an attacker to guess or brute-force users’ passwords with little computational effort. ### References Find out more on this vulnerability in the [security audit report](https://github.com/etcd-io/etcd/blob/master/security/SECURITY_AUDIT.pdf) ### For more information If you have any questions or comments about this advisory: * Contact the [etcd security committee](https://github.com/etcd-io/etcd/blob/master/security/security-release-process.md#product-security-committ...

### Vulnerability type Authentication ### Workarounds Refer to the [gateway documentation](https://github.com/etcd-io/etcd/blob/master/Documentation/op-guide/gateway.md). The vulnerability was spotted due to unclear documentation of how the gateway handles endpoints validation. ### Detail The gateway only authenticates endpoints detected from DNS SRV records, and it only authenticates the detected endpoints once. Therefore, if an endpoint changes its authentication settings, the gateway will continue to assume the endpoint is still authenticated. The auditors has noted that appropriate documentation of this validation functionality plus deprecation of this misleading functionality is an acceptable path forward. ### References Find out more on this vulnerability in the [security audit report](https://github.com/etcd-io/etcd/blob/master/security/SECURITY_AUDIT.pdf) ### For more information If you have any questions or comments about this advisory: * Contact the [etcd security commit...