Cloudflare vulnerabilities

Description: To issue and renew TLS certificates on behalf of customers, Cloudflare's Universal SSL feature automatically manages the CAA RRset for the customer's zone. This auto-managed RRset is permissive by design (e.g. 'issue "letsencrypt.org"' without parameters). On Universal SSL zones, Cloudflare's authoritative DNS serves this auto-managed RRset at query time, superseding any customer-configured CAA records on the zone. When a customer publishes a stricter CAA record using the RFC 8657 accounturi or validationmethods parameters, the Certificate Authority does not observe those parameters when evaluating the served RRset under RFC 8659. As a result, the RFC 8657 account-binding and validation-method-binding protections are not enforced end-to-end on Universal SSL zones. Successful exploitation could result in issuance of a browser-trusted TLS certificate to an attacker, enabling MITM against the affected domain. Exploitation is non-trivial in practice: an attacker would need to hold an ACME account at one of the Certificate Authorities in the served CAA RRset and to simultaneously satisfy domain control validation across the multiple geographically distinct Network Perspectives the CA relies on for Multi-Perspective Issuance Corroboration. Cloudflare prefixes are anycast-announced from hundreds of locations globally, raising the bar against single-vantage-point BGP hijacks. Any resulting misissuance of a browser-trusted certificate is subject to Certificate Transparency logging required by major browsers, and would be visible to CT monitoring. Mitigation:  Customers requiring strict RFC 8657 enforcement need to disable Universal SSL on the affected zone. Universal SSL's automatic CAA management and customer-set RFC 8657 accounturi and validationmethods enforcement are mutually exclusive by the nature of the issue, so there is no in-product workaround that preserves both.  Certificate Transparency monitoring is recommended for all customers as a general detection control. Credits: David Osipov (ORCID: https://orcid.org/0009-0005-2713-9242), independent researcher

Cloudflare Quiche was affected by 2 use-after-free vulnerabilities in the connection ID iterator FFI functions. The “quiche_connection_id_iter_next” and “quiche_conn_retired_scid_next” functions would return a pointer to a “ConnectionId” to the applications via function arguments, but the owned “ConnectionId” would be dropped at the end of those functions' scope. Only applications using those FFI functions are affected. The FFI API is disabled by default by a build-time feature flag. Impact If unpatched, an application calling the affected FFI functions will dereference freed memory. The most likely outcome is undefined behavior leading to a process crash (denial of service). Depending on allocator state, the read may also return adjacent heap contents, resulting in limited information disclosure or incorrect connection identifier handling. Mitigation Users are requested to upgrade to quiche 0.29.2 which is the earliest version containing the fix for this issue.

In gokey versions <0.2.0, a flaw in the seed decryption logic resulted in passwords incorrectly being derived solely from the initial vector and the AES-GCM authentication tag of the key seed. This issue has been fixed in gokey version 0.2.0. This is a breaking change. The fix has invalidated any passwords/secrets that were derived from the seed file (using the -s option). Even if the input seed file stays the same, version 0.2.0 gokey will generate different secrets. Impact This vulnerability impacts generated keys/secrets using a seed file as an entropy input (using the -s option). Keys/secrets generated just from the master password (without the -s option) are not impacted. The confidentiality of the seed itself is also not impacted (it is not required to regenerate the seed itself). Specific impact includes: * keys/secrets generated from a seed file may have lower entropy: it was expected that the whole seed would be used to generate keys (240 bytes of entropy input), where in vulnerable versions only 28 bytes was used * a malicious entity could have recovered all passwords, generated from a particular seed, having only the seed file in possession without the knowledge of the seed master password Patches The code logic bug has been fixed in gokey version 0.2.0 and above. Due to the deterministic nature of gokey, fixed versions will produce different passwords/secrets using seed files, as all seed entropy will be used now. System secret rotation guidance It is advised for users to regenerate passwords/secrets using the patched version of gokey (0.2.0 and above), and provision/rotate these secrets into respective systems in place of the old secret. A specific rotation procedure is system-dependent, but most common patterns are described below. Systems that do not require the old password/secret for rotation Such systems usually have a "Forgot password" facility or a similar facility allowing users to rotate their password/secrets by sending a unique "magic" link to the user's email or phone. In such cases users are advised to use this facility and input the newly generated password secret, when prompted by the system. Systems that require the old password/secret for rotation Such systems usually have a modal password rotation window usually in the user settings section requiring the user to input the old and the new password sometimes with a confirmation. To generate/recover the old password in such cases users are advised to: * temporarily download gokey version 0.1.3 https://github.com/cloudflare/gokey/releases/tag/v0.1.3 for their respective operating system to recover the old password * use gokey version 0.2.0 or above to generate the new password * populate the system provided password rotation form Systems that allow multiple credentials for the same account to be provisioned Such systems usually require a secret or a cryptographic key as a credential for access, but allow several credentials at the same time. One example is SSH: a particular user may have several authorized public keys configured on the SSH server for access. For such systems users are advised to: * generate a new secret/key/credential using gokey version 0.2.0 or above * provision the new secret/key/credential in addition to the existing credential on the system * verify that the access or required system operation is still possible with the new secret/key/credential * revoke authorization for the existing/old credential from the system Credit This vulnerability was found by Théo Cusnir ( @mister_mime https://hackerone.com/mister_mime ) and responsibly disclosed through Cloudflare's bug bounty program.