ghsa

## Impact Trying to read malformed HAMT sharded directories can cause panics and virtual memory leaks. If you are reading untrusted user input, an attacker can then trigger a panic. This is caused by a bogus fanout parameter in the HAMT directory nodes. This includes checks returned in [ipfs/go-bitfield GHSA-2h6c-j3gf-xp9r](https://github.com/ipfs/go-bitfield/security/advisories/GHSA-2h6c-j3gf-xp9r), as well as limiting the fanout to <= 1024 (to avoid attempts of arbitrary sized allocations). ## Patches - https://github.com/ipfs/go-unixfsnode/commit/91b3d39d33ef0cd2aff2c95d50b2329350944b68 - https://github.com/ipfs/go-unixfsnode/commit/a4ed723727e0bdc2277158337c2fc0d82802d122 ## References * https://github.com/ipfs/go-unixfs/security/advisories/GHSA-q264-w97q-q778 * https://github.com/ipfs/go-bitfield/security/advisories/GHSA-2h6c-j3gf-xp9r

### Impact When feeding untrusted user input into the size parameter of `NewBitfield` and `FromBytes` functions, an attacker can trigger `panic`s. This happen when the `size` is a not a multiple of `8` or is negative. There were already a note in the `NewBitfield` documentation: > ``` > Panics if size is not a multiple of 8. > ```` But it incomplete and missing from `FromBytes`'s documentation. This has been replaced by returning an `(Bitfield, error)` and returning a non nil error if the size is wrong. ### Patches - https://github.com/ipfs/go-bitfield/commit/5e1d256fe043fc4163343ccca83862c69c52e579 ### Workarounds - Ensure `size%8 == 0 && size >= 0` yourself before calling `NewBitfield` or `FromBytes` ### References - https://github.com/ipfs/go-unixfs/security/advisories/GHSA-q264-w97q-q778

The ExtractCCDAAttributes Processor in Apache NiFi 1.2.0 through 1.19.1 does not restrict XML External Entity references. Flow configurations that include the ExtractCCDAAttributes Processor are vulnerable to malicious XML documents that contain Document Type Declarations with XML External Entity references. The resolution disables Document Type Declarations and disallows XML External Entity resolution in the ExtractCCDAAttributes Processor.

### Summary When running vertx web applications that serve files using `StaticHandler` on Windows Operating Systems and Windows File Systems, if the mount point is a wildcard (`*`) then an attacker can exfiltrate any class path resource. ### Details When computing the relative path to locate the resource, in case of wildcards, the code: https://github.com/vert-x3/vertx-web/blob/62c0d66fa1c179ae6a4d57344631679a2b97e60f/vertx-web/src/main/java/io/vertx/ext/web/impl/Utils.java#L83 returns the user input (without validation) as the segment to lookup. Even though checks are performed to avoid escaping the sandbox, given that the input was not sanitized `\` are not properly handled and an attacker can build a path that is valid within the classpath. ### PoC https://github.com/adrien-aubert-drovio/vertx-statichandler-windows-traversal-path-vulnerability

A null pointer in OpenSSL can be dereferenced when signatures are being verified in malformed PKCS7 data. Agents or clients compiled with OpenSSL may experience unexpected crashes. OpenSSL has been removed in bottlerocket/update-operator version 1.1.0 in favor of Rust-based TLS using rustls.

A timing based side channel exists in the OpenSSL RSA decryption implementation which could enable a recovery of plaintext from across the network. This affects all RSA padding modes. A server agent compiled with OpenSSL could be made to give up plaintext payloads over the network, but this would require a large amount of malicious payloads from a third party actor as trial messages. OpenSSL removed in bottlerocket version 1.1.0 in favor of Rust-based TLS using rustls.

A double-free vulnerability exists in OpenSSL where it is possible to construct a malicious PEM file that has 0 bytes of payload data. This then points to data that has already been freed in memory which, when freed again, leads to a crash. Agents or clients compiled with OpenSSL may crash unexpectedly when parsing these PEM files. OpenSSL has been removed in bottlerocket/update-operator version 1.1.0 in favor of Rust-based TLS using rustls.

A read buffer overflow can be triggered in OpenSSL X.509 verification during name constraint checking. Note that this occurs after the certificate chain has been verified and would require a compromised CA. This can cause a client or agent compiled with OpenSSL to crash unexpectedly. OpenSSL has been removed in bottlerocket/update-operator version 1.1.0 in favor of Rust-based TLS using rustls.

As indicated by this [issue](https://github.com/libpnet/libpnet/issues/449#issuecomment-663355987), a buffer overrun is possible in the `set_payload` setter of the various mutable "Packet" struct setters. The offending `set_payload` functions were defined within the struct `impl` blocks in earlier versions of the package, and later by the `packet` macro. Fixed in the `packet` macro by [this](https://github.com/libpnet/libpnet/pull/455) PR.

An OpenSSL public API provides streaming of ASN.1 data via a BIO. It is possible for a malicious third party to use the BIO to access unfreed memory pointers that are not cleaned up after execution of the API. Freeing these memory pointers will result in a crash. Agents and clients compiled with OpenSSL may see unexpected crashes. OpenSSL has been removed in bottlerocket/update-operator version 1.1.0 in favor of Rust-based TLS using rustls.