From d6be205e4b7a8212ecdff69f1c57d089c7d12010 Mon Sep 17 00:00:00 2001 From: Henri Sivonen Date: Mon, 9 Dec 2024 14:28:49 +0200 Subject: [PATCH] idna accepts Punycode labels that do not produce any non-ASCII when decoded (#2163) --- crates/idna/RUSTSEC-0000-0000.md | 43 ++++++++++++++++++++++++++++++++ 1 file changed, 43 insertions(+) create mode 100644 crates/idna/RUSTSEC-0000-0000.md diff --git a/crates/idna/RUSTSEC-0000-0000.md b/crates/idna/RUSTSEC-0000-0000.md new file mode 100644 index 000000000..d9856afb3 --- /dev/null +++ b/crates/idna/RUSTSEC-0000-0000.md @@ -0,0 +1,43 @@ +```toml +[advisory] +id = "RUSTSEC-0000-0000" + +package = "idna" + +date = "2024-12-09" + +categories = ["privilege-escalation"] + +keywords = ["idna", "punycode", "same-origin", "domain-name"] + +aliases = ["CVE-2024-12224"] + +url = "https://bugzilla.mozilla.org/show_bug.cgi?id=1887898" + +[versions] +patched = [">= 1.0.0"] +``` + +# `idna` accepts Punycode labels that do not produce any non-ASCII when decoded + +`idna` 0.5.0 and earlier accepts Punycode labels that do not produce any non-ASCII output, which means that either ASCII labels or the empty root label can be masked such that they appear unequal without IDNA processing or when processed with a different implementation and equal when processed with `idna` 0.5.0 or earlier. + +Concretely, `example.org` and `xn--example-.org` become equal after processing by `idna` 0.5.0 or earlier. Also, `example.org.xn--` and `example.org.` become equal after processing by `idna` 0.5.0 or earlier. + +In applications using `idna` (but not in `idna` itself) this may be able to lead to privilege escalation when host name comparison is part of a privilege check and the behavior is combined with a client that resolves domains with such labels instead of treating them as errors that preclude DNS resolution / URL fetching and with the attacker managing to introduce a DNS entry (and TLS certificate) for an `xn--`-masked name that turns into the name of the target when processed by `idna` 0.5.0 or earlier. + +## Remedy + +Upgrade to `idna` 1.0.3 or later, if depending on `idna` directly, or to `url` 2.5.4 or later, if depending on `idna` via `url`. (This issue was fixed in `idna` 1.0.0, but versions earlier than 1.0.3 are not recommended for other reasons.) + +When upgrading, please take a moment to read about [alternative Unicode back ends for `idna`](https://docs.rs/crate/idna_adapter/latest). + +If you are using Rust earlier than 1.81 in combination with SQLx 0.8.2 or earlier, please also read an [issue](https://github.com/servo/rust-url/issues/992) about combining them with `url` 2.5.4 and `idna` 1.0.3. + +## Additional information + +This issue resulted from `idna` 0.5.0 and earlier implementing the UTS 46 specification literally on this point and the specification having this bug. The specification bug has been fixed in [revision 33 of UTS 46](https://www.unicode.org/reports/tr46/tr46-33.html#Modifications). + +## Acknowledgements + +Thanks to kageshiron for recognizing the security implications of this behavior.