Impact

Unix-like operating systems may segfault due to dereferencing a dangling pointer in specific circumstances. This requires an environment variable to be set in a different thread than the affected functions. This may occur without the user's knowledge, notably in a third-party library.

Workarounds

No workarounds are known.

References

• time-rs/time#293

The Rust Security Response WG was notified that the regex crate did not properly limit the complexity of the regular expressions (regex) it parses. An attacker could use this security issue to perform a denial of service, by sending a specially crafted regex to a service accepting untrusted regexes. No known vulnerability is present when parsing untrusted input with trusted regexes.

This issue has been assigned CVE-2022-24713. The severity of this vulnerability is "high" when the regex crate is used to parse untrusted regexes. Other uses of the regex crate are not affected by this vulnerability.

Overview

The regex crate features built-in mitigations to prevent denial of service attacks caused by untrusted regexes, or untrusted input matched by trusted regexes. Those (tunable) mitigations already provide sane defaults to prevent attacks. This guarantee is documented and it's considered part of the crate's API.

Unfortunately a bug was discovered in the mitigations designed to prevent untrusted regexes to take an arbitrary amount of time during parsing, and it's possible to craft regexes that bypass such mitigations. This makes it possible to perform denial of service attacks by sending specially crafted regexes to services accepting user-controlled, untrusted regexes.

Affected versions

All versions of the regex crate before or equal to 1.5.4 are affected by this issue. The fix is include starting from regex 1.5.5.

Mitigations

We recommend everyone accepting user-controlled regexes to upgrade immediately to the latest version of the regex crate.

Unfortunately there is no fixed set of problematic regexes, as there are practically infinite regexes that could be crafted to exploit this vulnerability. Because of this, we do not recommend denying known problematic regexes.

Acknowledgements

We want to thank Addison Crump for responsibly disclosing this to us according to the Rust security policy, and for helping review the fix.

We also want to thank Andrew Gallant for developing the fix, and Pietro Albini for coordinating the disclosure and writing this advisory.

Deeply nested fragments in a GraphQL request may cause a stack overflow in the server.

It was sometimes possible for SQLite versions >= 1.0.12, < 3.39.2 to allow an array-bounds overflow when large string were input into SQLite's printf function.

As libsqlite3-sys bundles SQLite, it is susceptible to the vulnerability. libsqlite3-sys was updated to bundle the patched version of SQLite here.

Versions of ed25519-dalek prior to v2.0 model private and public keys as separate types which can be assembled into a Keypair, and also provide APIs for serializing and deserializing 64-byte private/public keypairs.

Such APIs and serializations are inherently unsafe as the public key is one of the inputs used in the deterministic computation of the S part of the signature, but not in the R value. An adversary could somehow use the signing function as an oracle that allows arbitrary public keys as input can obtain two signatures for the same message sharing the same R and only differ on the S part.

Unfortunately, when this happens, one can easily extract the private key.

Revised public APIs in v2.0 of ed25519-dalek do NOT allow a decoupled private/public keypair as signing input, except as part of specially labeled "hazmat" APIs which are clearly labeled as being dangerous if misused.

The following presentation at this year's DEF CON was brought to our attention on the Diesel Gitter Channel:

SQL Injection isn't Dead: Smuggling Queries at the Protocol Level
http://web.archive.org/web/20240812130923/https://media.defcon.org/DEF%20CON%2032/DEF%20CON%2032%20presentations/DEF%20CON%2032%20-%20Paul%20Gerste%20-%20SQL%20Injection%20Isn't%20Dead%20Smuggling%20Queries%20at%20the%20Protocol%20Level.pdf
(Archive link for posterity.) Essentially, encoding a value larger than 4GiB can cause the length prefix in the protocol to overflow, causing the server to interpret the rest of the string as binary protocol commands or other data.

It appears Diesel does perform truncating casts in a way that could be problematic, for example: https://github.com/diesel-rs/diesel/blob/ae82c4a5a133db65612b7436356f549bfecda1c7/diesel/src/pg/connection/stmt/mod.rs#L36

This code has existed essentially since the beginning, so it is reasonable to assume that all published versions <= 2.2.2 are affected.

Mitigation

The prefered migration to the outlined problem is to update to a Diesel version newer than 2.2.2, which includes fixes for the problem.

As always, you should make sure your application is validating untrustworthy user input. Reject any input over 4 GiB, or any input that could encode to a string longer than 4 GiB. Dynamically built queries are also potentially problematic if it pushes the message size over this 4 GiB bound.

For web application backends, consider adding some middleware that limits the size of request bodies by default.

Resolution

Diesel now uses #[deny] directives for the following Clippy lints:

• cast_possible_truncation
• cast_possible_wrap
• cast_sign_loss

to prevent casts that will lead to precision loss or other trunctations. Additionally we performed an audit of the relevant code.

A fix is included in the 2.2.3 release.

Diesel allows users to configure various options for PostgreSQL's COPY FROM and COPY TO statements. These configurations are partially provided as strings or characters.

Diesel did not check if any these user-provided options contain a quote character ', which can lead to the injection of additional options in the current COPY FROM/COPY TO statement.

This vulnerability affects any user of COPY FROM/COPY TO that passes user-provided input to any of the affected functions. It can result in modifications of options in the current statement, but it is not possible inject additional statements.

Mitigation

The preferred mitigation to the outlined problem is to update to Diesel version 2.3.8 or newer, which includes fixes for the problem.

Resolution

Diesel now correctly escapes any quotes contained in the provided arguments.

Diesel allows to register custom aggregate SQL functions for SQLite via the SqliteAggregate interface.

To store an instance of the custom aggregate processor Diesel relied on the sqlite3_aggregate_context function provided by sqlite. This function doesn't provide any guarantees about alignment of the returned allocation, which in turn can lead to problems if the type implementing requires a special alignment, e.g. via a custom #[align(x)] attribute on the type implementing this trait. This affects any user of SqliteAggregate that registers the custom aggregate function with an SQLite connection, while using a non-standard alignment on the type implementing this trait.

Mitigation

The preferred mitigation to the outlined problem is to update to a Diesel version 2.3.8 or newer, which includes fixes for the problem.

Resolution

Diesel now allocates the corresponding memory on Rust side to get a correctly aligned allocation.

BytesStart::attributes() returns an Attributes iterator which, by default (with_checks(true)), rejects a start tag that repeats an attribute name. For each attribute yielded, the iterator compared the new name against every name seen so far in the same tag using a linear scan, so a start tag with N distinct attribute names cost O(N²) byte comparisons. There was no bound on N other than the size of the buffered start tag.

Impact

Any code that parses untrusted XML and iterates a start tag's attributes with the default duplicate check enabled can be made to spend CPU time quadratic in the number of attributes on a single tag. Because the check is pure computation with no .await/I/O, an I/O-based timeout on the consumer (for example a read or request timeout) cannot interrupt it while it runs.

Measured cost of a single start tag, release build:

| Attributes on one tag | Time | |---|---| | 80,000 | ~6 s | | 800,000 | ~10 min |

The cost grows with the square of the attribute count, so a start tag of a few tens of megabytes can stall a parsing thread for hours. No memory is exhausted and the parser does not crash; the effect is CPU exhaustion on the thread doing the parsing: a single crafted start tag can pin a CPU core for minutes to hours, denying service to that worker. A deployment that places a wall-clock bound on parsing, or confines it to a non-critical thread, may consider the availability impact lower.

Affected code paths

• BytesStart::attributes() / Attributes iterated with checks enabled (the default), and BytesStart::try_get_attribute.
• NsReader, which resolves namespaces by iterating a tag's attributes and so reaches the same check internally.

Consumers that iterate attributes with .attributes().with_checks(false) and do not use NsReader are not affected.

This was reported as reachable by a remote, unauthenticated attacker in a real-world RPKI relying party (NLnet Labs Routinator) via a crafted RRDP snapshot.xml.

Remediation

Upgrade to quick-xml >= 0.41.0, where the duplicate check keeps the linear scan for start tags with a small number of attributes and switches to an O(1) hash pre-filter above a threshold, making the whole tag O(N). The reported AttrError::Duplicated positions are unchanged.

If upgrading is not possible and duplicate-name detection is not required, disable it with .attributes().with_checks(false) (this does not help NsReader consumers, which have no equivalent opt-out before 0.41.0).

NsReader resolves namespaces by calling NamespaceResolver::push for every Start/Empty event before the event is returned to the caller. push iterated all xmlns / xmlns:* attributes on the start tag and, for each one, appended the prefix bytes to an internal buffer and pushed a NamespaceBinding (32 bytes on 64-bit) to an internal Vec, with no upper bound on the number of declarations.

Impact

A start tag with N namespace declarations drove roughly 3× the tag's byte size in NamespaceResolver heap, allocated inside quick-xml before the NsReader consumer ever received the event and could inspect or reject it. A consumer that bounds its input size therefore still cannot bound this allocation: an M-byte start tag yields on the order of 3 × M bytes of resolver heap the caller never sees.

On untrusted XML this lets a remote, unauthenticated attacker force large heap allocations with a single start tag. With several NsReaders running concurrently on independent inputs (a common server pattern), the allocations stack and can exhaust process memory, causing the operating system to kill the process (OOM). This was confirmed against a real-world RPKI relying party (NLnet Labs Routinator), where concurrent RRDP validation workers parsing a crafted snapshot.xml exceeded the memory limit and the process was OOM-killed.

Affected code paths

Consumers using NsReader (which always calls NamespaceResolver::push before yielding Start/Empty), or calling NamespaceResolver::push directly. A plain Reader that does not perform namespace resolution is not affected.

Remediation

Upgrade to quick-xml >= 0.41.0. NamespaceResolver::push now rejects a start tag that declares more than DEFAULT_MAX_DECLARATIONS_PER_ELEMENT (256) namespace bindings, returning the new NamespaceError::TooManyDeclarations instead of allocating without limit. The limit is configurable via NamespaceResolver::set_max_declarations_per_element (use usize::MAX to restore the previous unbounded behavior), and NsReader::resolver_mut() is provided to reach it.

There is no clean workaround for NsReader consumers before 0.41.0, as the allocation happens inside the reader with no configuration knob to cap it.